Hogyan működik a DNS-feloldás?

Question

IT Interview Practice · Accepted Answer

A **DNS** (Domain Name System) az internet telefonkönyve: egy ember által olvasható nevet, mint az `example.com`, IP-címmé fordít, mint a `93.184.216.34`. A feloldás egy hierarchikus lekérdezés, amelyet általában egy **recursive resolver** (az ISP-édé vagy egy publikus, mint a 8.8.8.8) végez helyetted, bejárva az **authoritative** name serverek fáját a nevedben:

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

A resolver megkérdezi a **root** servereket (amelyek ismerik a TLD servereket), majd a `.com` **TLD** servereit (amelyek tudják, ki az authoritative az `example.com` számára), végül az **authoritative** servert (amely a tényleges rekordot tartja). Hogy ezt ne kelljen minden alkalommal megismételni, az eredmények minden szinten **cache**-elődnek — böngésző, OS és resolver —, mindegyik tiszteletben tartva a rekord **TTL**-jét (time-to-live). Egy meleg cache mikroszekundumok alatt old fel; egy hideg lekérdezés több round trip-be kerülhet.

Gyakori **rekordtípusok**: `A` (name → IPv4), `AAAA` (name → IPv6), `CNAME` (alias egy másik névre), `MX` (mail serverek), `TXT` (tetszőleges szöveg, SPF-hez/verifikációhoz használva) és `NS` (egy zóna delegálása). A feloldást közvetlenül is megvizsgálhatod:

```bash
dig example.com A       # megmutatja az A rekordot és hogy melyik szerver válaszolt
```

## Miért fontos

A DNS *minden* olyan kérés kritikus útján ott van, amely egy névből indul, így egy lassú vagy rosszul konfigurált resolver mindenhez latency-t ad. Az interjúztatók azért kedvelik ezt a kérdést, mert felfedi, érted-e a **hierarchiát és a caching-et** — azt a két ötletet, amely lehetővé teszi, hogy egy globális, elosztott rendszer gyorsan válaszoljon milliárdnyi lekérdezésre. Egyben gyakori forrása valódi production incidenseknek ("mindig a DNS"): lejárt rekordok, rossz TTL-ek vagy propagációs késések egy változás után — így annak ismerete, hogyan működik a caching és a TTL, közvetlenül gyakorlati.

Miért fontos

Kapcsolódó kérdések