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

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

האם אחסון במטמון יעיל? לפני כמה שנים, המחקר הקטן שלי הראה שזה לא מושלם. בואו נסתכל על מצב העניינים הנוכחי.

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

מערך הנתונים המתקבל מורכב מ-1 רשומות (שם, qtype, TTL, חותמת זמן). להלן התפלגות ה-TTL הכוללת (ציר X הוא TTL בשניות):

מלבד בליטה קלה ב-86 (בעיקר עבור רשומות SOA), די ברור שה-TTLs נמצאים בטווח הנמוך. בואו נסתכל מקרוב:

אוקיי, TTLs יותר משעה 1 אינם מובהקים סטטיסטית. אז בואו נתמקד בטווח 0-3600:

רוב ה-TTLs הם בין 0 ל-15 דקות:

הרוב המכריע הוא בין 0 ל-5 דקות:

זה לא מאוד טוב.

התפלגות מצטברת הופכת את הבעיה לעוד יותר ברורה:

למחצית מתגובות ה-DNS יש TTL של דקה אחת או פחות, ושלושה רבעים יש TTL של 1 דקות או פחות.

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

כך שהלקוח יכול למעשה להשתמש בכל ערך עבור, בממוצע, חצי מה-TTL המקורי לפני שליחת בקשה חדשה.

אולי TTLs נמוכים מאוד אלה חלים רק על בקשות חריגות ולא על אתרים פופולריים וממשקי API? בואו נסתכל:

ציר ה-X הוא TTL, ציר ה-Y הוא הפופולריות של שאילתות.

למרבה הצער, השאילתות הפופולריות ביותר הן גם הגרוע ביותר לאחסון במטמון.

בואו נתקרב:

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

מטמון DNS הפך שימושי רק עבור תוכן שאף אחד לא מבקר בו.

שימו לב גם שהתוכנה עשויה בדרכים שונות לפרש TTLs נמוכים.

למה כל כך?

מדוע רשומות DNS מוגדרות ל-TTL נמוך כל כך?

• מאזני עומסים מדור קודם נותרו עם הגדרות ברירת מחדל.
• ישנם מיתוסים שאיזון עומסי DNS תלוי ב-TTL (זה לא נכון - מאז ימי Netscape Navigator, לקוחות בחרו כתובת IP אקראית מתוך קבוצה של RRs וניסו בשקיפות אחרת אם הם לא מצליחים להתחבר)
• מנהלי מערכת רוצים להחיל שינויים באופן מיידי, כך שקל יותר לתכנן אותם.
• המנהל של שרת DNS או מאזן עומסים רואה במשימה שלו פריסה יעילה של התצורה שהמשתמשים מבקשים, ולא לזרז אתרים ושירותים.
• TTLs נמוכים נותנים לך שקט נפשי.
• אנשים מגדירים תחילה TTLs נמוכים לבדיקה ואז שוכחים לשנות אותם.

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

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

שירותי CDN ומאזני עומסים אשמים במידה רבה ב-TTL נמוכים, במיוחד כאשר הם משלבים CNAMEs עם TTLs נמוכים ורשומות עם TTLs נמוכים באותה מידה (אך בלתי תלויים):

$ 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 שניות.

אבל חכה! זה אפילו יותר גרוע. חלק מהפותרים מתנהגים רע מאוד במצב זה עם שני TTLs נמוכים קשורים:

$ drill raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 IN CNAME github.map.fastly.net. github.map.fastly.net. 1 IN A 151.101.16.133

פותר Level3 כנראה פועל על 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 הגון, אבל הוא חסר תועלת לחלוטין. ל-CNAMEs אחרים יש 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

אותה בעיה כמו Firefox ו-TTL יהיו תקועים בשנייה אחת רוב הזמן בעת ​​שימוש ב- Level1 Resolver.

דרופבוקס?

$ drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 IN 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 IN 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 דקות לא תמנע ממשתמשים לגשת לשירות.

עם זאת, זה יקטין משמעותית את זמן האחזור וישפר את הפרטיות והאמינות על ידי הימנעות מבקשות מיותרות.

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

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

כמובן, יש סיבות טובות להגדיר TTLs קטנים עבור רשומות DNS. אבל לא עבור 75% מתעבורת ה-DNS שנותרה כמעט ללא שינוי.

ואם מסיבה כלשהי אתה באמת צריך להשתמש ב-TTLs נמוכים עבור DNS, בו-זמנית ודא ש-Caching לא מופעל באתר שלך. מאותן סיבות.

אם יש לך מטמון DNS מקומי פועל, כגון dnscrypt-proxyהמאפשר לך להגדיר מינימום TTLs, השתמש בפונקציה זו. זה בסדר. שום דבר רע לא יקרה. הגדר את ה-TTL המינימלי לכ-40 דקות (2400 שניות) ושעה אחת. טווח סביר למדי.

מקור: www.habr.com