O latență DNS scăzută este un factor cheie pentru o funcționare rapidă pe internet. Pentru a o minimiza, este important să alegem cu atenție serverele DNS și . Dar mai întâi trebuie să eliminăm cererile inutile.
De aceea, DNS a fost creat inițial ca un protocol cu un grad ridicat de cache. Administratorii de zone stabilesc timpul de viață (TTL) pentru înregistrările individuale, iar rezolvatoarele folosesc aceste informații pentru a stoca înregistrările în memorie, evitând astfel traficul nedorit.
Este eficient cachingul? Cu ceva timp în urmă, o mică cercetare a arătat că nu este perfect. Să ne uităm la situația actuală.
Pentru a aduna informații, am patch-uit pentru a păstra valoarea TTL pentru răspuns. Aceasta este definită ca fiind TTL minim al înregistrărilor sale, pentru fiecare cerere primită. Acest lucru oferă o bună imagine de ansamblu asupra distribuției TTL în traficul real și ia în considerare popularitatea cererilor individuale. Versiunea patch-uită a serverului a funcționat câteva ore.
Setul de date rezultat constă din 1 583 579 înregistrări (name, qtype, TTL, timestamp). Iată distribuția generală a TTL (axa X reprezintă TTL în secunde):
Dacă excludem un mic vârf la 86 400 (în principal pentru înregistrările SOA), este destul de evident că TTL-ul se află în intervale scăzute. Să ne uităm mai atent:
Bine, TTL-urile de peste 1 oră sunt statistic nesemnificative. Atunci să ne concentrăm pe intervalul 0–3600:
Majoritatea TTL-urilor sunt între 0 și 15 minute:
Cea mai mare parte se încadrează între 0 și 5 minute:
Acest lucru nu este prea bun.
Distribuția acumulativă face problema și mai evidentă:
În jumătate din răspunsurile DNS, TTL-ul este de 1 minut sau mai puțin, iar la trei sferturi – 5 minute sau mai puțin.
Dar așteaptă, de fapt, lucrurile sunt chiar mai rele. Acesta este TTL-ul de la serverele autoritative. Cu toate acestea, rezolvatoarele clientului (de exemplu, routerele, cache-urile locale) primesc TTL de la rezolvatoarele superioare, iar acesta scade cu fiecare secundă.
Astfel, clientul poate folosi, de fapt, fiecare înregistrare, în medie, timp de jumătate din TTL-ul original, după care va trimite o nouă cerere.
Poate că aceste TTL-uri foarte scăzute se referă doar la cereri neobișnuite, nu la site-uri web populare și API-uri? Să vedem:
Axa X reprezintă TTL-ul, axa Y reprezintă popularitatea cererilor.
Din păcate, cele mai populare cereri sunt de asemenea cele mai puțin cache-uite.
Să ne apropiem:
Verdict: things are really bad. It was already bad before, and now it has gotten even worse. DNS caching has become practically useless. As fewer people use their provider's DNS resolver (for valid reasons), the increased latency becomes more noticeable.
DNS caching has only become useful for content that no one visits.
Also note that the software can differently.
Why is that?
Why is such a low TTL set for DNS records?
- Outdated load balancers remain with default settings.
- There are myths that DNS load balancing depends on TTL (this is not true - since the days of Netscape Navigator, clients randomly choose an IP address from the RR set and transparently try another if they can't connect)
- Administrators want to apply changes immediately, so it's easier to plan.
- The DNS server or load balancer administrator sees their task as effectively deploying the configuration requested by users, not speeding up websites and services.
- Low TTLs provide peace of mind.
- People initially set low TTLs for testing and then forget to change them.
I haven't included 'failure handling' on the list, as it is becoming less relevant. If it's necessary to redirect users to another network just to display an error page when everything else has completely broken, a delay of more than one minute is probably acceptable.
Moreover, a one-minute TTL means that if authoritative DNS servers are blocked for more than a minute, no one else can access dependent services. And redundancy won't help if the cause is a configuration error or a hack. On the other hand, with reasonable TTLs, many clients will continue using the previous configuration and may never notice anything.
Low TTLs are largely blamed on CDN services and load balancers, especially when they combine CNAMEs with low TTLs and records with equally low (but independent) 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
Ori de câte ori expiră CNAME sau orice înregistrare A, trebuie trimisă o nouă solicitare. Ambele au un TTL de 30 de secunde, dar nu coincide. TTL-ul mediu real va fi de 15 secunde.
Dar așteaptă! E și mai rău. Unele rezolvatoare se comportă foarte prost în această situație cu două TTL-uri scăzute corelate:
$ 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
Rezolvatorul Level3 funcționează probabil pe BIND. Dacă continui să trimiți această solicitare, va returna mereu un TTL egal cu 1. Practic, raw.githubusercontent.com nu este niciodată cache-uit.
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. Of! Una are un TTL decent, dar acesta este complet inutil. În alte CNAME, TTL-ul inițial este de 60 de secunde, dar pentru domeniile akamai.net TTL-ul maxim este de 20 de secunde, și niciunul dintre ele nu este sincronizat.
Ce zici de domeniile care interoghează 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 la Firefox, și TTL-ul va rămâne de multe ori blocat la 1 secundă folosind rezolvatorul Level3.
Dropbox?
$ 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 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 IN A 162.125.64.3
La înregistrare safebrowsing.googleapis.com valoarea TTL este de 60 de secunde, la fel ca și pentru domeniile Facebook. Și, din nou, din perspectiva clientului, aceste valori se reduc la jumătate.
Ce zici de stabilirea unui TTL minim?
Folosind numele, tipul de solicitare, TTL-ul și timestamp-ul inițial salvat, am scris un script pentru a simula 1,5 milioane de solicitări care trec printr-un rezolvator de cache, pentru a evalua volumul de cereri inutile trimise din cauza unei înregistrări de cache expirate.
47,4% dintre solicitări au fost făcute după expirarea înregistrării existente. Acest procent este inacceptabil de ridicat.
Care va fi impactul asupra caching-ului dacă se stabilește un TTL minim?
Axa X reprezintă valorile minime TTL. Înregistrările cu TTL inițial mai mari decât această valoare nu sunt afectate.
Axa Y reprezintă procentul cererilor de la client care deja are o înregistrare cache, dar perioada de valabilitate a acesteia a expirat și face o nouă cerere.
Ponderea cererilor "în plus" scade de la 47% la 36% doar prin setarea unui TTL minim de 5 minute. Când se setează un TTL minim de 15 minute, numărul acestor cereri scade la 29%. Un TTL minim de 1 oră reduce acest număr la 17%. O diferență semnificativă!
Ce spui de a nu schimba nimic pe server, ci în schimb să stabilești TTL-uri minime în cache-urile DNS ale clienților (routere, rezolutori local)?
Numărul de cereri necesare scade de la 47% la 34% prin setarea unui TTL minim de 5 minute, la 25% cu un minim de 15 minute și la 13% cu un minim de 1 oră. Este posibil ca valoarea optimă să fie de 40 de minute.
Impactul acestei modificări minime este uriaș.
Care sunt consecințele?
Desigur, serviciul poate fi mutat la un nou furnizor de cloud, pe un nou server, pe o nouă rețea, cerând clienților să utilizeze ultimele înregistrări DNS. Și un TTL suficient de mic ajută la realizarea acestei tranziții într-un mod lin și subtil. Dar cu trecerea la o nouă infrastructură, nimeni nu se așteaptă ca clienții să treacă la noile înregistrări DNS în decurs de 1 minut, 5 minute sau 15 minute. Stabilirea unei durate minime de viață de 40 de minute în loc de 5 nu va împiedica utilizatorii să acceseze serviciul.
Cu toate acestea, acest lucru va permite să se reducă semnificativ întârzierile și să se crească confidențialitatea și fiabilitatea, evitând cererile inutile.
Desigur, RFC-uri spun că trebuie să respectăm strict TTL. Dar realitatea este că sistemul DNS a devenit mult prea ineficient.
Dacă lucrezi cu servere DNS autoritative, te rugăm să verifici TTL-urile tale. Ai nevoie cu adevărat de valori atât de ridicul de mici?
Desigur, există motive întemeiate pentru a stabili TTL-uri mici pentru înregistrările DNS. Dar nu pentru 75% din traficul DNS care practic nu se schimbă.
Și dacă din anumite motive trebuie să folosești TTL-uri mici pentru DNS, asigură-te că pe site-ul tău nu este activată caching-ul. Din aceleași motive.
Dacă ai un cache DNS local în funcțiune, cum ar fi , care permite setarea unui TTL minim, folosiți această funcție. Este în regulă. Nu va fi nimic rău. Setați un TTL minim de aproximativ între 40 de minute (2400 de secunde) și 1 oră. O gamă destul de rezonabilă.
Sursa: habr.com
