Cum funcționează rezolvarea DNS?

Question

IT Interview Practice · Accepted Answer

**DNS** (Domain Name System) este cartea de telefon a internetului: traduce un nume lizibil de om precum `example.com` într-o adresă IP precum `93.184.216.34`. Rezolvarea este o căutare ierarhică, făcută de obicei în locul tău de un **recursive resolver** (al ISP-ului tău sau unul public precum 8.8.8.8) care parcurge arborele de servere de nume **authoritative** în numele tău:

```text
Browser ──▶ Recursive Resolver ──▶ Root (.)          "ask .com's servers"
                     │        ◀──
                     ├────────▶ TLD (.com)            "ask example.com's servers"
                     │        ◀──
                     └────────▶ Authoritative         "example.com = 93.184.216.34"
                                (example.com)   ◀──
Browser  ◀── 93.184.216.34
```

Resolverul întreabă serverele **root** (care cunosc serverele TLD), apoi serverele **TLD** pentru `.com` (care știu cine este authoritative pentru `example.com`), apoi serverul **authoritative** (care deține recordul propriu-zis). Pentru a nu repeta asta de fiecare dată, rezultatele sunt **cache-uite** la fiecare nivel — browser, OS și resolver — fiecare respectând **TTL-ul** (time-to-live) al recordului. Un cache cald rezolvă în microsecunde; o căutare rece poate costa câteva round trips.

**Tipuri de record** comune: `A` (name → IPv4), `AAAA` (name → IPv6), `CNAME` (alias către alt nume), `MX` (servere de mail), `TXT` (text arbitrar, folosit pentru SPF/verificare) și `NS` (deleagă o zonă). Poți inspecta rezolvarea direct:

```bash
dig example.com A       # arată recordul A și care server a răspuns
```

## De ce contează

DNS stă pe calea critică a *fiecărei* cereri care pornește de la un nume, deci un resolver lent sau prost configurat adaugă latență la tot. Intervievatorilor le place această întrebare pentru că dezvăluie dacă înțelegi **ierarhia și caching-ul** — cele două idei care permit unui sistem global, distribuit să răspundă la miliarde de interogări rapid. Este și o sursă frecventă de incidente reale de producție („mereu e DNS-ul”): recorduri expirate, TTL-uri greșite sau întârzieri de propagare după o modificare, deci a ști cum funcționează caching-ul și TTL-ul este direct practic.

De ce contează

Întrebări conexe