Rezoluția DNS, De la Început până la Sfârşit

De fiecare dată când tastezi un domeniu într-un browser, o serie de căutări se lansează înainte ca măcar un pachet să ajungă la site-ul pe care-l vrei. Cea mai mare parte din acea serie este invizibilă, și cele mai multe explicații despre ea se opresc la "e ca un cartea de telefon." Iată ce se întâmplă de fapt, pas cu pas, inclusiv părţile pe care oamenii le omit de obicei.

Stub resolver-ul nu este inteligent

Sistemul tău de operare nu face rezoluţie reală DNS pe cont propriu. Rulează un stub resolver, o bucată subţire de cod care doar transmite interogarea ta oricărui server DNS este configurat în /etc/resolv.conf pe Linux sau în setările adaptorului de rețea pe Windows. Verifică-ți cu:

cat /etc/resolv.conf

Acel fişier de obicei indică routerul tău (cum ar fi 192.168.1.1), resolverul ISP-ului tău, sau unul public cum ar fi 1.1.1.1 sau 8.8.8.8. Stub resolver-ul nu are logică de cache proprie dincolo de ceea ce oferă OS-ul sau un daemon local cum ar fi systemd-resolved.

Recursive resolver-ul face munca reală

Odată ce interogarea ta ajunge la un recursive resolver, acel server preia sarcina de a găsi răspunsul, chiar dacă trebuie să ceară mai multor alte servere pentru a ajunge acolo. Dacă răspunsul este deja în cache dintr-o căutare anterioară, îl primești înapoi imediat. Verifică TTL-ul cu:

dig example.com

Priveşte ANSWER SECTION — numărul dinaintea tipului de înregistrare (cum ar fi 300 înaintea A) este TTL-ul în secunde. Acela e cât timp resolverele sunt permise să cache înregistrarea înainte de a cere din nou.

Dacă nimic nu este în cache, recursive resolver-ul începe o parcurgere în jos a ierarhiei DNS de la rădăcină.

Servere rădăcină, TLD și autoritare

Sunt 13 adrese de server rădăcină (a.root-servers.net prin m.root-servers.net), fiecare susţinut de multe mașini fizice prin rutare anycast. Serverul rădăcină nu ştie unde trăieşte example.com, dar ştie care servere gestionează .com, deci returnează o referire.

Resolver-ul apoi întreabă un server .com TLD, care din nou nu ştie răspunsul final dar ştie care nameserveri sunt autoritari pentru example.com în mod specific. Poţi vedea această delegare tu însuţi:

dig +trace example.com

Acea comandă arată fiecare hop: rădăcină, apoi TLD, apoi nameserverii autoritari pentru domeniu, terminând cu înregistrarea reală A sau AAAA. E singura cea mai bună comandă pentru a înţelege DNS vizual în loc de teoretic.

Nameserverul autorizat este ultima oprire. E serverul pe care proprietarul domeniului de fapt l-a configurat, adesea prin panoul DNS al unui registrator sau un serviciu cum ar fi Route 53 sau Cloudflare DNS. Acesta e singurul server din toată lanţul care are răspunsul real, canonic în loc de o copie în cache sau o referire.

Tipuri de înregistrări pe care de fapt le întâlnești

O înregistrare A mapează un nume la o adresă IPv4, AAAA face acelaşi lucru pentru IPv6. CNAME indică un nume la alt nume mai degrabă decât o IP, care e cum CDN-urile cum ar fi Cloudflare sau Fastly direcţionează traficul fără a expune IP-uri brute. Înregistrările MX gestionează rutarea poştei, iar înregistrările TXT transportă text arbitrar, folosit cel mai frecvent acum pentru SPF, DKIM și șiruri de verificare de domeniu. Înregistrările NS spun lumii care servere sunt autoritare pentru o zonă, și acel tip de înregistrare e cel care face delegarea posibilă în primul rând.

Unde cache-ul de fapt trăieşte

Cache-ul se întâmplă la mai multe straturi simultan: browserul însuşi (Chrome are propriul cache DNS vizibil la chrome://net-internals/#dns), cache-ul resolver-ului OS, routerul local, și recursive resolver-ul upstream. Asta e de ce o schimbare DNS poate să pară că funcţionează instant pe un dispozitiv și să dureze ore să apară pe altul — nu accesezi acelaşi cache.

Când cobori TTL-ul unei înregistrări înainte de o migrare planificată, nu accelerezi nimic imediat. Doar micșorezi fereastra în care date vechi pot persista odată ce schimbarea se întâmplă de fapt. Fă asta cel puţin un ciclu TTL în avans, nu cinci minute înainte de schimbare.

De ce asta contează pentru depanare

Când un site este inaccesibil, dig +trace îţi spune exact care strat e stricat: o problemă rădăcină/TLD arată complet diferit de un server autorizat configurat greşit sau un cache vechi pe propria ta mașină. Compararea dig example.com împotriva unui resolver cu comportament cunoscut, cum ar fi dig example.com @1.1.1.1, izolează dacă problema e resolverul tău local sau DNS-ul real al domeniului.

DNS arată simplu de afară pentru că de obicei se rezolvă în sub 100ms și nimeni nu se gândeşte la asta. Dedesubt, e un sistem de interogare distribuit, în cache, ierarhic care a rulat în mare măsură neschimbat în structură din anii 1980, ceea ce e un argument destul de bun pentru cât de bine designul original s-a menţinut.

Dacă vrei să mergi mai departe cu asta, Korra Studio are segmente înrudite pe DEFENSE_GRID care acoperă extensii de securitate DNS, tunelarea DNS ca tehnică de exfiltrare și construirea propriului resolver de la zero în Python.