TTL מה זה ואיך הוא קובע מתי שינוי DNS נראה

שיניתם רשומת A, החלפתם ספק דואר או הפניתם דומיין ליעד חדש, אבל חלק מהמשתמשים עדיין מגיעים למקום הישן. ברוב המקרים זו אינה תקלה מסתורית: TTL מה זה, אם לא ההגדרה שקובעת כמה זמן שכבות DNS ברחבי הרשת רשאיות לזכור תשובה קיימת לפני שהן בודקות אותה מחדש. למי שמנהל דומיין יחיד זה פרט טכני. לסוכנות, צוות DevOps או מנהל פורטפוליו, זו הגדרה שמשפיעה ישירות על קצב תגובה, חלון סיכון, ביצועי DNS וחוויית משתמש.

TTL מה זה בהקשר של DNS

TTL הוא קיצור של Time To Live - זמן חיים, הנמדד בשניות. בהקשר של DNS, זהו משך הזמן שבו resolver, כלומר שרת DNS פותר שמות, רשאי לשמור תשובה במטמון שלו.

נניח שלרשומת `www` יש כתובת IP ו-TTL של 3,600 שניות. כאשר resolver מקבל את התשובה, הוא יכול להגיש אותה למשתמשים נוספים במשך שעה בלי לפנות שוב לשרת ה-DNS הסמכותי של הדומיין. רק לאחר שהזמן יפוג, הוא יבקש תשובה מעודכנת.

ההגדרה אינה אומרת שהרשומה תיעלם אחרי שעה. היא גם לא מבטיחה שכל העולם יראה שינוי בדיוק כעבור שעה. היא קובעת את משך המטמון המקסימלי של תשובה שנשמרה אצל resolver מרגע שנשלפה. ההבדל הזה קריטי כשמתכננים מעבר תשתית או טיפול באירוע.

למה בכלל צריך מטמון DNS

בלי מטמון, כל בקשה לדומיין הייתה מחייבת שרשרת שאילתות חוזרת אל שרתי DNS סמכותיים. התוצאה הייתה עומס מיותר, זמני תגובה גבוהים יותר ותלות גדולה בהרבה בזמינות של כל רכיב בדרך.

מטמון מאפשר ל-resolvers להחזיר תשובות במהירות, מפחית עומסים על תשתית ה-DNS ומייצב את חוויית הגלישה. TTL הוא מנגנון האיזון: ערך גבוה מעדיף יעילות ויציבות, בעוד ערך נמוך מעדיף גמישות ועדכון מהיר יותר.

אין כאן ערך "נכון" אוניברסלי. TTL של דומיין שיווקי יציב, שלא צפוי להשתנות במשך חודשים, שונה מ-TTL של שירות SaaS עם failover, החלפות כתובות IP ודרישות זמינות מחמירות.

מה קורה בפועל כשמשנים רשומת DNS

כאשר משנים רשומה, שרת ה-DNS הסמכותי מתחיל להחזיר את הערך החדש מיד לאחר שהשינוי נשמר ופורסם באזור. אבל resolvers שכבר שמרו את הערך הקודם אינם מחויבים לשאול שוב לפני שזמן ה-TTL של התשובה הישנה הסתיים.

לכן ייתכן שמחשב אחד יקבל את היעד החדש, משתמש אחר יקבל את היעד הישן, וכל אחד מהם יהיה תקין ביחס למטמון שבו הוא משתמש. גם הדפדפן, מערכת ההפעלה, נתב ארגוני או רשת סלולרית יכולים להוסיף שכבות cache משלהם. TTL של DNS אינו שולט בכל אחת מהן.

המונח הנפוץ "הפצת DNS" מעט מטעה. אין מנגנון שמפיץ שינוי ידנית לכל שרת בעולם. שרתי DNS מקבלים את העדכון כאשר המטמון המקומי שלהם פג והם מבצעים שאילתה חדשה. מה שנראה כהפצה הוא בפועל התחדשות מדורגת של מטמונים.

למה הורדת TTL ברגע השינוי לא עוזרת

זו טעות תפעולית מוכרת. אם הרשומה הייתה עם TTL של 86,400 שניות, ורק ברגע המעבר שיניתם אותה ל-300, resolvers שכבר שמרו את התשובה הישנה עדיין רשאים להשתמש בה עד יממה. הם לא יודעים בדיעבד שהחלטתם לקצר את זמן החיים שלה.

אם מתוכנן מעבר, מורידים את ה-TTL מראש - בדרך כלל לפחות במשך זמן השווה ל-TTL הישן, ולעיתים יותר. לאחר שהחלון הזה חלף, רוב ה-resolvers שיבקשו את הרשומה כבר יקבלו את ערך ה-TTL הנמוך. אז אפשר לבצע את השינוי עם חלון התאוששות קצר יותר.

אילו רשומות מושפעות מ-TTL

TTL מוגדר בדרך כלל ברמת הרשומה, ולכן יש לבחון כל סוג רשומה לפי התפקיד שלו. רשומות A ו-AAAA מכוונות תעבורה לכתובות IPv4 ו-IPv6. רשומות CNAME מגדירות alias. רשומות MX משפיעות על ניתוב דואר. TXT יכולות לשמש לאימותי שירותים, SPF, DKIM, DMARC או אימות בעלות.

לא כל רשומה דורשת אותה מדיניות. רשומת MX יציבה יכולה להחזיק TTL גבוה יותר, כל עוד אין מעבר דואר מתוכנן. רשומת אימות זמנית יכולה לקבל TTL קצר, אם כי צריך לזכור ששירות האימות עצמו עשוי לבצע בדיקות בקצב שלו. עבור רשומות של שירות קריטי, הערך צריך לשקף את יכולת הצוות לזהות תקלה, לקבל החלטה ולשנות יעד בזמן אמת.

יש גם Negative Caching - מטמון של תשובה שלילית, למשל כאשר resolver מקבל תשובת NXDOMAIN עבור שם שאינו קיים. משך הזמן הזה נגזר בדרך כלל מהגדרות SOA של אזור ה-DNS. אם יוצרים תת-דומיין חדש והוא לא נראה מיד אצל חלק מהמשתמשים, לא תמיד מדובר בבעיה ברשומה החדשה. ייתכן שהמטמון מחזיק תשובה ישנה שלפיה השם לא היה קיים.

איך בוחרים TTL נכון

TTL קצר אינו בהכרח מקצועי יותר. הוא מגדיל את תדירות השאילתות אל השרתים הסמכותיים, מפחית את יתרון המטמון ולעיתים מוסיף תנודתיות מיותרת. מנגד, TTL ארוך מדי יכול להפוך שינוי דחוף לאירוע שנמרח שעות.

לרשומות יציבות של אתר, ערך של שעה עד כמה שעות מתאים לעיתים קרובות. לתשתית שבה שינויים נדירים במיוחד, אפשר לבחור ערך ארוך יותר. לפני מיגרציה, החלפת CDN, שינוי יעד של redirect או מעבר ספק דואר, אפשר להוריד זמנית ל-300 או 600 שניות - בתנאי שעושים זאת מראש.

במערכות עם איזון עומסים, התאוששות מאסון או יכולת failover מבוססת DNS, TTL קצר יותר עשוי להיות מוצדק. אבל גם כאן צריך לדייק: TTL של 60 שניות לא מבטיח מעבר תוך דקה. קיימים caches שלא מתנהגים באופן מושלם, לקוחות עם מטמון מקומי וחיבורים קיימים שלא מתחדשים רק כי רשומת DNS התחלפה.

הבחירה הנכונה מתחילה בשאלה תפעולית פשוטה: כמה זמן הארגון מסוגל לחיות עם יעד ישן לאחר שינוי? אם התשובה היא עשר דקות, TTL של יום אינו מתאים. אם שינויים מתרחשים פעם ברבעון ואין סיבה עסקית להאיץ אותם, TTL נמוך מאוד הוא בעיקר רעש.

תהליך עבודה לפני שינוי קריטי

בניהול מקצועי, TTL אינו פרמטר שמתקנים תחת לחץ. הוא חלק מ-runbook של שינוי. לפני מעבר, מזהים את כל הרשומות המעורבות - לא רק A או CNAME, אלא גם MX, TXT, subdomains, redirects ותלויות של שירותים חיצוניים.

לאחר מכן מורידים TTL מראש, מתעדים את הערך המקורי וממתינים לחלון הנדרש. בזמן המעבר, מאמתים את התשובות מול שרתי ה-DNS הסמכותיים ומול resolvers חיצוניים, בודקים את השירות עצמו ולא מסתפקים בכך שהרשומה נראית תקינה בממשק. לבסוף, לאחר שהמערכת התייצבה, מחזירים TTL לערך שמתאים לשגרה.

החזרה לערך גבוה אינה קוסמטית. היא מחזירה את יתרונות המטמון ומונעת מצב שבו הגדרה זמנית הופכת בטעות למדיניות קבועה. בפורטפוליו גדול, שכחה כזו מצטברת לאלפי שאילתות, לעודף ניטור ולתפעול פחות צפוי.

TTL וניהול דומיינים בקנה מידה רחב

ככל שמספר הדומיינים גדל, הבעיה אינה להבין מהו TTL אלא לשמור על עקביות. רשומה קריטית עם 300 שניות בסביבת ייצור ורשומה זהה עם 86,400 שניות בדומיין אחר היא פער שעלול להיחשף רק בזמן תקלה.

לכן DNS צריך להיות מנוהל כחלק מתשתית ולא כאוסף מסכים נפרדים. הרשאות צוות, audit trail, פעולות bulk, תבניות רשומות והתראות על תוקף או שינוי הם חלק מהשליטה הנדרשת. בפלטפורמה כמו TalPress Domains, המטרה היא לאפשר לצוות לנהל את המחזור הזה מתוך מערכת אחת: שינוי, אימות, האצלת הרשאות ותיעוד - בלי לרדוף אחר גיליונות אקסל או גישות מפוזרות.

חשוב גם להבחין בין מהירות שינוי לבין אבטחת שינוי. גישה מהירה ל-DNS מועילה רק כאשר היא נשלטת היטב. הרשאות מדויקות, domain lock, פרטיות WHOIS ותהליך אישור פנימי מצמצמים את הסיכוי ששינוי TTL או יעד DNS יבוצע על ידי האדם הלא נכון, בזמן הלא נכון.

טעויות שכדאי להפסיק לעשות

הטעות הראשונה היא להתייחס ל-TTL כאל כפתור "רענון". הוא לא מנקה מטמונים קיימים ולא עוקף DNS של ספקי אינטרנט. הטעות השנייה היא להשאיר TTL נמוך לצמיתות רק כי היה מעבר מוצלח. הטעות השלישית היא לשנות TTL ורשומה באותה דקה, ואז לצפות להתנהגות אחידה.

טעות נוספת היא לבדוק רק מהמחשב של מי שביצע את השינוי. בדיקה מקומית יכולה להסתיר cache ישן או להציג cache חדש, ואין לה ערך מספק כהוכחת זמינות גלובלית. צריך לבדוק את התשובה הסמכותית, את התשובה דרך resolvers שונים ואת השירות בקצה - אתר, API, דואר או יעד ההפניה.

TTL טוב אינו הערך הנמוך ביותר שאפשר להקליד. הוא הערך שמתאים לארכיטקטורה, לקצב השינויים וליכולת התפעולית של הצוות. כשמתייחסים אליו כך, DNS מפסיק להיות שכבה שמקווים שתעבוד והופך לרכיב שניתן לתכנן, לבקר ולשנות בביטחון.