Latența DNS scăzută este cheia pentru navigarea rapidă pe internet. Pentru a o minimiza, este important să selectați cu atenție serverele DNS și . Dar primul pas este să scapi de interogările inutile.
Acesta este motivul pentru care DNS a fost conceput inițial ca un protocol care poate fi stocat în cache. Administratorii zonei stabilesc un timp de viață (TTL) pentru intrările individuale, iar rezolutorii folosesc aceste informații atunci când stochează intrările în memorie pentru a evita traficul inutil.
Este eficientă stocarea în cache? Acum câțiva ani, mica mea cercetare a arătat că nu era perfectă. Să aruncăm o privire asupra situației actuale.
Pentru a colecta informații pe care le-am corectat pentru a salva valoarea TTL pentru răspuns. Este definit ca TTL minim al înregistrărilor sale pentru fiecare cerere primită. Acest lucru oferă o imagine de ansamblu bună asupra distribuției TTL a traficului real și, de asemenea, ia în considerare popularitatea solicitărilor individuale. Versiunea corectată a serverului a funcționat câteva ore.
Setul de date rezultat constă din 1 de înregistrări (nume, qtype, TTL, timestamp). Iată distribuția generală TTL (axa X este TTL în secunde):
În afară de o creștere minoră la 86 (mai ales pentru înregistrările SOA), este destul de clar că TTL-urile sunt în intervalul scăzut. Să aruncăm o privire mai atentă:
Bine, TTL-urile mai mari de 1 oră nu sunt semnificative statistic. Apoi să ne concentrăm pe intervalul 0−3600:
Majoritatea TTL-urilor sunt de la 0 la 15 minute:
Marea majoritate sunt de la 0 la 5 minute:
Nu e foarte bine.
Distribuția cumulativă face problema și mai evidentă:
Jumătate dintre răspunsurile DNS au un TTL de 1 minut sau mai puțin, iar trei sferturi au un TTL de 5 minute sau mai puțin.
Dar stai, de fapt e mai rău. La urma urmei, acesta este TTL de la servere autorizate. Cu toate acestea, soluțiile client (de exemplu, routere, cache-uri locale) primesc un TTL de la rezolutorii din amonte și scade în fiecare secundă.
Deci, clientul poate folosi efectiv fiecare intrare pentru, în medie, jumătate din TTL original înainte de a trimite o nouă solicitare.
Poate că aceste valori TTL foarte scăzute se aplică numai solicitărilor neobișnuite și nu site-urilor web și API-urilor populare? Să aruncăm o privire:
Axa X este TTL, axa Y este popularitatea interogărilor.
Din păcate, cele mai populare interogări sunt, de asemenea, cele mai prost de stocat în cache.
Să mărim:
Verdict: este foarte rău. Era deja rău înainte, dar a devenit și mai rău. Memorarea în cache DNS a devenit practic inutilă. Pe măsură ce mai puțini oameni folosesc rezolutorul DNS al ISP-ului lor (din motive întemeiate), creșterea latenței devine mai vizibilă.
Memorarea în cache DNS a devenit utilă doar pentru conținutul pe care nu îl vizitează nimeni.
Vă rugăm să rețineți că software-ul poate interpretați TTL-uri scăzute.
De ce așa?
De ce înregistrările DNS sunt setate la un TTL atât de scăzut?
- Echilibratoarele de încărcare vechi au rămas cu setări implicite.
- Există mituri conform cărora echilibrarea încărcăturii DNS depinde de TTL (acest lucru nu este adevărat - din zilele Netscape Navigator, clienții au ales o adresă IP aleatorie dintr-un set de RR-uri și au încercat în mod transparent alta dacă nu se pot conecta)
- Administratorii doresc să aplice modificări imediat, astfel încât este mai ușor de planificat.
- Administratorul unui server DNS sau al unui echilibrator de încărcare vede ca sarcina sa implementează eficient configurația solicitată de utilizatori și nu accelerează site-urile și serviciile.
- TTL-urile scăzute vă oferă liniște sufletească.
- Oamenii setează inițial valori TTL scăzute pentru testare și apoi uită să le schimbe.
Nu am inclus „failover” în listă pentru că devine din ce în ce mai puțin relevant. Dacă trebuie să redirecționați utilizatorii către o altă rețea doar pentru a afișa o pagină de eroare atunci când absolut totul s-a stricat, o întârziere de mai mult de 1 minut este probabil acceptabilă.
În plus, un TTL de un minut înseamnă că, dacă serverele DNS autorizate sunt blocate mai mult de 1 minut, nimeni altcineva nu va putea accesa serviciile dependente. Și redundanța nu va ajuta dacă cauza este o eroare de configurare sau un hack. Pe de altă parte, cu TTL rezonabile, mulți clienți vor continua să folosească configurația anterioară și nu vor observa niciodată nimic.
Serviciile CDN și echilibratorii de încărcare sunt în mare parte de vină pentru TTL-uri scăzute, mai ales atunci când combină CNAME-uri cu TTL-uri scăzute și înregistrări cu TTL-uri la fel de scăzute (dar independente):
$ 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
Ori de câte ori CNAME sau oricare dintre înregistrările A expiră, trebuie trimisă o nouă solicitare. Ambele au un TTL de 30 de secunde, dar nu este același lucru. TTL mediu real va fi de 15 secunde.
Dar asteapta! E chiar mai rău. Unii rezolutori se comportă foarte rău în această situație cu două TTL-uri scăzute asociate:
$ drill raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 ÎN CNAME github.map.fastly.net. github.map.fastly.net. 1 ÎN A 151.101.16.133
Soluția Level3 rulează probabil pe BIND. Dacă continuați să trimiteți această solicitare, un TTL de 1 va fi întotdeauna returnat. raw.githubusercontent.com nu este niciodată în cache.
Iată un alt exemplu de astfel de situație cu un domeniu foarte popular:
$ 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
Cel puțin trei înregistrări CNAME. Ay. Unul are un TTL decent, dar este complet inutil. Alte CNAME au un TTL inițial de 60 de secunde, dar pentru domenii akamai.net TTL maxim este de 20 de secunde și niciunul dintre ele nu este în fază.
Dar domeniile care sondajează în mod constant dispozitivele Apple?
$ 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
Aceeași problemă ca și Firefox și TTL vor fi blocate la 1 secundă de cele mai multe ori când se utilizează soluția Level3.
Dropbox?
$ drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 ÎN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 ÎN UN 162.125.67.3 $ drill client.dropbox.com @4.2.2.2 client.dropbox.com. 1 ÎN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 ÎN A 162.125.64.3
La înregistrare safebrowsing.googleapis.com Valoarea TTL este de 60 de secunde, ca și domeniile Facebook. Și, din nou, din punctul de vedere al clientului, aceste valori sunt înjumătățite.
Ce zici de setarea unui TTL minim?
Folosind numele, tipul cererii, TTL și marcajul de timp stocat inițial, am scris un script pentru a simula 1,5 milioane de solicitări care trec printr-un solutor de cache pentru a estima volumul de solicitări inutile trimise din cauza unei intrări în cache expirate.
47,4% dintre solicitări au fost făcute după ce expirase o înregistrare existentă. Acest lucru este nerezonabil de mare.
Care va fi impactul asupra stocării în cache dacă este setat TTL-ul minim?
Axa X reprezintă valorile TTL minime. Înregistrările cu TTL sursă peste această valoare nu sunt afectate.
Axa Y reprezintă procentul de solicitări de la un client care are deja o intrare în cache, dar a expirat și face o nouă solicitare.
Ponderea solicitărilor „în plus” este redusă de la 47% la 36% prin simpla setare a TTL minim la 5 minute. Setând TTL minim la 15 minute, numărul acestor solicitări scade la 29%. Un TTL minim de 1 oră le reduce la 17%. Diferenta semnificativa!
Ce zici de a nu schimba nimic din partea serverului, ci de a seta TTL minim în cache-urile DNS ale clientului (routere, soluții locale)?
Numărul de cereri necesare scade de la 47% la 34% cu un TTL minim de 5 minute, la 25% cu un minim de 15 minute și la 13% cu un minim de 1 oră. Poate 40 de minute este optim.
Impactul acestei mici schimbări este enorm.
Care sunt consecințele?
Desigur, serviciul poate fi mutat la un nou furnizor de cloud, un nou server, o nouă rețea, solicitând clienților să folosească cele mai recente înregistrări DNS. Și un TTL destul de mic ajută la realizarea unei astfel de tranziții fără probleme și imperceptibil. Dar, odată cu trecerea la o nouă infrastructură, nimeni nu se așteaptă ca clienții să migreze la noi înregistrări DNS în decurs de 1 minut, 5 minute sau 15 minute. Setarea TTL minim la 40 de minute în loc de 5 minute nu va împiedica utilizatorii să acceseze serviciul.
Cu toate acestea, acest lucru va reduce semnificativ latența și va îmbunătăți confidențialitatea și fiabilitatea prin evitarea solicitărilor inutile.
Desigur, RFC-urile spun că TTL trebuie respectat cu strictețe. Dar realitatea este că sistemul DNS a devenit prea ineficient.
Dacă lucrați cu servere DNS autorizate, vă rugăm să vă verificați TTL-urile. Chiar ai nevoie de valori atât de ridicol de mici?
Desigur, există motive întemeiate pentru a seta TTL-uri mici pentru înregistrările DNS. Dar nu pentru cei 75% din traficul DNS care rămâne practic neschimbat.
Și dacă dintr-un motiv oarecare trebuie să utilizați TTL-uri scăzute pentru DNS, asigurați-vă, în același timp, că site-ul dvs. nu are activată memoria cache. Din aceleași motive.
Dacă aveți un cache DNS local care rulează, cum ar fi care vă permite să setați valori TTL minime, utilizați această funcție. Este în regulă. Nu se va întâmpla nimic rău. Setați TTL minim la aproximativ 40 de minute (2400 de secunde) și 1 oră. Un interval destul de rezonabil.
Sursa: www.habr.com