השהיית DNS נמוכה היא גורם מפתח לגלישה מהירה. כדי למזער אותה, חשוב לבחור בקפידה שרתי DNS ו אבל הדבר הראשון שאתה צריך לעשות הוא להיפטר משאילתות חסרות תועלת.
זו הסיבה ש-DNS תוכנן במקור כפרוטוקול הניתן לאחסון במטמון גבוה. מנהלי אזורים קובעים זמן חיים (TTL) עבור רשומות בודדות, ורזולוטורים משתמשים במידע זה בעת אחסון רשומות בזיכרון כדי למנוע תעבורה מיותרת.
האם אחסון במטמון יעיל? לפני כמה שנים, מחקר קטן שערכתי הראה שהוא אינו מושלם. בואו נבחן את מצב העניינים הנוכחי.
כדי לאסוף מידע שתיקנתי לאחסן את ערך ה-TTL עבור התגובה. הוא מוגדר כערך ה-TTL המינימלי של הרשומות שלו, עבור כל בקשה נכנסת. זה נותן סקירה טובה של התפלגות ה-TTL של תעבורה אמיתית, וגם לוקח בחשבון את הפופולריות של בקשות בודדות. הגרסה המתוקנת של השרת עבדה במשך מספר שעות.
מערך הנתונים שנוצר מורכב מ-1 רשומות (שם, סוג q, TTL, חותמת זמן). הנה התפלגות ה-TTL הכוללת (ציר ה-x הוא TTL בשניות):
מלבד עלייה קלה ב-86 (בעיקר עבור רשומות SOA), די ברור ש-TTLs נמצאים בטווח הנמוך. בואו נסתכל מקרוב:
אוקיי, ערכי TTL מעל שעה הם חסרי משמעות סטטיסטית. בואו נתמקד בטווח 1-0 אם כן:
רוב ערכי ה-TTL הם בין 0 ל-15 דקות:
הרוב המכריע הוא בין 0 ל-5 דקות:
זה לא ממש טוב.
התפלגות מצטברת הופכת את הבעיה לברורה עוד יותר:
למחצית מתגובות ה-DNS יש TTL של דקה אחת או פחות, ולשלושה רבעים יש TTL של 1 דקות או פחות.
אבל רגע, זה בעצם גרוע יותר. זהו ה-TTL מהשרתים הסמכותיים. עם זאת, רזולוטורים של לקוחות (למשל נתבים, מטמונים מקומיים) מקבלים את ה-TTL רזולוטורים במעלה הזרם, והוא יורד בכל שנייה.
לפיכך, הלקוח יכול למעשה להשתמש בכל רשומה, בממוצע, במחצית מה-TTL המקורי לפני שליחת בקשה חדשה.
אולי ערכי ה-TTL הנמוכים מאוד הללו משפיעים רק על בקשות יוצאות דופן ולא על אתרים ו-APIs פופולריים? בואו נסתכל:
ציר ה-X הוא TTL, ציר ה-Y הוא פופולריות השאילתה.
למרבה הצער, השאילתות הפופולריות ביותר הן גם אלו שמאוחסנות במטמון בצורה הגרועה ביותר.
בואו נצמצם:
פסק דין: זה ממש גרוע. זה כבר היה גרוע, וזה החמיר. אחסון במטמון DNS הפך כמעט חסר תועלת. ככל שפחות אנשים משתמשים ברזולוטור ה-DNS של ספק האינטרנט שלהם (מסיבות טובות), העלייה ב-latency הופכת בולטת יותר.
אחסון במטמון DNS הפך שימושי רק עבור תוכן שאף אחד לא מבקר בו.
שימו לב גם כי התוכנה עשויה לפרש TTLs נמוכים.
למה כל כך?
מדוע רשומות DNS מוגדרות ל-TTL כל כך קטן?
- מאזני עומסים מדור קודם נשארים עם הגדרות ברירת המחדל.
- ישנם מיתוסים לפיה איזון עומסים של DNS תלוי ב-TTL (זה לא נכון - מאז Netscape Navigator, לקוחות בוחרים כתובת IP אקראית מקבוצת ה-RR ומנסים אחרת באופן שקוף אם הם לא מצליחים להתחבר).
- מנהלים רוצים להחיל שינויים באופן מיידי, כך שקל יותר לתכנן.
- מנהל של שרת DNS או מאזן עומסים רואה את משימתו כפריסת יעילות של התצורה המבוקשת על ידי המשתמשים, ולא כהאצת פעולת האתרים והשירותים.
- TTL נמוך נותן שקט נפשי.
- אנשים בהתחלה קובעים ערכי TTL נמוכים לבדיקות ואז שוכחים לשנות אותם.
לא כללתי את המונח "failover" כי זה הופך לפחות ופחות רלוונטי. אם אתם צריכים להפנות משתמשים לרשת אחרת רק כדי להציג דף שגיאה כאשר כל השאר מקולקל, עיכוב של יותר מדקה כנראה מקובל.
בנוסף, TTL של דקה אחת פירושו שאם שרתי DNS סמכותיים חסומים למשך יותר מדקה, אף אחד אחר לא יוכל לגשת לשירותים תלויים. ויתירות לא תעזור אם הסיבה היא שגיאת תצורה או פריצה. מצד שני, עם TTL סבירים, לקוחות רבים ימשיכו להשתמש בתצורה הקודמת ולא ישימו לב לעולם.
ערכי TTL נמוכים הם במידה רבה אשמתם של שירותי CDN ומאזני עומסים, במיוחד כאשר הם משלבים ערכי CNAME עם ערכי TTL נמוכים ורשומות עם ערכי TTL נמוכים באותה מידה (אך בלתי תלויים):
$ drill raw.githubusercontent.com raw.githubusercontent.com. 9 IN CNAME github.map.fastly.net. github.map.fastly.net. 20 IN A 151.101.128.133 github.map.fastly.net. 20 IN A 151.101.192.133 github.map.fastly.net. 20 IN A 151.101.0.133 github.map.fastly.net. 20 IN A 151.101.64.133
בכל פעם ש-CNAME או כל אחת מרשומות A פג תוקף, יש לשלוח בקשה חדשה. לשניהם יש TTL של 30 שניות, אך הם אינם זהים. ה-TTL הממוצע בפועל יהיה 15 שניות.
אבל רגע! זה מחמיר. חלק מהרזולוטורים מתנהגים בצורה גרועה מאוד במצב הזה עם שני ערכי TTL נמוכים מקושרים:
$ drill raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 ב-CNAME github.map.fastly.net. github.map.fastly.net. 1 ב-A 151.101.16.133
כנראה שה-Level3 resolver פועל על BIND. אם תמשיכו לשלוח שאילתה זו, היא תמיד תחזיר TTL של 1. בעיקרון, raw.githubusercontent.com מעולם לא נשמר במטמון.
הנה דוגמה נוספת למצב הזה עם דומיין פופולרי מאוד:
$ drill detectportal.firefox.com @1.1.1.1 detectportal.firefox.com. 25 IN CNAME detectportal.prod.mozaws.net. detectportal.prod.mozaws.net. 26 IN CNAME detectportal.firefox.com-v2.edgesuite.net. detectportal.firefox.com-v2.edgesuite.net. 10668 IN CNAME a1089.dscd.akamai.net. a1089.dscd.akamai.net. 10 IN A 104.123.50.106 a1089.dscd.akamai.net. 10 IN A 104.123.50.88
לפחות שלוש רשומות CNAME. אוי. לאחת יש TTL סביר, אבל היא חסרת תועלת לחלוטין. לשאר רשומות ה-CNAME יש TTL התחלתי של 60 שניות, אבל עבור דומיינים. akamai.net ה-TTL המקסימלי הוא 20 שניות ואף אחד מהם אינו בפאזה.
מה לגבי דומיינים שסורקים כל הזמן מכשירי אפל?
$ drill 1-courier.push.apple.com @4.2.2.2 1-courier.push.apple.com. 1253 IN CNAME 1.courier-push-apple.com.akadns.net. 1.courier-push-apple.com.akadns.net. 1 IN CNAME gb-courier-4.push-apple.com.akadns.net. gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.84 gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.85
אותה בעיה כמו שפיירפוקס ו-TTL נתקעים בשנייה אחת ברוב הזמן בעת שימוש ברזולוטור Level1.
דרופבוקס?
$ drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 בתוך CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 בתוך A 162.125.67.3 $ drill client.dropbox.com @4.2.2.2 client.dropbox.com. 1 בתוך CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 בתוך A 162.125.64.3
בהקלטה safebrowsing.googleapis.com ערך TTL של 60 שניות, בדיוק כמו דומיינים בפייסבוק. ושוב, מנקודת מבטו של הלקוח, ערכים אלה מצטמצמים בחצי.
מה לגבי קביעת TTL מינימלי?
באמצעות השם, סוג הבקשה, ה-TTL וחותמת הזמן המאוחסנת במקור, כתבתי סקריפט כדי לדמות 1,5 מיליון בקשות שעוברות דרך פותר מטמון כדי להעריך את כמות הבקשות הנוספות שנשלחו עקב ערך מטמון שפג תוקפו.
47,4% מהבקשות הוגשו לאחר שפג תוקפו של השיא הקיים. זהו מספר גבוה באופן בלתי סביר.
מה תהיה ההשפעה על אחסון במטמון אם יוגדר TTL מינימלי?
ציר ה-X הוא ערכי ה-TTL המינימליים. רשומות עם ערכי TTL גולמיים מעל ערך זה אינן מושפעות.
ציר ה-Y הוא אחוז הבקשות מלקוח שכבר יש לו ערך מאוחסן במטמון, אך הוא פג תוקפו ומבצע בקשה חדשה.
חלקן של בקשות "נוספות" מצטמצם מ-47% ל-36% פשוט על ידי הגדרת זמן ה-TTL המינימלי ל-5 דקות. הגדרת זמן ה-TTL המינימלי ל-15 דקות מפחיתה את מספר הבקשות הללו ל-29%. זמן TTL מינימלי של שעה אחת מצמצם אותן ל-1%. הבדל משמעותי!
מה דעתך לא לשנות דבר בצד השרת, אלא להגדיר ערכי TTL מינימליים במטמוני DNS של הלקוח (נתבים, רזולוורים מקומיים)?
מספר הבקשות הנדרשות יורד מ-47% ל-34% כאשר מגדירים את זמן ה-TTL המינימלי ל-5 דקות, ל-25% עם מינימום של 15 דקות, ול-13% עם מינימום של שעה. אולי 1 דקות זה אופטימלי.
ההשפעה של שינוי מינימלי זה היא עצומה.
מה ההשלכות?
בוודאי, ניתן להעביר שירות לספק ענן חדש, שרת חדש, רשת חדשה, ולדרוש מהלקוחות להשתמש ברשומות ה-DNS העדכניות ביותר. ו-TTL קטן מספיק עוזר להפוך את המעבר הזה לחלק וחלק. אבל כשמעבירים לתשתית חדשה, אף אחד לא מצפה מהלקוחות לעבור לרשומות ה-DNS החדשות תוך דקה, 1 דקות או 5 דקות. הגדרת ה-TTL המינימלי ל-15 דקות במקום 40 דקות לא תמנע ממשתמשים גישה לשירות.
עם זאת, הדבר יפחית משמעותית את ההשהיה וישפר את הפרטיות והאמינות על ידי הימנעות מבקשות מיותרות.
נכון, רשויות ה-RFC אומרות שיש לאכוף בקפדנות את חוקי ה-TTL. אבל המציאות היא שמערכת ה-DNS הפכה ללא יעילה מדי.
אם אתם עובדים עם שרתי DNS סמכותיים, אנא בדקו את ערכי ה-TTL שלכם. האם אתם באמת צריכים ערכים כל כך נמוכים בצורה מגוחכת?
כמובן, ישנן סיבות טובות לקבוע ערכי TTL נמוכים עבור רשומות DNS. אבל לא עבור 75% מתנועת ה-DNS שכמעט ולא משתנה.
ואם מסיבה כלשהי אתם באמת צריכים להשתמש ב-TTL נמוכים עבור DNS, ודאו גם שהאתר שלכם לא מפעיל אחסון במטמון. מאותן סיבות.
אם פועל לך מטמון DNS מקומי, כגון , המאפשר לך להגדיר את ה-TTL המינימלי, השתמש בפונקציה זו. זה נורמלי. שום דבר רע לא יקרה. הגדר את ה-TTL המינימלי לטווח שבין 40 דקות (2400 שניות) לשעה. טווח סביר.
מקור: www.habr.com
