Kaip veikia DNS vardų sprendimas?

Question

IT Interview Practice · Accepted Answer

**DNS** (Domain Name System) yra interneto telefonų knyga: jis verčia žmogui suprantamą vardą kaip `example.com` į IP adresą kaip `93.184.216.34`. Sprendimas yra hierarchinė paieška, paprastai atliekama už jus **recursive resolver'io** (jūsų ISP arba viešo kaip 8.8.8.8), kuris už jus apeina **authoritative** vardų serverių medį:

```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'is klausia **root** serverių (kurie žino TLD serverius), tada **TLD** serverių dėl `.com` (kurie žino, kas yra authoritative dėl `example.com`), tada **authoritative** serverio (kuris laiko tikrąjį įrašą). Kad to nekartotų kaskart, rezultatai **cache'uojami** kiekviename lygyje — naršyklės, OS ir resolver'io — kiekvienas gerbdamas įrašo **TTL** (time-to-live). Šiltas cache išsprendžia per mikrosekundes; šalta paieška gali kainuoti kelis round trip'us.

Dažni **įrašų tipai**: `A` (name → IPv4), `AAAA` (name → IPv6), `CNAME` (aliasas į kitą vardą), `MX` (pašto serveriai), `TXT` (savavališkas tekstas, naudojamas SPF/patvirtinimui) ir `NS` (deleguoja zoną). Sprendimą galite apžiūrėti tiesiogiai:

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

## Kodėl tai svarbu

DNS yra ant kritinio kelio *kiekvienos* užklausos, prasidedančios nuo vardo, tad lėtas ar blogai sukonfigūruotas resolver'is prideda delsą viskam. Apklausėjai mėgsta šį klausimą, nes jis atskleidžia, ar suprantate **hierarchiją ir caching** — dvi idėjas, leidžiančias globaliai, paskirstytai sistemai greitai atsakyti į milijardus užklausų. Tai taip pat dažnas realių production incidentų šaltinis („visada tai DNS"): pasibaigę įrašai, blogi TTL ar sklaidos vėlavimai po pakeitimo, tad žinoti, kaip veikia caching ir TTL, yra tiesiogiai praktiška.

Kodėl tai svarbu

Susiję klausimai