Hvordan fungerer DNS-resolution?

Question

IT Interview Practice · Accepted Answer

**DNS** (Domain Name System) er internettets telefonbog: den oversætter et menneskelæseligt navn som `example.com` til en IP-adresse som `93.184.216.34`. Resolution er et hierarkisk opslag, som regel udført for dig af en **recursive resolver** (din ISP's eller en offentlig som 8.8.8.8), der går træet af **authoritative** name servers igennem på dine vegne:

```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
```

Resolveren spørger **root**-serverne (som kender TLD-serverne), derefter **TLD**-serverne for `.com` (som ved, hvem der er authoritative for `example.com`), derefter den **authoritative** server (som holder den faktiske record). For at undgå at gentage dette hver gang **caches** resultater på hvert niveau — browser, OS og resolver — hvor hvert respekterer record'ens **TTL** (time-to-live). En varm cache resolver på mikrosekunder; et koldt opslag kan koste flere round trips.

Almindelige **record-typer**: `A` (navn → IPv4), `AAAA` (navn → IPv6), `CNAME` (alias til et andet navn), `MX` (mail servers), `TXT` (vilkårlig tekst, brugt til SPF/verifikation) og `NS` (delegerer en zone). Du kan inspicere resolution direkte:

```bash
dig example.com A       # shows the A record and which server answered
```

## Hvorfor det betyder noget

DNS ligger på den kritiske sti for *hver* request, der starter fra et navn, så en langsom eller fejlkonfigureret resolver tilføjer latency til alt. Interviewere kan lide dette spørgsmål, fordi det afslører, om du forstår **hierarki og caching** — de to idéer, der lader et globalt, distribueret system besvare milliarder af forespørgsler hurtigt. Det er også en hyppig kilde til reelle production-incidents ("det er altid DNS"): udløbne records, forkerte TTL'er eller propagerings-forsinkelser efter en ændring, så det at vide, hvordan caching og TTL fungerer, er direkte praktisk.

Hvorfor det betyder noget

Relaterede spørgsmål