Hvordan fungerer DNS-oppslag?

Question

IT Interview Practice · Accepted Answer

**DNS** (Domain Name System) er internettets telefonkatalog: den oversetter et menneskelesbart navn som `example.com` til en IP-adresse som `93.184.216.34`. Oppslaget er et hierarkisk søk, vanligvis gjort for deg av en **recursive resolver** (din ISP sin eller en offentlig som 8.8.8.8) som går gjennom treet av **authoritative** navneservere 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ør **root**-serverne (som kjenner TLD-serverne), deretter **TLD**-serverne for `.com` (som vet hvem som er authoritative for `example.com`), og til slutt den **authoritative** serveren (som holder selve oppføringen). For å slippe å gjenta dette hver gang blir resultater **cachet** på hvert nivå — nettleser, OS og resolver — der hvert nivå respekterer oppføringens **TTL** (time-to-live). En varm cache slår opp på mikrosekunder; et kaldt oppslag kan koste flere round trips.

Vanlige **oppføringstyper**: `A` (navn → IPv4), `AAAA` (navn → IPv6), `CNAME` (alias til et annet navn), `MX` (mailservere), `TXT` (vilkårlig tekst, brukt til SPF/verifisering) og `NS` (delegerer en sone). Du kan inspisere oppslaget direkte:

```bash
dig example.com A       # viser A-oppføringen og hvilken server som svarte
```

## Hvorfor det er viktig

DNS ligger på den kritiske stien for *hver* forespørsel som starter fra et navn, så en treg eller feilkonfigurert resolver legger latency til alt. Intervjuere liker dette spørsmålet fordi det avslører om du forstår **hierarki og caching** — de to ideene som lar et globalt, distribuert system svare på milliarder av forespørsler raskt. Det er også en hyppig kilde til reelle produksjonshendelser («det er alltid DNS»): utløpte oppføringer, feil TTL-er eller propageringsforsinkelser etter en endring — så å vite hvordan caching og TTL fungerer er direkte praktisk.

Hvorfor det er viktig

Relaterte spørsmål