latența sistemului de nume de domeniu (DNS) este o componentă cheie pentru a avea o experiență online bună. Și pentru a minimiza latența DNS, alegerea cu atenție a serverelor DNS și a releelor de anonimizare joacă un rol important. dar cel mai bun mod de a minimiza latenta este de a evita trimiterea de interogări inutile pentru a începe cu. Acesta este motivul pentru care DNS-ul a fost proiectat, încă din prima zi, pentru a fi un protocol puternic cacheable. Înregistrările individuale au un time-to-live (TTL), stabilit inițial de administratorii de zonă, iar rezolvatorii folosesc aceste informații pentru a păstra aceste înregistrări în memorie pentru a evita traficul inutil.
cache-ul este eficient? Un studiu rapid pe care l-am făcut acum câțiva ani a arătat că există loc pentru îmbunătățiri. Astăzi, vreau să arunc o privire nouă asupra situației actuale.pentru a face acest lucru, am patch-uri un server DNS criptat pentru a stoca TTL original al unui răspuns, definit ca TTL minim al înregistrărilor sale, pentru fiecare interogare de intrare. Acest lucru ne oferă o imagine de ansamblu bună a distribuției TTL a traficului din lumea reală, dar explică și popularitatea interogărilor individuale.
această versiune patch-uri a fost lăsat să ruleze pentru câteva ore. Setul de date rezultat este compus din 1.583.579 tupluri (nume, qtype, TTL, timestamp). Aici este distribuția generală TTL (axa X este TTL în secunde):
pe lângă o ciocnire neglijabilă la 86.400 (în principal pentru înregistrările SOA), este destul de evident că TTL-urile sunt în intervalul scăzut. Să mărim:
bine, TTL-urile de peste 1 oră sunt nesemnificative statistic. Să ne concentrăm pe intervalul 0-3, 600:
și unde majoritatea TTL – urilor stau între 0 și 15 minute:
marea majoritate este între 0 și 5 minute:
Acest lucru nu este mare. Distribuția cumulativă poate face problema și mai evidentă:
jumătate din Internet are un TTL de 1 minut sau mai puțin, iar trei sferturi au un TTL de 5 minute sau mai puțin.
dar stai, acest lucru este de fapt mai rău. Acestea sunt TTL-uri așa cum sunt definite de serverele autoritare. Cu toate acestea, TTL-urile preluate de la rezolvatorii de clienți (de exemplu, routere, cache-uri locale) obțin un TTL care rezoluțiile din amonte scad în fiecare secundă. Deci, în medie, durata reală pe care un client o poate utiliza o intrare în cache înainte de a solicita o nouă interogare este jumătate din TTL-ul original.
poate că aceste TTL-uri foarte scăzute afectează doar interogările neobișnuite și nu Site-urile web și API-urile populare. Să aruncăm o privire:
Din păcate, cele mai populare interogări sunt, de asemenea, cele mai inutile pentru cache. Să mărim:
Verdict: este foarte rău, sau mai degrabă a fost deja rău și sa înrăutățit. Cache-ul DNS a devenit aproape inutil. Cu mai puține persoane care utilizează rezolvatorul DNS al ISP-ului lor (din motive întemeiate), latența crescută devine mai vizibilă. Cache-ul DNS a devenit util doar pentru conținutul pe care nimeni nu îl vizitează. De asemenea, rețineți că software-ul poate interpreta diferit TTL-urile scăzute.
De ce?
de ce sunt stabilite înregistrări DNS cu TTL-uri atât de scăzute?
- Legacy load balancers sunt lăsate cu setările implicite.
- legenda urbană conform căreia echilibrarea încărcării bazată pe DNS depinde de TTLs (nu).
- administratorii care doresc ca modificările lor să fie aplicate imediat, deoarece pot necesita mai puține lucrări de planificare.
- ca administrator DNS sau load-balancer, datoria dvs. este să implementați eficient configurația pe care o cer oamenii, nu să faceți site-uri și servicii rapide.
- TTLS scăzut da pace a mintii.
nu includ ‘pentru failover’ în acea listă, deoarece acest lucru a devenit din ce în ce mai puțin relevant. Dacă intenția este de a redirecționa utilizatorii către o altă rețea doar pentru a afișa o pagină de balenă eșuată atunci când absolut orice altceva este pe foc, este probabil acceptabil să aveți o întârziere de peste un minut.
CDN-urile și echilibratoarele de sarcină sunt în mare parte de vină, mai ales atunci când combină înregistrările CNAME cu TTL-uri scurte, cu înregistrări care au și TTL-uri scurte (dar independente):
$ drill raw.githubusercontent.comraw.githubusercontent.com. 9 IN CNAME github.map.fastly.net.github.map.fastly.net. 20 IN A 151.101.128.133github.map.fastly.net. 20 IN A 151.101.192.133github.map.fastly.net. 20 IN A 151.101.0.133github.map.fastly.net. 20 IN A 151.101.64.133
o nouă interogare trebuie trimisă ori de câte ori CNAME sau oricare dintre înregistrările A expiră. Ambele au un TTL de 30 de secunde, dar nu sunt în fază. TTL-ul mediu real va fi de 15 secunde.
dar stai! Acest lucru este mai rău. Unii rezolvatori se comportă destul de prost într-o astfel de situație low-TTL-CNAME+low-TTL-records:
$ drill raw.githubusercontent.com @4.2.2.2raw.githubusercontent.com. 1 IN CNAME github.map.fastly.net.github.map.fastly.net. 1 IN A 151.101.16.133
acesta este rezolvatorul Level3, care, cred, rulează BIND. Dacă continuați să trimiteți acea interogare, TTL returnat va fi întotdeauna 1. În esență, raw.githubusercontent.com nu va fi niciodată în cache.
Iată un alt exemplu de situație low-TTL-CNAME+low-TTL-records, cu un nume foarte popular:
$ drill detectportal.firefox.com @1.1.1.1detectportal.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.106a1089.dscd.akamai.net. 10 IN A 104.123.50.88
Nu Mai puțin de trei înregistrări CNAME. Au. Unul dintre ei are un TTL decent, dar este total inutil. Alte CNAMEs au un TTL original de 60 de secunde; akamai.net numele au un TTL maxim de 20 de secunde și niciunul dintre acestea nu este în fază.
Ce zici de unul pe care dispozitivele Apple îl sondează constant?
$ drill 1-courier.push.apple.com @4.2.2.21-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.84gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.85
aceeași configurație ca Firefox și TTL este blocat la 1 cele mai multe ori atunci când se utilizează resolver Level3 lui.
Ce zici de Dropbox?
$ drill client.dropbox.com @8.8.8.8client.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.2client.dropbox.com. 1 IN CNAME client.dropbox-dns.com.client.dropbox-dns.com. 1 IN A 162.125.64.3
safebrowsing.googleapis.com are un TTL de 60 de secunde. Numele Facebook au un TTL de 60 de secunde. Și, încă o dată, din perspectiva clientului, aceste valori ar trebui reduse la jumătate.
ce zici de setarea unui TTL minim?
folosind numele, tipul de interogare, TTL și timestamp stocate inițial, am scris un script care simulează peste 1,5 milioane de interogări care trec printr-un rezolvator de cache pentru a estima câte interogări au fost trimise din cauza unei intrări cache expirate. 47,4% din interogări au fost făcute după ce o intrare existentă în cache a expirat. Acest lucru este nerezonabil de mare.
care ar fi impactul asupra cache-ului dacă s-ar stabili un TTL minim?
axa X este TTL minim care a fost setat. Înregistrările al căror TTL inițial a fost mai mare decât această valoare nu au fost afectate. Axa Y este procentul de interogări efectuate de un client care a avut deja o intrare în cache, dar a fost făcută o nouă interogare și intrarea în cache a expirat.
Numărul de interogări scade de la 47% la 36% doar prin setarea unui TTL minim de 5 minute. Setarea unui TTL minim de 15 minute face ca numărul de interogări necesare să scadă la 29%. Un TTL minim de 1 oră îl face să scadă la 17%. Aceasta este o diferență semnificativă!
Ce zici de a nu schimba nimic din partea serverului, ci de a avea cache-uri DNS client (routere, rezolvatoare locale și cache-uri…) setați un TTL minim?
numărul de interogări 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ă. 40 de minute poate un loc dulce. Impactul acestei schimbări minime este imens.
care sunt implicațiile?
desigur, un serviciu poate trece la un nou furnizor de cloud, un nou server, o nouă rețea, necesitând clienților să utilizeze înregistrări DNS actualizate. Și având în mod rezonabil TTLS scăzut ajută la trecerea fără frecare. Cu toate acestea, nimeni care trece la o nouă infrastructură nu se va aștepta ca clienții să utilizeze noile înregistrări DNS în decurs de 1 minut, 5 minute sau 15 minute.
setarea unui TTL minim de 40 de minute în loc de 5 minute nu va împiedica utilizatorii să acceseze serviciul. Cu toate acestea, va reduce drastic latența și va îmbunătăți confidențialitatea (mai multe interogări = mai multe oportunități de urmărire) și fiabilitatea, evitând interogările care nu sunt necesare.
desigur, RFC-urile spun că TTL-urile ar trebui respectate cu strictețe. Dar realitatea este că DNS a devenit ineficient.
dacă operați servere DNS autoritare, vă rugăm să revedeți TTLs-ul. Chiar ai nevoie ca acestea să fie ridicol de mici?
Read: cum să alegeți valorile DNS TTL
sigur, există motive valide pentru a utiliza TTLS DNS scăzut. Dar nu pentru 75% din Internet pentru a servi conținut care este în mare parte imuabil, dar inutil să cache. Și dacă, din orice motive, trebuie să utilizați TTLS DNS scăzut, asigurați-vă, de asemenea, că memoria cache nu funcționează nici pe site-ul dvs. web. Din aceleași motive.
dacă utilizați un cache DNS local, cum ar fi dnscrypt-proxy care permite setarea TTL-urilor minime, utilizați această caracteristică. Acest lucru este în regulă. Nu se va întâmpla nimic rău. Setați acel TTL minim la ceva între 40 de minute (2400 de secunde) și 1 oră; acesta este un interval perfect rezonabil.
adaptat după postarea originală care a apărut pe 00f.net