Hur fungerar DNS-uppslagning?

Question

IT Interview Practice · Accepted Answer

**DNS** (Domain Name System) är internets telefonkatalog: det översätter ett läsbart namn som `example.com` till en IP-adress som `93.184.216.34`. Uppslagningen är en hierarkisk sökning, vanligtvis utförd åt dig av en **recursive resolver** (din ISP:s eller en publik som 8.8.8.8) som går igenom trädet av **authoritative** namnservrar å dina vägnar:

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

Resolvern frågar **root**-servrarna (som känner till TLD-servrarna), sedan **TLD**-servrarna för `.com` (som vet vem som är authoritative för `example.com`), sedan den **authoritative** servern (som håller den faktiska posten). För att slippa upprepa detta varje gång **cachas** resultaten på varje nivå — webbläsare, OS och resolver — där var och en respekterar postens **TTL** (time-to-live). En varm cache slår upp på mikrosekunder; en kall uppslagning kan kosta flera round trips.

Vanliga **posttyper**: `A` (namn → IPv4), `AAAA` (namn → IPv6), `CNAME` (alias till ett annat namn), `MX` (mailservrar), `TXT` (godtycklig text, används för SPF/verifiering) och `NS` (delegerar en zon). Du kan inspektera uppslagningen direkt:

```bash
dig example.com A       # visar A-posten och vilken server som svarade
```

## Varför det är viktigt

DNS ligger på den kritiska vägen för *varje* request som utgår från ett namn, så en långsam eller felkonfigurerad resolver lägger till latens på allt. Intervjuare gillar denna fråga eftersom den avslöjar om du förstår **hierarki och caching** — de två idéer som låter ett globalt, distribuerat system besvara miljarder frågor snabbt. Det är också en frekvent källa till verkliga produktionsincidenter ("det är alltid DNS"): utgångna poster, fel TTL:er eller propageringsfördröjningar efter en ändring, så att veta hur caching och TTL fungerar är direkt praktiskt.

Varför det är viktigt

Relaterade frågor