Как работает разрешение DNS?

Question

IT Interview Practice · Accepted Answer

**DNS** (Domain Name System) — это телефонная книга интернета: он переводит читаемое человеком имя вроде `example.com` в IP-адрес вроде `93.184.216.34`. Разрешение — это иерархический поиск, обычно выполняемый за вас **recursive resolver** (вашего провайдера или публичным, вроде 8.8.8.8), который обходит дерево **авторитетных (authoritative)** name-серверов от вашего имени:

```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 спрашивает **root**-серверы (которые знают TLD-серверы), затем **TLD**-серверы для `.com` (которые знают, кто авторитетен для `example.com`), затем **авторитетный** сервер (который держит саму запись). Чтобы не повторять это каждый раз, результаты **кэшируются** на каждом уровне — браузер, ОС и resolver — каждый уважает **TTL** (time-to-live) записи. Тёплый кэш разрешает за микросекунды; холодный поиск может стоить нескольких round trip.

Распространённые **типы записей**: `A` (name → IPv4), `AAAA` (name → IPv6), `CNAME` (алиас на другое имя), `MX` (почтовые серверы), `TXT` (произвольный текст, используется для SPF/верификации) и `NS` (делегирует зону). Вы можете напрямую посмотреть разрешение:

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

## Почему это важно

DNS находится на критическом пути *каждого* запроса, который начинается с имени, поэтому медленный или неправильно настроенный resolver добавляет задержку ко всему. Интервьюеры любят этот вопрос, потому что он показывает, понимаете ли вы **иерархию и кэширование** — две идеи, которые позволяют глобальной распределённой системе быстро отвечать на миллиарды запросов. Это также частый источник реальных production-инцидентов («это всегда DNS»): просроченные записи, неверные TTL или задержки распространения после изменения — так что знание того, как работают кэширование и TTL, напрямую практично.

Почему это важно

Похожие вопросы