Как DNS превращает домен в адрес: путь запроса от браузера до сервера
Когда вы вводите адрес сайта в браузере, компьютер не знает, куда отправлять запрос. Доменное имя — это просто удобная метка для человека, а не реальный адрес для машин. Чтобы найти сервер, браузер обращается к системе доменных имён (DNS). Она работает как распределённая телефонная книга: вместо того чтобы помнить числовые адреса всех сайтов, вы запоминаете имена, а система подставляет нужный адрес.
Запрос начинается с резолвера — программы, которая ищет ответ на вопрос “какой адрес у этого домена?”. Резолвер может быть локальным (на вашем компьютере или роутере) или публичным (например, у интернет-провайдера). Если резолвер не знает ответа, он обращается к корневым серверам DNS. Эти серверы не хранят адреса всех сайтов, но знают, кто отвечает за каждую зону верхнего уровня — например, за .com или .ru. Корневые серверы отдают адреса серверов TLD (.com, .ru), которые хранят делегирование: NS-записи домена, заданные через регистратора. Серверы TLD направляют резолвер на авторитетные серверы домена, и только эти серверы возвращают сами записи A, AAAA, CNAME, MX.
Серверы зоны — это те, на которые делегирован домен. Они хранят все записи о домене: какой IP-адрес соответствует имени, какие есть псевдонимы, какие серверы обрабатывают почту. Когда резолвер получает ответ от сервера зоны, он сохраняет его в кеше на время, указанное в записи — это называется TTL (time to live). Если TTL истекает, резолвер снова обращается к серверу зоны за свежим ответом.
Кеш нужен для экономии времени и ресурсов. Без него каждый запрос к сайту требовал бы обращения к нескольким серверам по всему миру. Но кеш может стать источником проблем: если запись изменилась, а TTL ещё не истёк, резолвер будет возвращать устаревший адрес.
Какие DNS-записи ломаются чаще всего и почему
Не все записи в DNS одинаково важны. Чаще всего проблемы возникают с адресными записями (A и AAAA), которые связывают домен с IP-адресом. Если такая запись отсутствует или содержит неверный адрес, сайт не откроется. Проблемы с псевдонимами (CNAME) тоже встречаются часто: например, если настроить www.example.com как псевдоним для example.com, но забыть создать запись для example.com, сайт будет недоступен по обоим адресам.
Почтовые записи (MX) ломаются реже, но если они неверны, почта не будет доставляться. Делегирование зоны — ещё один частый источник проблем. Если домен делегирован на серверы DNS-хостинга, а изменения вносятся в панели регистратора, их никто не увидит. Это как если бы вы изменили номер телефона в записной книжке, но не сообщили об этом оператору связи — звонки всё равно будут идти на старый номер. Серверы TLD хранят NS-записи домена, и только они направляют резолвер на авторитетные серверы зоны.
Как проверить DNS напрямую, минуя все кеши
Когда сайт не открывается, первое, что стоит сделать — проверить ответ авторитетного сервера напрямую. Это можно сделать с помощью команды dig:
Проверяйте обе адресные записи: dig A example.com и dig AAAA example.com, с @адресом авторитетного сервера и без него.
Сначала узнайте, на какие серверы реально делегирован домен (dig NS example.com или dig +trace). Затем сравните ответ этих серверов с ожидаемым IP. Совпадение ответа резолвера с авторитетным исключает кеш, но не ошибку в самой записи.
Для этого можно пройти всю цепочку запросов с помощью:
dig +trace example.comЭта команда покажет весь путь запроса: от корневых серверов до серверов TLD (.com, .ru), которые отдают NS-записи домена, а затем до авторитетных серверов домена, возвращающих сами записи. Если на каком-то этапе ответ отличается от ожидаемого, проблема именно там.
Почему TTL снижают заранее при переезде сайта
Время жизни записи (TTL) определяет, как долго резолверы хранят ответ в кеше. Если планируется переезд сайта на новый сервер, TTL снижают минимум за один старый TTL до переезда: пока старый ответ лежит в кешах, резолверы не знают о новом коротком TTL. Если снизить в день переезда, часть резолверов продержит старый адрес весь старый срок.
Механизм работает так: когда TTL высокий, резолверы хранят ответ долго. Если изменить запись при высоком TTL, часть пользователей будет видеть старый адрес до тех пор, пока не истечёт срок кеша. Если снизить TTL заранее, резолверы будут чаще обращаться за свежими данными.
Снижение TTL — это страховка. Если что-то пойдёт не так при переезде, можно быстро откатить изменения. Если TTL не снижен, откат займёт столько же времени, сколько и распространение изменений.
Тупик: почему сброс кеша и ожидание не помогают
Когда сайт не открывается, многие первым делом сбрасывают кеш DNS на своём компьютере. Кажется логичным: если кеш устарел, его нужно очистить. Но на практике это редко решает проблему.
Локальный кеш — лишь один из многих уровней кеширования. Даже если вы очистили его на своём компьютере, резолвер провайдера или публичный резолвер всё ещё может возвращать старый адрес. Кроме того, браузеры тоже кешируют DNS-запросы, и этот кеш не очищается при сбросе системного.
Другой распространённый тупик — ожидание после изменения записей. Если TTL высокий, изменения действительно могут распространяться долго. Но если сайт всё равно не открывается после ожидания, проблема скорее всего не в кеше. Стоит проверить, где именно расхождение: в ответе резолвера или авторитетного сервера.
Самая частая причина, почему ожидание не помогает — изменения внесены не в ту зону. Например, если домен делегирован на серверы DNS-хостинга, а изменения внесены в панели регистратора, их никто не увидит. Серверы TLD хранят NS-записи домена, и только авторитетные серверы зоны знают об изменениях в записях A, AAAA, CNAME или MX.
Когда DNS ни при чём: сервер, сертификат или прокси
Если ответ авторитетного сервера верный, но сайт не открывается, проблема может быть не в DNS. Например, 502 и 504 означают, что ответил прокси, а бэкенд за ним нет. Если сервер по IP не отвечает, браузер покажет ошибку соединения (тайм-аут или отказ, например ERR_CONNECTION_TIMED_OUT или ERR_CONNECTION_REFUSED).
В этом случае нужно проверить доступность сервера по IP с указанием имени хоста:
curl --resolve example.com:443:IP https://example.comЭтот запрос обходит DNS и напрямую обращается к серверу по указанному IP, но использует правильное имя хоста в заголовке. Если этот запрос проходит, а обычный — нет, проблема в DNS. Если оба запроса не проходят, дело в сервере, сети или сертификате.
Например, если сертификат истёк или неверно настроен, браузер не сможет установить защищённое соединение. В этом случае стоит обратиться к разборам о настройке HTTPS. Позиция неверна, когда домен делегирован на сеть доставки. Если делегирование настроено на DNS сети доставки, её серверы становятся авторитетными и отдают адреса узлов CDN, которые могут отличаться в разных регионах. Адрес origin в этом случае задаётся отдельно в настройках CDN, и проверять его нужно напрямую, например через curl --resolve.
Позиция редакции
Первым делом стоит проверять ответ авторитетного сервера, а не свой резолвер. Это позволяет быстро исключить DNS из списка возможных причин проблем. Однако эта рекомендация не работает, когда домен делегирован на сеть доставки.
Если делегирование настроено на DNS сети доставки, авторитетными становятся её серверы. Они отдают адреса узлов CDN, которые зависят от региона, а адрес origin задаётся в настройках CDN. Если CDN подключена через CNAME, делегирование не меняется: авторитетный сервер домена отдаёт CNAME на имя CDN, а адреса узлов выдаёт уже DNS самой CDN. В обоих случаях origin проверяют отдельно — например, через curl --resolve.
Если сеть доставки настроена неверно, она может блокировать запросы или возвращать неверные адреса для отдельных регионов. В этом случае проблема не в системе доменных имён, а в конфигурации сети. Стоит проверить настройки прокси или обратиться к разбору об обратном прокси.