Jak działa rozwiązywanie DNS?

Question

IT Interview Practice · Accepted Answer

**DNS** (Domain Name System) to książka telefoniczna internetu: tłumaczy czytelną dla człowieka nazwę jak `example.com` na adres IP jak `93.184.216.34`. Rozwiązywanie to hierarchiczne wyszukiwanie, zwykle wykonywane za ciebie przez **recursive resolver** (twojego ISP lub publiczny, jak 8.8.8.8), który przechodzi drzewo serwerów nazw **authoritative** w twoim imieniu:

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

Resolver pyta serwery **root** (które znają serwery TLD), potem serwery **TLD** dla `.com` (które wiedzą, kto jest authoritative dla `example.com`), potem serwer **authoritative** (który trzyma faktyczny rekord). Aby nie powtarzać tego za każdym razem, wyniki są **cache'owane** na każdym poziomie — przeglądarki, OS i resolvera — każdy honorujący **TTL** (time-to-live) rekordu. Ciepły cache rozwiązuje w mikrosekundach; zimne wyszukiwanie może kosztować kilka rund tam i z powrotem.

Częste **typy rekordów**: `A` (nazwa → IPv4), `AAAA` (nazwa → IPv6), `CNAME` (alias do innej nazwy), `MX` (serwery pocztowe), `TXT` (dowolny tekst, używany do SPF/weryfikacji) oraz `NS` (deleguje strefę). Możesz podejrzeć rozwiązywanie wprost:

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

## Dlaczego to ważne

DNS leży na krytycznej ścieżce *każdego* żądania, które zaczyna się od nazwy, więc wolny lub źle skonfigurowany resolver dodaje opóźnienie do wszystkiego. Rekruterzy lubią to pytanie, bo ujawnia, czy rozumiesz **hierarchię i caching** — dwie idee, które pozwalają globalnemu, rozproszonemu systemowi odpowiadać na miliardy zapytań szybko. To także częste źródło realnych incydentów produkcyjnych („to zawsze DNS"): wygasłe rekordy, złe TTL-e lub opóźnienia propagacji po zmianie, więc wiedza o tym, jak działają caching i TTL, jest wprost praktyczna.

Dlaczego to ważne

Powiązane pytania