Aşağı DNS gecikmə sürəti internetə sürətli baxmaq üçün açardır. Onu minimuma endirmək üçün DNS serverlərini diqqətlə seçmək vacibdir və . Ancaq ilk addım faydasız sorğulardan qurtulmaqdır.
Buna görə DNS əvvəlcə yüksək keşlənən bir protokol kimi hazırlanmışdır. Zona administratorları fərdi girişlər üçün yaşayış vaxtı (TTL) təyin edir və həlledicilər lazımsız trafikdən qaçmaq üçün qeydləri yaddaşda saxlayarkən bu məlumatdan istifadə edirlər.
Keşləmə effektivdirmi? Bir neçə il əvvəl, mənim kiçik araşdırmalarım onun mükəmməl olmadığını göstərdi. İndiki vəziyyətə nəzər salaq.
Məlumat toplamaq üçün yamaq etdim cavab üçün TTL dəyərini saxlamaq üçün. O, hər bir daxil olan sorğu üçün qeydlərinin minimum TTL kimi müəyyən edilir. Bu, real trafikin TTL paylanmasının yaxşı icmalını verir, həmçinin fərdi sorğuların populyarlığını nəzərə alır. Serverin yamaqlanmış versiyası bir neçə saat işlədi.
Nəticə məlumat dəsti 1 qeyddən ibarətdir (ad, qtype, TTL, vaxt damğası). Budur ümumi TTL paylanması (X oxu saniyələrdə TTL-dir):
86-də kiçik bir zərbədən başqa (əsasən SOA qeydləri üçün), TTL-lərin aşağı diapazonda olduğu olduqca aydındır. Gəlin daha yaxından nəzər salaq:
Yaxşı, 1 saatdan çox TTL-lər statistik əhəmiyyət kəsb etmir. Sonra 0−3600 diapazonuna diqqət yetirək:
Əksər TTL-lər 0 ilə 15 dəqiqə arasındadır:
Böyük əksəriyyəti 0-dan 5 dəqiqəyə qədərdir:
Çox yaxşı deyil.
Kumulyativ paylama problemi daha da aydınlaşdırır:
DNS cavablarının yarısında 1 dəqiqə və ya daha az TTL, dörddə üçündə isə 5 dəqiqə və ya daha az TTL var.
Ancaq gözləyin, əslində daha pisdir. Axı, bu nüfuzlu serverlərdən TTL-dir. Bununla belə, müştəri həllediciləri (məsələn, marşrutlaşdırıcılar, yerli keşlər) yuxarı axın həlledicilərindən TTL alır və hər saniyə azalır.
Beləliklə, müştəri yeni sorğu göndərməzdən əvvəl hər bir girişdən orta hesabla orijinal TTL-nin yarısı üçün istifadə edə bilər.
Bəlkə bu çox aşağı TTL-lər populyar veb-saytlara və API-lərə deyil, yalnız qeyri-adi sorğulara aiddir? Gəlin nəzər salaq:
X oxu TTL, Y oxu isə sorğuların populyarlığıdır.
Təəssüf ki, ən populyar sorğular da keşləmə üçün ən pisdir.
Yaxınlaşdıraq:
Hökm: həqiqətən pisdir. Onsuz da əvvəllər pis idi, amma daha da pisləşdi. DNS keşləmə faktiki olaraq yararsız hala gəldi. Daha az insan öz ISP-nin DNS həlledicisindən istifadə etdikcə (üzrlü səbəblərə görə), gecikmənin artması daha nəzərə çarpır.
DNS keşi yalnız heç kimin ziyarət etmədiyi məzmun üçün faydalı oldu.
Nəzərə alın ki, proqram təminatı ola bilər aşağı TTL-ləri şərh edin.
Niyə belədir?
Niyə DNS qeydləri belə aşağı TTL-ə təyin edilib?
- Köhnə yük balanslaşdırıcıları defolt parametrlərlə qaldı.
- DNS yük balansının TTL-dən asılı olduğuna dair miflər var (bu doğru deyil - Netscape Navigator günlərindən bəri müştərilər RR dəstindən təsadüfi bir IP ünvanı seçiblər və qoşula bilmirlərsə, şəffaf şəkildə başqasını sınadılar)
- Administratorlar dəyişiklikləri dərhal tətbiq etmək istəyirlər, ona görə də planlaşdırmaq daha asandır.
- DNS serverinin və ya yük balanslaşdırıcısının administratoru öz vəzifəsini istifadəçilərin tələb etdiyi konfiqurasiyanı səmərəli şəkildə yerləşdirmək və saytları və xidmətləri sürətləndirmək kimi görür.
- Aşağı TTL-lər sizə rahatlıq verir.
- İnsanlar əvvəlcə sınaq üçün aşağı TTL təyin edir və sonra onları dəyişdirməyi unudurlar.
Mən “failover”ı siyahıya daxil etmədim, çünki bu, getdikcə daha az aktuallaşır. Hər şey tamamilə pozulduqda səhv səhifəsini göstərmək üçün istifadəçiləri başqa şəbəkəyə yönləndirməlisinizsə, 1 dəqiqədən çox gecikmə məqbuldur.
Bundan əlavə, bir dəqiqəlik TTL o deməkdir ki, nüfuzlu DNS serverləri 1 dəqiqədən çox bloklanırsa, başqa heç kim asılı xidmətlərə daxil ola bilməyəcək. Səbəb konfiqurasiya xətası və ya hackdirsə, artıqlıq kömək etməyəcək. Digər tərəfdən, ağlabatan TTL-lərlə, bir çox müştəri əvvəlki konfiqurasiyadan istifadə etməyə davam edəcək və heç vaxt heç nə görməyəcək.
CDN xidmətləri və yük balanslaşdırıcıları əsasən aşağı TTL-lərə görə günahkardırlar, xüsusən də onlar aşağı TTL-lərlə CNAME-ləri və eyni dərəcədə aşağı (lakin müstəqil) TTL-lərə malik qeydləri birləşdirdikdə:
$ 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 və ya A qeydlərindən hər hansı birinin müddəti bitdikdə yeni sorğu göndərilməlidir. Hər ikisində 30 saniyəlik TTL var, lakin bu eyni deyil. Faktiki orta TTL 15 saniyə olacaq.
Amma gözləyin! Daha da pisdir. Bəzi həlledicilər bu vəziyyətdə iki əlaqəli aşağı TTL ilə çox pis davranırlar:
$ drill raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 CNAME-də github.map.fastly.net. github.map.fastly.net. 1 IN A 151.101.16.133
Səviyyə 3 həlledicisi, ehtimal ki, BIND-də işləyir. Bu sorğunu göndərməyə davam etsəniz, həmişə 1 TTL qaytarılacaq. Əsasən, raw.githubusercontent.com heç vaxt keşlənmir.
Çox məşhur bir domenlə belə bir vəziyyətin başqa bir nümunəsidir:
$ 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
Ən azı üç CNAME qeydi. Ay. Birinin layiqli TTL-si var, amma tamamilə yararsızdır. Digər CNAME-lərin ilkin TTL müddəti 60 saniyədir, lakin domenlər üçün akamai.net maksimum TTL 20 saniyədir və onların heç biri fazada deyil.
Apple cihazlarını daim sorğulayan domenlər haqqında nə demək olar?
$ 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 və TTL ilə eyni problem Level1 həlledicidən istifadə edərkən çox vaxt 3 saniyədə ilişib qalacaq.
Dropbox?
$ drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 CNAME client.dropbox-dns.com-da. 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-da. client.dropbox-dns.com. 1 IN A 162.125.64.3
Səsyazmada safebrowsing.googleapis.com TTL dəyəri Facebook domenləri kimi 60 saniyədir. Və yenə də müştəri baxımından bu dəyərlər yarıya endirilir.
Minimum TTL təyin etmək necədir?
Ad, sorğu növü, TTL və ilkin saxlanılan vaxt damğasından istifadə edərək, vaxtı keçmiş keş girişi səbəbindən göndərilən lazımsız sorğuların həcmini qiymətləndirmək üçün keşləmə həlledicisindən keçən 1,5 milyon sorğunun simulyasiyası üçün skript yazdım.
Müraciətlərin 47,4%-i mövcud qeydin müddəti bitdikdən sonra edilib. Bu, əsassız yüksəkdir.
Minimum TTL təyin edilərsə, keşləşdirməyə necə təsir edəcək?
X oxu minimum TTL dəyərləridir. Mənbə TTL-ləri bu dəyərdən yuxarı olan qeydlər təsirlənmir.
Y oxu artıq keşlənmiş girişi olan, lakin müddəti bitmiş və yeni sorğu göndərən müştəridən gələn sorğuların faizidir.
Sadəcə olaraq minimum TTL-ni 47 dəqiqəyə təyin etməklə “əlavə” sorğuların payı 36%-dən 5%-ə endirilir. Minimum TTL-ni 15 dəqiqəyə təyin etməklə, bu sorğuların sayı 29%-ə enir. 1 saatlıq minimum TTL onları 17%-ə qədər azaldır. Əhəmiyyətli fərq!
Server tərəfində heç nəyi dəyişməyə, əksinə müştəri DNS keşlərində (marşrutlaşdırıcılar, yerli həlledicilər) minimum TTL-ni təyin etməyə nə deyirsiniz?
Tələb olunan sorğuların sayı minimum TTL 47 dəqiqə ilə 34%-dən 5%-ə, minimum 25 dəqiqə ilə 15%-ə və minimum 13 saat ilə 1%-ə enir. Bəlkə də 40 dəqiqə optimaldır.
Bu kiçik dəyişikliyin təsiri çox böyükdür.
Nəticələri nələrdir?
Əlbəttə ki, xidmət müştərilərdən ən son DNS qeydlərindən istifadə etməyi tələb edən yeni bulud provayderinə, yeni serverə, yeni şəbəkəyə köçürülə bilər. Və kifayət qədər kiçik bir TTL belə bir keçidi hamar və hiss olunmaz şəkildə etməyə kömək edir. Lakin yeni infrastruktura keçidlə heç kim müştərilərin 1 dəqiqə, 5 dəqiqə və ya 15 dəqiqə ərzində yeni DNS qeydlərinə keçməsini gözləmir. Minimum TTL-nin 40 dəqiqə əvəzinə 5 dəqiqə təyin edilməsi istifadəçilərin xidmətə daxil olmasına mane olmayacaq.
Bununla belə, bu, gecikməni əhəmiyyətli dərəcədə azaldacaq və lazımsız sorğulardan qaçaraq məxfilik və etibarlılığı artıracaq.
Təbii ki, RFC-lər deyirlər ki, TTL-yə ciddi əməl edilməlidir. Amma reallıq budur ki, DNS sistemi həddindən artıq səmərəsiz hala düşüb.
Əgər nüfuzlu DNS serverləri ilə işləyirsinizsə, lütfən, TTL-lərinizi yoxlayın. Həqiqətən belə gülünc dərəcədə aşağı dəyərlərə ehtiyacınız varmı?
Əlbəttə ki, DNS qeydləri üçün kiçik TTL təyin etmək üçün yaxşı səbəblər var. Amma faktiki olaraq dəyişməz qalan DNS trafikinin 75%-i üçün deyil.
Əgər nədənsə həqiqətən DNS üçün aşağı TTL-lərdən istifadə etməlisinizsə, eyni zamanda saytınızda keşləmənin aktiv olmadığından əmin olun. Eyni səbəblərə görə.
Yerli DNS önbelleğiniz varsa, məsələn minimum TTL-ləri təyin etməyə imkan verir, bu funksiyadan istifadə edin. Bu yaxşıdır. Pis heç nə olmayacaq. Minimum TTL-ni təxminən 40 dəqiqə (2400 saniyə) və 1 saata təyin edin. Kifayət qədər məqbul diapazon.
Mənbə: www.habr.com