בחירת ה-TTL הנכון לרשומות שלכם

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

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

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

הפשרה

TTL קצר (60-300 שניות) אומר שהשינויים מתפשטים בתוך דקות. עדכנו כתובת IP, והעולם רואה אותה כמעט מיד. אבל הרזולברים חייבים לשאול את שרתי השמות שלכם כל הזמן. יותר תעבורה. חיפושים מעט איטיים יותר, מכיוון שהתשובות ב-cache פגות לפני שמשתמשים יכולים ליהנות מהן.

TTL ארוך (3600-86400 שניות) אומר ששרתי השמות שלכם מטפלים בחלק קטן מהשאילתות. הרזולברים שומרים תשובות ב-cache למשך שעות או ימים. המשתמשים מקבלים תגובות מיידיות מה-cache. אבל שינוי משהו? אתם מחויבים. אם אתם מפנים לשרת הלא נכון, אתם מחכים.

ה-TTL האופטימלי תלוי בשאלה אחת: כמה סביר שהרשומה הזו תשתנה, וכמה גרוע אם השינויים איטיים?

TTL לפי יציבות

תשתית מוצקה כסלע (86400-172800 שניות)

אם לא השתנה בחודשים ולא ישתנה ללא תכנון רציני:

• שרתים ייעודיים שמחזיקים באותה כתובת IP מאז ההתקנה
• שרתי דואר הפועלים על תשתית יציבה — דואר אלקטרוני מתאים לשמירה ב-cache
• רשומות nameserver (NS) המצביעות על ה-DNS הסמכותי שלכם — אלה משתנות אולי פעם בכמה שנים

TTL של 24-48 שעות אומר שהרזולברים בקושי נוגעים בשרתים שלכם. האינטרנט סומך על התשובות שלכם.

שירותי ייצור (3600-7200 שניות)

רוב עומסי הייצור חיים כאן:

• אפליקציות מאוחסנות בענן שבהן כנראה לא תחליפו כתובות IP, אבל יכול להיות
• נקודות קצה של API שעשויות להזדקק להחלפה או התאמות של איזון עומסים
• CNAME של CDN שבהם הספק מסובב תשתית מדי פעם

שעה עד שעתיים נותנת לכם גמישות מבלי לטבוע בשאילתות DNS.

משאבים המשתנים לעיתים קרובות (300-900 שניות)

• סביבות פיתוח וסביבות בדיקה שבהן פריסות מתרחשות כל הזמן
• DNS דינמי לחיבורים עם כתובות IP משתנות
• מאגרי load balancer שבהם אתם צריכים להסיר שרתים לא בריאים במהירות

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

מערכות קריטיות ל-Failover (60-300 שניות)

כאשר דקות של השבתה עולות כסף רציני:

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

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

הטכניקה המקדימה להעברה

כאן אסטרטגיית TTL באמת מצילה אתכם.

אתם מעבירים שרת בשבת הקרובה. לרשומת ה-A שלכם יש TTL של 86400 שניות — 24 שעות. אם תחליפו את כתובת ה-IP בבוקר שבת, חלק מהמשתמשים לא יראו את ה-IP החדש עד בוקר ראשון. השרת הישן לא פעיל. אותם משתמשים רואים שגיאות.

הבעיה: ברגע שרזולבר שומר את הרשומה שלכם ב-cache, הוא לא ישאל שוב עד שה-TTL יפוג. אתם לא יכולים להגיע לרזולברים ברחבי העולם ולנקות את ה-cache שלהם. זהו המנוף היחיד שיש לכם — ואתם חייבים להשתמש בו לפני שתזדקקו לו.

הפתרון: הנמיכו את ה-TTL מבעוד מועד.

1. שבוע לפני: שנו את ה-TTL מ-86400 ל-300 שניות. אל תיגעו בכתובת ה-IP עדיין.
2. המתינו עד שה-TTL הישן יפוג לחלוטין: כל רזולבר ששמר את הרשומה שלכם ב-86400 שניות צריך לפוג. זה לוקח את כל תקופת ה-TTL המקורית — לפחות 24 שעות — אבל אתם עושים זאת שבוע מוקדם כדי להיות בטוחים.
3. בצעו את ההעברה: עכשיו כל רזולבר בודק כל חמש דקות. שנו את ה-IP, והעולם רואה אותו בתוך דקות.
4. אמתו: ודאו שהתעבורה מגיעה לשרת החדש כראוי.
5. החזירו את ה-TTL: העלו אותו חזרה ל-86400 שניות לפעולה יעילה לטווח ארוך.

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

TTL לפי סוג רשומה

רשומות A ו-AAAA: תלוי לחלוטין ביציבות התשתית. שרת ייעודי סטטי? 86400 שניות. מופע ענן? 3600 שניות.

רשומות CNAME: אתם מצביעים על תשתית של מישהו אחר. התאימו את ה-TTL שלכם לשלהם, או הנמיכו ממנו — אין טעם לשמור ב-cache את המצביע שלכם יותר זמן ממה שהם שומרים את היעד ב-cache. אם ל-CNAME שלכם יש TTL של 86400 שניות אבל לרשומת ה-A היעד יש 300 שניות, ה-TTL הארוך שלכם מנטרל את הקצר שלהם.

רשומות MX: תשתית דואר אלקטרוני יציבה מטבעה. 86400 שניות היא הסטנדרט. משלוח דואר מתאים לשמירה ב-cache בחן.

רשומות TXT: SPF ו-DKIM כמעט ולא משתנים — 86400 שניות. אסימוני אימות שתמחקו בקרוב? 3600 שניות או פחות.

רשומות NS: שרתי השמות הסמכותיים שלכם כמעט ולא משתנים. 172800 שניות (48 שעות) או יותר. כאשר אתם כן מחליפים שרתי שמות, תתכננו זאת בקפידה — בלי קשר ל-TTL.

דוגמה מהשטח

פלטפורמת מסחר אלקטרוני עשויה להגדיר:

לפני העברת מרכז נתונים, היו מורידים את www ואת api ל-300 שניות שבוע לפני, מעבירים, מאמתים, ואז מחזירים את ה-TTL לערכו המקורי.

שאלות נפוצות על DNS TTL

מה קורה אם אגדיר TTL נמוך מדי?

שרתי השמות הסמכותיים שלכם מטפלים ביותר שאילתות — אולי הרבה יותר. עבור רוב ההגדרות, זו רק חוסר יעילות: עלויות רוחב פס גבוהות יותר, איחור מעט גדול יותר למשתמשים. עבור דומיינים בעלי תעבורה גבוהה, TTL נמוך מאוד (מתחת ל-60 שניות) יכול ליצור בעיות עומס אמיתיות. הבעיה הגדולה יותר היא בדרך כלל בזבוז: אם הרשומות שלכם לא משתנות לעתים קרובות, אתם משלמים עבור גמישות שלעולם לא תשתמשו בה.

האם אני יכול לאלץ שינויי DNS להתפשט מהר יותר ממה שה-TTL מאפשר?

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

מדוע חלק מהשירותים הגדולים משתמשים ב-TTL קצר מאוד?

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

האם עלי להשתמש באותו TTL לכל הרשומות שלי?

לא. לרשומות שונות יש תדירויות שינוי שונות ותוצאות שונות כאשר הנתונים ישנים. לרשומות ה-NS שלכם המצביעות לשרתי שמות שכמעט לא משתנים לא צריך להיות אותו TTL כמו לרשומת ה-A של סביבת הבדיקה שלכם שמשתנה מדי יום. התאימו את ה-TTL ליציבות של מה שהרשומה מצביעה עליו.

מה אם שכחתי להוריד את ה-TTL לפני העברה?

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

מקורות