Компьютерные сети
Как работает DNS-резолвинг
Каждый заход на сайт - это цепочка запросов через континенты: root-сервер в Швеции → TLD в Вирджинии → authoritative в Сингапуре - и всё за 50 миллисекунд. Понимание этого процесса - ключ к диагностике проблем и оптимизации.
- **Деплой:** понимание TTL спасает от часов даунтайма при миграции
- **Диагностика:** dig +trace показывает, где именно проблема
- **Производительность:** кеширование критично для скорости сайтов
Предварительные знания
Рекурсивный запрос
**Рекурсивный запрос** - клиент просит резолвер найти ответ полностью. Резолвер обходит иерархию DNS и возвращает финальный результат. Клиент получает готовый IP-адрес.
Резолверы ISP и публичные (8.8.8.8, 1.1.1.1) принимают рекурсивные запросы. Authoritative серверы (ns1.google.com) - нет, они отвечают только за свою зону.
**Почему рекурсия отключена на authoritative?** 1) Безопасность - открытый рекурсивный сервер можно использовать для DDoS-амплификации. 2) Нагрузка - authoritative должен быстро отвечать за свои записи, не тратить ресурсы на чужие.
Что означает флаг RD=1 в DNS-запросе?
Итеративный запрос
**Итеративный запрос** - сервер отвечает только тем, что знает. Если не знает ответ - возвращает ссылку на другой сервер. Резолвер сам обходит серверы. Так работает взаимодействие резолвера с иерархией DNS.
**Referral:** Ответ «не знаю, но спроси у X» называется referral. Содержит NS-записи для следующего уровня. Резолвер кеширует не только ответы, но и referrals - это ускоряет последующие запросы к тому же TLD.
Что возвращает root-сервер при запросе www.example.com?
Кеширование DNS
**Кеширование** - ключ к скорости DNS. Каждый уровень (браузер, ОС, резолвер) хранит ответы. Повторный запрос к google.com не идёт к root-серверам - ответ уже в кеше.
**Negative caching:** Кешируется и «домен не существует» (NXDOMAIN). Это защищает от повторных бесполезных запросов. TTL для negative cache обычно меньше (5-60 минут).
Где проверяется кеш DNS в первую очередь?
TTL - время жизни записи
**TTL** (Time To Live) - сколько секунд запись можно хранить в кеше. Задаётся владельцем домена. Низкий TTL = быстрое обновление, но больше запросов. Высокий TTL = меньше нагрузки, но изменения распространяются медленно.
**TTL и деплой:** Перед большими изменениями (смена хостинга, миграция) TTL уменьшается заранее! Если TTL = 1 день, а IP уже сменён - часть пользователей увидит изменение через сутки.
Зачем уменьшать TTL перед миграцией?
Root-серверы - фундамент DNS
**Root-серверы** - 13 логических серверов (a-m.root-servers.net), которые знают адреса всех TLD-серверов. Физически - сотни серверов по всему миру через anycast. Без них DNS не работает.
**Почему 13?** Историческое ограничение: ответ должен умещаться в UDP-пакет 512 байт. 13 NS-записей с A-записями = ~500 байт. Сейчас есть EDNS, но число 13 осталось. Anycast позволяет иметь сотни физических серверов.
Если root-серверы упадут, интернет перестанет работать
Благодаря кешированию интернет будет работать часы или даже дни без root-серверов
Резолверы кешируют ответы, включая referrals к TLD. Пока TTL не истёк, запросы не дойдут до root. Плюс anycast делает полный отказ почти невозможным - нужно отключить сотни серверов на всех континентах.
Сколько физических root-серверов существует?
Ключевые идеи
- **Рекурсивный запрос:** резолвер находит ответ полностью за клиента
- **Итеративный запрос:** сервер отвечает ссылкой на следующий уровень
- **Кеширование:** браузер → ОС → резолвер, каждый уровень кеширует
- **TTL:** время жизни записи; уменьшайте перед миграцией!
Связанные темы
Резолвинг - сердце DNS:
- DNSSEC — Криптографическая верификация ответов
- DoH / DoT — Шифрование DNS-запросов
- GeoDNS — Разные ответы для разных регионов
Вопросы для размышления
- Почему резолвер от ISP обычно быстрее, чем 8.8.8.8?
- Что произойдёт, если TTL = 0? (это запрещено, но теоретически?)
- Как anycast обеспечивает отказоустойчивость root-серверов?