נניח שכתובת השרת של מתחם השתנתה: בבית האתר החדש נפתח, אבל הטלפון עדיין מתחבר לשרת הישן. גם כשמזינים אותו שם בשני המכשירים, התוצאות עשויות להיות שונות לזמן מה אם עברו במטמוני DNS שונים. מטמון HTTP שמשמש להורדה חוזרת של דף ומטמון DNS שעוזר למצוא לאיזו כתובת להתחבר מצריכים בדיקה של דברים שונים.
במאמר נעקוב אחר המארח הדמיוני של ספרייה, www.library.example, כדי להבין את הקשר בין פתרון שמות למטמון. השם ולוח הזמנים נוצרו להמחשה, ולא נמדדו תשובות של שירות אמיתי. המטרה היא להפריד בין תהליך מציאת הכתובת ב-DNS, הסיבות להופעה מאוחרת של שינוי ותקלות לאחר פתרון השם.
1. ב-DNS יש כמה סוגי תשובות לכל שם
DNS מספק מידע שקשור לשם מתחם ברשומות מסוגים שונים. A מציין כתובת IPv4 ו-AAAA כתובת IPv6; לשם אחד יכולות להיות גם כמה כתובות. CNAME הוא כינוי שמפנה לשם אחר, MX מציין שרת שמקבל דואר ו-NS מציין שרת שמות סמכותי של האזור המתאים. לכן התשובה לאותו שם יכולה להשתנות לפי סוג הרשומה שהתבקש.
כפי שמבהיר ההסבר של Cloudflare על רשומות DNS, הערך של CNAME הוא שם אחר, ולא כתובת IP. אם נחוצה כתובת, פתרון השם הזה עשוי להימשך. כמו כן, בשם https://www.library.example/books, שם המארח ש-DNS מטפל בו הוא www.library.example. לא רושמים ב-DNS את הנתיב /books או את תוכן הדף. הגדרת CNAME גם אינה יוצרת אוטומטית הפניית HTTP שמשנה את שורת הכתובת בדפדפן.
2. כיצד הפותר הרקורסיבי מגיע לשרת הסמכותי
מנגנון פתרון השמות במכשיר פונה בדרך כלל לפותר הרקורסיבי שהוגדר. הפותר משתמש במידע הנחוץ אם הוא נמצא במטמון, ואם חסר מידע הוא שואל שרתי DNS אחרים ומחזיר תשובה סופית או שגיאה. תקן המונחים של DNS, RFC 9499, מבדיל בין תפקיד הפתרון בשם הפונה לבין שרת סמכותי שמחזיק מידע על האזור שבאחריותו. יש להבין את מקור התשובה לפי התפקיד שבו השרת משיב.
בזרימה פשוטה בלי מטמון ובלי מעבירים באמצע, שרת השורש מפנה את הפותר לשרתי הסיומת העליונה, והם מפנים אותו לשרתים הסמכותיים של האזור המבוקש. מן השרת הסמכותי האחרון מתקבלים הרשומה או הכינוי הדרושים. אין שרת שורש אחד ששומר את כתובות ה-IP של כל האתרים. בפועל אפשר להתחיל ממידע האצלה שכבר נשמר או להעביר לפותר אחר, ולכן לא מוכרחים לחזור על כל הסדר בכל ביקור.
3. TTL הוא זמן שנותר במטמון, ולא שעון עולמי
TTL של רשומה הוא מידע על משך חייה במטמון, שמועבר בשניות. בתשובת מטמון רגילה הזמן שנותר קטן במהלך השמירה. לדוגמה, אם הפותר שמר ב-10:00 כתובת עם TTL של 300 שניות, בתשובה מאותו עותק ב-10:02 יישארו בערך 180 שניות. לוח הזמנים הדמיוני הבא מניח פותר אחד שאינו שואל שוב, מחדש מראש או מגיש תשובות שהתיישנו.
| שעה דמיונית | הכתובת בשרת הסמכותי | פעולת הפותר הזה |
|---|---|---|
| 10:00 | הכתובת הישנה | שומר את הכתובת הישנה עם TTL של 300 שניות |
| 10:01 | השתנתה לכתובת החדשה | לעותק השמור נותרו עדיין 240 שניות |
| 10:03 | הכתובת החדשה | יכול להשתמש שוב בכתובת הישנה במשך 120 השניות שנותרו |
| השאילתה הראשונה אחרי 10:05 | הכתובת החדשה | מניחים שישאל מחדש ויקבל את הכתובת החדשה במקום העותק שפג |
פותר אחר אולי שמר את הרשומה מאוחר יותר, ואולי עדיין לא ראה אותה כלל. זמני החידוש שונים, ולכן ערך TTL אחד אינו קובע רגע שבו כל משתמשי העולם מתחלפים יחד. מטמון יכול להשליך מידע גם לפני פקיעתו, ורענון דף איננו מוחק את העותק אצל הפותר המשותף. TTL מסייע להבין שימוש חוזר בתשובות DNS, ואינו מגבלת זמן של כל חיבור האינטרנט או של רענון המסך.
4. מתי להפחית TTL ואיך נשמרת תשובת ״לא קיים״
מטמון שקיבל קודם את הכתובת הישנה עם TTL של 3,600 שניות אינו מקבל מיד הודעה שהמפעיל הפחית אותו עכשיו ל-60 שניות. בשינוי כתובת מתוכנן כדאי לשנות מראש ולשקול כמה זמן יישארו תשובות שנשמרו עם משך החיים הארוך הקודם. TTL נמוך יכול לגרום לבדיקות שינוי תכופות יותר, אך גם מגדיל את עומס השאילתות ואת התלות בשרת הסמכותי. במקום להחיל מספר קצר זהה על כל שירות, בוחנים יחד את תוכנית השינוי ואת הטיפול בתקלות.
אפשר לשמור במטמון גם NXDOMAIN, שמשמעותו שהשם אינו קיים, וגם NODATA, שבו השם קיים אך אין רשומה מהסוג שהתבקש. תקן המטמון השלילי RFC 2308 מגדיר את משך שמירת התשובה השלילית כקטן מבין TTL של רשומת SOA בשרת הסמכותי לבין ערך MINIMUM של אותה SOA. לכן מיד אחרי הוספת מארח שלא היה קיים עלולה להישאר תשובת ״לא קיים״ קודמת. אם מסתכלים רק על TTL של רשומת A החדשה ומניחים שגם משך התשובה ההיא זהה לו, אפשר להחמיץ את הסיבה.
5. בודקים כשהשם, הסוג והשרת קבועים
רשמו יחד את השם המדויק שנשאל, את הסוג כגון A או AAAA, את שרת ה-DNS שנשאל ואת השעה. אם dig מותקן, אפשר לציין שם וסוג כמו בפקודה dig example.com A. בבירור בעיה אמיתית מחליפים את example.com במארח שרוצים לבדוק. זו דוגמה להליך עבודה; במאמר לא בוצעה הפקודה בפועל ולא נמדד זמן תגובה.
בדקו יחד את מצב התשובה ואת השם, הסוג, הערך וה-TTL שב-ANSWER. כששולחים שוב אותה שאילתה לאותו פותר, בדקו אם TTL יורד, אך אל תקבעו מיד שעלייה בערכו היא שגיאה. ייתכן חידוש מקדים או שמענה הגיע מצומת אחר בין כמה צומתי מטמון. רישום נפרד של A ושל AAAA, בלי לערבב תוצאות, מקל לזהות באיזו משפחת כתובות יש הבדל.
מפעיל יכול להשוות בין תשובת הפותר הרקורסיבי שבשימוש לבין תשובת השרת הסמכותי של האזור שבניהולו, לאותו שם ולאותו סוג. אם יש פער, בודקים לפי הסדר את הזמן שנותר במטמון, את התאמת הנתונים בין השרתים הסמכותיים ואת הגדרות ההאצלה. תשובת פותר ציבורי אחד אינה מעידה על מצב כל המשתמשים. DNS פנימי ברשת חברה או הגדרת DNS נפרדת בדפדפן יכולים לשנות את מסלול הבירור, ולכן מתעדים גם את סביבת החיבור בהשוואה.
6. מפרידים בין תקלות DNS, תקלות חיבור וחריגים
NXDOMAIN הוא מענה שהשם אינו קיים, ו-NODATA הוא מצב שאין בו סוג הרשומה המבוקש. לעומת זאת SERVFAIL הוא כישלון של השרת לטפל בשאילתה, ופקיעת זמן המתנה היא תצפית שלא התקבלה תשובה במשך ההמתנה שהוקצתה. אין לפרש את הכול כ״המתחם נמחק״. תחילה שומרים אם התקבל קוד תשובה ולאיזה שרת פנו, כדי לבחור את הבדיקה הבאה.
תשובה ישנה אחרי ש-TTL חלף אינה תמיד הפרת כללים. שיטת serve-stale שב-RFC 8767 מגדירה כיצד אפשר לשפר זמינות בעזרת מידע שפג במקרים חריגים שבהם אי אפשר לחדש מן השרת הסמכותי. אין פירוש הדבר שכל הפותרים משתמשים באותן הגדרות. במקום לקבוע זמן החלת שינוי לפי TTL יחיד, בודקים את התנהגות הפותר שבו השתמשו באמת.
לבסוף, קבלת כתובת תקינה אינה מבטיחה שהאתר ייפתח. הרשת בדרך לכתובת, תעודת TLS, שרת הווב והיישום הם שלבים נפרדים. אם תשובת DNS היא הכתובת המצופה והדף אינו נפתח, מעבירים את הבירור לשלב החיבור הבא. תיעוד נפרד של תשובת פתרון השם ושל תגובת הווב עוזר לצמצם במדויק את מקום הכשל לפני שמוחקים מטמון דף או משנים הגדרות DNS ללא אבחנה.