Как работает DNS: полный путь запроса от браузера до authoritative-сервера

Любая веб-страница начинается не с HTML. Сначала браузер должен узнать IP-адрес домена — без него TCP-handshake или QUIC-пакет просто некуда отправить. Эту задачу выполняет DNS, и большинство пользователей думают о нём как о «волшебном чёрном ящике, который преобразует имена в адреса». На самом деле это распределённая база данных с пятью уровнями кэша, строгой иерархией зон и десятками типов записей.

Хорошая новость: DNS обычно «мгновенный». Плохая новость: когда он ломается, диагностика бывает мучительной — потому что ошибка может произойти на любом из пяти уровней. Разберёмся в каждом, чтобы понимать, где именно искать причину.

Запрос google.com

Уровень 0: in-process cache    ─►  hit ~80% запросов, 0 ms
    │ miss
Уровень 1: stub resolver ОС    ─►  hit ~10%, 1-3 ms
    │ miss
Уровень 2: домашний роутер     ─►  иногда DNS, иногда DHCP-relay
    │ miss
Уровень 3: recursive resolver  ─►  1.1.1.1 / 8.8.8.8 / провайдер
    │ miss
    └─► root (.)              ─►  список NS для .com
         └─► TLD (.com)       ─►  NS для google.com
              └─► authoritative ─► A/AAAA/HTTPS-records

Финал: IP-адрес + TTL  ←  кэшируется на всех уровнях вверх

Башня кэшей: почему DNS «мгновенный»

Уровней кэша существенно больше, чем кажется на первый взгляд. По нарастающей:

1. Кэш браузера. Chrome держит 1000 последних имён, типичный TTL 30–300 секунд. Можно посмотреть на chrome://net-internals/#dns.
2. Stub resolver ОС. На Linux это обычно systemd-resolved или nscd, на macOS — mDNSResponder, на Windows — DNS Client. Кэш в памяти, обновляется по TTL.
3. Домашний роутер. Часто работает как DNS-forwarder — кэширует ответы для всей квартиры.
4. Recursive resolver. Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9, или DNS вашего провайдера. Огромный распределённый кэш на anycast-адресах.
5. Authoritative DNS. Сервер, ответственный за зону. До него запрос доходит только после промахов на всех вышестоящих уровнях.

В обычной интернет-сессии до уровня 4 (recursive resolver) доходит около 5–15% запросов, а до authoritative — десятые доли процента. Кэширование — главная причина, по которой DNS обычно занимает миллисекунды.

Что делает recursive resolver на полном промахе

Допустим, ваш браузер впервые в жизни запрашивает analytics.example. Stub-резолвер промахнулся, идёт к recursive (например, 1.1.1.1). У 1.1.1.1 кэша тоже нет. Дальше начинается классическая рекурсия:

1. Резолвер идёт в один из 13 root-серверов (a.root-servers.net … m.root-servers.net) и спрашивает: «кто отвечает за зону .example?». Получает список NS-записей для TLD.
2. Идёт в TLD-сервер (например, a.gtld-servers.net для .com) и спрашивает: «кто отвечает за example.com?». Получает authoritative NS.
3. Идёт в authoritative для example.com и спрашивает: «какой A-record у analytics.example.com?». Получает финальный IP.
4. Возвращает ответ клиенту и кэширует на TTL.

На практике каждый шаг — это UDP-пакет на 53-й порт и ответ обратно. На быстром anycast-резолвере полная рекурсия занимает 50–150 мс. Дальше всё кэшируется и следующие миллионы запросов отвечают мгновенно.

Типы записей и зачем они нужны

Самый интересный новичок последних лет — HTTPS-запись. Она объединяет A/AAAA, ALPN-список и ECH-ключ в одну запись. Для современного браузера это означает один DNS-запрос вместо трёх и поддержку ECH «из коробки».

TTL и его экономика

Каждая запись приходит с TTL — числом секунд, которое разрешено держать ответ в кэше. Это компромисс между скоростью миграций и нагрузкой на authoritative:

• TTL 300 (5 минут). Гибкость для миграций и failover, но 12 запросов в час с каждого резолвера.
• TTL 3600 (час). Хороший компромисс для большинства веб-сайтов.
• TTL 86400 (сутки). Минимальная нагрузка, но миграция в новый IP займёт ровно сутки в худшем случае.
• Negative caching. Отрицательные ответы (NXDOMAIN) тоже кэшируются — TTL берётся из SOA-записи зоны.

На практике крупные сервисы вроде Google и Cloudflare держат TTL 60–300 секунд для гибкости, а небольшие сайты — час и больше.

Инструменты диагностики

Если что-то не работает с DNS, четыре команды покрывают 95% случаев:

• dig +trace example.com — следит за всей иерархией от root до authoritative и показывает каждый шаг рекурсии.
• dig @1.1.1.1 example.com — спрашивает конкретный резолвер. Полезно сравнить ответ Cloudflare и провайдера.
• dig example.com HTTPS — показывает современную HTTPS-запись с ALPN и ECH.
• dig +short example.com TXT — быстрый просмотр SPF/DKIM/DMARC.
• nslookup example.com 8.8.8.8 — кросс-платформенный аналог.
• На Windows: Resolve-DnsName example.com -Server 1.1.1.1.

Для отладки кэшей: chrome://net-internals/#dns в Chrome, resolvectl flush-caches в systemd-resolved, ipconfig /flushdns на Windows.

Почему DNS иногда ломается

Типичные причины, по убыванию частоты:

• Зависший stub-резолвер. systemd-resolved иногда теряет соединение с upstream — лечится systemctl restart systemd-resolved.
• Кэш с устаревшим IP. Сайт мигрировал, но ваш TTL ещё не истёк. Решение — flush DNS.
• Недоступный authoritative. Зона работает, но один из NS лежит. На уровне рекурсивного резолвера это видно как партиционные ответы.
• DNSSEC validation fail. Зона подписана, но подписи протухли или не сходятся. Резолвер с включённой валидацией откажется отдавать ответ.
• CNAME loop. A → CNAME → CNAME → A — и где-то ссылка кольцом. Резолвер бросает SERVFAIL.

Полезный приём: при подозрении на DNS-проблему всегда сравнивайте ответы с трёх резолверов — собственного провайдера, 1.1.1.1 и 8.8.8.8. Если все трое отвечают одинаково, проблема в зоне; если расхождение — где-то по дороге.

Почему DNS — это вопрос приватности

Классический DNS работает по UDP/53 открытым текстом. Любой посредник между вами и резолвером видит, какие домены вы открываете — даже до TLS. Это та же утечка имени, что и SNI, только происходит ещё раньше. Поэтому защищённый DNS (DoH, DoT, DoQ) — это не паранойя, а гигиена. Сравнение подходов разобрано в статье про DoH и DoT.

Итого

DNS — это первый шаг почти любого сетевого действия и одновременно одна из самых сложных распределённых систем веба. Понимая башню кэшей, иерархию резолюции, типы записей и роль TTL, вы сможете отделить «у меня кривой DNS» от «сайт лёг» за минуту, а не за полчаса. И это умение пригождается чаще, чем кажется.