Рекурсивный DNS-запрос: шаг за шагом
Браузер
нужен example.com
Резолвер
ваш провайдер / 1.1.1.1
Корень + TLD
кто отвечает за .com?
Авторитетный
настоящий ответ
Каждый шаг цепочки — тоже DNS-запрос, и его ответ потом кэшируется
Как работает DNS: от доменного имени к IP-адресу
Введите example.com в браузере — и страница появляется почти мгновенно. Между этими двумя моментами распределённая база данных, охватывающая всю планету, ответила на вопрос: какой IP-адрес принадлежит этому имени? Эта система — DNS, система доменных имён.
Её стоит понимать по-настоящему, потому что почти любая непонятная проблема с сайтом — изменение, которое не вступило в силу, пропадающая почта, сайт, работающий на одном устройстве и не работающий на другом — сводится к тому, как на самом деле ведут себя разрешение и кеширование DNS.
Рекурсивный DNS-запрос: шаг за шагом
Браузер
нужен example.com
Резолвер
ваш провайдер / 1.1.1.1
Корень + TLD
кто отвечает за .com?
Авторитетный
настоящий ответ
Каждый шаг цепочки — тоже DNS-запрос, и его ответ потом кэшируется
Четыре участника
- Stub-резолвер — небольшой DNS-клиент, встроенный в вашу операционную систему. Он почти ничего не знает и сразу всё делегирует.
- Рекурсивный резолвер — обычно его держит ваш провайдер или публичный сервис вроде
1.1.1.1или8.8.8.8. Это рабочая лошадка, которая добывает ответ и кеширует его. - Корневые серверы и серверы TLD — они не знают ответа, но знают, кто его знает. Корень указывает на
.com; серверы TLD.comуказывают на собственные серверы имён домена. - Авторитативные серверы имён — серверы, хранящие настоящие записи домена. Что бы они ни сказали, по определению это и есть истина.
Запрос шаг за шагом
Сначала проверяются локальные кеши
У браузера есть собственный кеш DNS, у ОС — тоже. Если в одном из них есть неистёкший ответ для
example.com, запрос завершается за микросекунды, и сетевого трафика нет вообще.Вопрос рекурсивному резолверу
При промахе stub-резолвер отправляет запрос настроенному рекурсивному резолверу — одним UDP-пакетом, обычно на порт 53.
Резолвер обращается к корневому серверу
Если в кеше резолвера ничего нет, он начинает с самого верха. Корневой сервер не знает
example.com, но отвечает: вот серверы имён для.com.Резолвер обращается к серверам TLD
Серверы
.comотвечают перенаправлением: авторитативные серверы имён дляexample.comвот эти. Это всё ещё не ответ, а очередной указатель.Резолвер обращается к авторитативному серверу имён
У этого сервера есть настоящий файл зоны. Он возвращает запись
A:93.184.216.34вместе с TTL, который говорит, как долго ответ можно использовать повторно.Ответ кешируется и возвращается
Резолвер кеширует результат на срок TTL и передаёт его вашей ОС, а та — браузеру. Только теперь может начаться TCP-соединение с сервером.
Рекурсивный и авторитативный: различие, которое имеет значение
Эти понятия постоянно путают, и это приводит к реальным ошибкам при отладке.
| Рекурсивный резолвер | Авторитативный сервер имён | |
|---|---|---|
| Задача | Найти ответ за вас | Хранить и публиковать ответ |
| Примеры | 1.1.1.1, 8.8.8.8, ваш провайдер | Cloudflare DNS, Route 53, ваш регистратор |
| Кеширует? | Да — это его основная задача | Нет, он сам источник |
| Кто его настраивает? | Вы или ваша сеть | Владелец домена |
Практическое следствие: когда вы меняете DNS-запись, авторитативный сервер обновляется мгновенно. Каждый рекурсивный резолвер в мире продолжает отдавать свою закешированную копию, пока не истечёт TTL. Этот разрыв люди и называют распространением DNS.
Что на самом деле возвращает резолвер
Ответ — это больше, чем адрес. Он несёт тип записи, значение и TTL, а также флаги, указывающие, был ли ответ авторитативным или взят из кеша. Один домен публикует сразу много типов записей: A и AAAA для адресов, MX для маршрутизации почты, NS для своих серверов имён и TXT для подтверждений и политик.
example.com. 3600 IN A 93.184.216.34
example.com. 3600 IN AAAA 2606:2800:220:1::248
example.com. 3600 IN MX 10 mail.example.com.
example.com. 86400 IN NS ns1.example.com.Число после имени — это TTL в секундах. IN означает класс «интернет». Остальное — тип записи и её значение.
Где DNS ломается на практике
- Изменение не распространилось. Авторитативный сервер верен; кеш между вами и им — нет. Чинить нечего, нужно только переждать.
- Серверы имён указывают на неправильного провайдера. Вы правили записи у регистратора, но домен делегирован серверам имён вашего хостинга, поэтому правки игнорируются.
- Пропущенная конечная точка. В файле зоны
mail.example.comбез конечной точки может быть истолковано относительно зоны, что дастmail.example.com.example.com. - Нет записи
AAAA, но есть клиенты только с IPv6. Для них сайт недоступен, хотя у всех остальных работает идеально.
Ключевой вывод
Если проблема с DNS проявляется на одном устройстве, но не на другом, это почти всегда кеш, а не сломанная запись. Прежде чем что-то менять, проверьте авторитативный ответ.
Каждую из этих записей для любого домена можно увидеть в инструменте поиска на главной странице: он запрашивает их независимо, поэтому если у домена какого-то типа нет, остальные всё равно отображаются.
Нужно проверить публичные DNS-адреса домена? Воспользуйтесь инструментом Domain IP Lookup.
Часто задаваемые вопросы
Читайте также
Рекурсивный DNS-запрос: шаг за шагом
Браузер
нужен example.com
Резолвер
ваш провайдер / 1.1.1.1
Корень + TLD
кто отвечает за .com?
Авторитетный
настоящий ответ
Каждый шаг цепочки — тоже DNS-запрос, и его ответ потом кэшируется
Что такое сервер имён: как работает делегирование домена
Единственная настройка, которая решает, какой провайдер управляет вашим DNS, и причина, по которой правки записей иногда не дают вообще никакого эффекта.
Записи, которые встретятся почти в каждой зоне
Типы DNS-записей: полный справочник
Каждый стоящий внимания тип записи: что он делает, как выглядит и какую ошибку с ним допускают чаще всего — на одной странице справочника.
Выбор TTL на практике
Что такое DNS TTL: как выбрать правильное значение
Одно число определяет, как быстро вступают в силу изменения и сколько DNS-трафика вы создаёте. Как выбрать его осознанно.