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

Автор: Кирилл Бодров, технический аккаунт-менеджер EdgeCenter.

DNS (Domain Name System, система доменных имён) — это распределённая база данных, которая переводит понятные человеку имена вроде example.ru в IP-адреса, по которым устройства реально обмениваются данными. Когда вы вводите адрес в браузере, до загрузки первого байта страницы происходит цепочка запросов через несколько независимых серверов, и занимает она обычно от 1 до 150 миллисекунд.

Разберём эту цепочку по шагам, обсудим, почему изменения «долетают» неравномерно, что такое TTL и как диагностировать проблемы с резолвингом.

Полная цепочка резолвинга: что происходит за 100 миллисекунд

Пользователь ввёл example.ru. Дальше система последовательно проверяет несколько источников, останавливаясь на первом, который дал ответ.

Шаг 1. Кеш браузера. У браузера собственный кеш DNS, независимый от системного. Живёт минуты. Именно из-за него правка файла hosts иногда «не срабатывает» до перезапуска браузера.

Шаг 2. Кеш операционной системы. Служба разрешения имён хранит недавние ответы. В Windows это DNS Client, в Linux — systemd-resolved или локальный кеширующий демон.

Шаг 3. Файл hosts. Статическое соответствие имён и адресов на вашей машине. Имеет приоритет над всей остальной цепочкой, на нём построено тестирование сайта до переключения DNS.

Шаг 4. Рекурсивный резолвер. Если локально ответа нет, запрос уходит на резолвер — обычно DNS-сервер вашего провайдера или публичный сервис. Резолвер берёт на себя всю дальнейшую работу и возвращает готовый ответ.

Шаг 5. Корневые серверы. Резолвер, если у него нет ничего в кеше, спрашивает корневые серверы. Они не знают адрес example.ru, но знают, кто отвечает за зону .ru.

Шаг 6. Серверы зоны верхнего уровня. Серверы .ru тоже не знают адрес сайта, но знают, каким серверам делегирована зона example.ru.

Шаг 7. Авторитативные серверы домена. Те самые NS-серверы, которые указаны у регистратора. Вот они уже дают окончательный ответ: example.ru → конкретный IP.

Шаг 8. Ответ возвращается и кешируется на каждом уровне на срок, заданный TTL-записью.

Ключевой момент: шаги 5–7 выполняются полностью только при «холодном» кеше. В реальности резолвер провайдера обслуживает тысячи клиентов, адреса популярных зон у него уже есть, и типичный запрос обходится одним обращением. Полная цепочка занимает 50–150 мс, ответ из кеша — единицы миллисекунд.

Рекурсивный и итеративный запрос: в чём разница

У DNS есть два режима работы, которые постоянно путают.

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

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

Разделение важно для понимания ролей: авторитативные серверы отвечают только за свою зону и не выполняют поиск (рекурсию) для посторонних. Сервер, который ищет данные для всех подряд, называется открытым резолвером — это уязвимая конфигурация, которую используют для amplification-атак. Если вы поднимаете собственный DNS, проверьте, что рекурсия разрешена только для вашей сети.

Кто есть кто в DNS

При этом регистратор и DNS-хостинг — разные функции. У регистратора вы указываете, какие серверы обслуживают зону. Сами записи вы правите там, куда делегирована зона. Правка A-записи в панели регистратора не даст эффекта, если NS указывают на другого провайдера.

TTL: почему изменения долетают не сразу

Каждая DNS-запись отдаётся вместе со сроком жизни в секундах. Этот срок жизни указывается с в специальной DNS-записи, TTL. Это указание всем кеширующим серверам: «можешь хранить ответ столько времени, дальше спроси заново».

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

Практический приём, который стоит запомнить: за 24–48 часов до любой миграции снизьте TTL до 300 секунд. После успешного переключения и периода наблюдения верните обычное значение. Это превращает откат из суточной операции в пятиминутную.

Негативное кеширование. Отдельная и часто неожиданная деталь: ответ «такой записи нет» тоже кешируется, причём срок задаётся не TTL, а параметром в SOA-записи зоны. Поэтому если вы создали запись после того, как кто-то её запросил и получил отказ, ждать придётся дольше, чем кажется. Проверяйте значение минимального TTL в SOA — часто там стоит неоправданно большое число, унаследованное из шаблона.

Как выглядит зона изнутри

Зона — это набор записей, описывающих домен. В формате BIND, который используется для экспорта и импорта почти везде, выглядит так:

Что здесь важно:

• SOA описывает параметры зоны. Поле serial обязано увеличиваться при каждой правке — по нему вторичные серверы понимают, что зона обновилась. Последнее число задаёт негативное кеширование.
• NS-записи должны совпадать с тем, что указано у регистратора. Расхождение — источник плавающих проблем: часть резолверов пойдёт по одним серверам, часть по другим.
• Точка в конце имени означает полное доменное имя. example.ru без точки внутри зоны развернётся в example.ru.example.ru — классическая ошибка при ручной правке.
• @ обозначает сам домен, корень зоны.

Делегирование: как домен привязывается к серверам

Цепочка делегирования — это то, что связывает вашу зону с остальной системой.

1. Регистратура зоны .ru хранит информацию о том, каким NS-серверам делегирован домен example.ru.
2. Вы указываете эти NS в панели регистратора.
3. Серверы .ru начинают отвечать на запросы о вашем домене: «спросите у ns1.provider.ru и ns2.provider.ru».
4. Эти серверы отдают записи зоны.

Glue records. Особый случай: если ваши NS-серверы находятся внутри самого домена (ns1.example.ru обслуживает example.ru), возникает замкнутый круг — чтобы узнать адрес ns1.example.ru, нужно спросить ns1.example.ru. Разрывается он склеивающими записями: регистратура хранит IP-адреса этих серверов и отдаёт их вместе с делегированием. Если вы используете DNS-хостинг провайдера, glue records вас не касаются.

Частая ошибка: сменить NS у регистратора, не создав зону у нового провайдера. Делегирование указывает на серверы, которые про домен ничего не знают, и он становится недоступен пользователям.

Диагностика: dig, nslookup и чтение вывода

Умение читать вывод dig закрывает большинство вопросов «почему сайт не открывается».

Базовый запрос:

dig example.ru A

Смотреть нужно на три вещи: секцию ANSWER SECTION с самим ответом, флаг статуса и значение TTL.

Проверить, что отдают конкретные серверы. Это ключевая команда при миграции: она обращается напрямую к серверу, минуя кеш:

dig @ns1.provider.ru example.ru A

Если новый провайдер отдаёт правильный ответ, а публичный резолвер — старый, значит, конфигурация верна, и вы просто ждёте истечения TTL.

Посмотреть всю цепочку делегирования:

dig +trace example.ru

Вывод покажет путь от корневых серверов через зону .ru до ваших авторитативных серверов. Незаменимо, когда домен «то работает, то нет».

Проверить NS, которые видит мир:

dig example.ru NS +short

Проверить почтовые записи:

dig example.ru MX +short
dig example.ru TXT +short

Если вы работаете на Windows, dig там не установлен по умолчанию, но есть nslookup:

nslookup example.ru
nslookup -type=MX example.ru
nslookup example.ru ns1.provider.ru

Последняя форма — обращение к конкретному серверу, аналог dig @. Учтите, что nslookup беднее по выводу: он не показывает TTL и флаги статуса, поэтому для разбора сложных случаев лучше поставить dig (входит в пакет BIND utilities) или воспользоваться Resolve-DnsName в PowerShell:

Resolve-DnsName example.ru -Type A -Server ns1.provider.ru

Как сбросить локальный кеш, если подозреваете, что видите устаревший ответ:

ipconfig /flushdns                          # Windows
sudo systemd-resolve --flush-caches         # Linux с systemd-resolved
sudo dscacheutil -flushcache                # macOS

Отдельно сбросьте кеш браузера — он независим от системного. В Chrome это страница chrome://net-internals/#dns.

Расшифровка статусов:

Отдельно про SERVFAIL. Это самый недооценённый статус. В большинстве случаев за ним стоит нарушенная цепочка DNSSEC: DS-запись у регистратора не соответствует ключам зоны. Домен при этом полностью недоступен для всех резолверов, которые проверяют подписи, — а таких большинство.

Типичные проблемы и их причины 

Сколько раз DNS срабатывает при загрузке одной страницы

Типичная страница подтягивает ресурсы с нескольких доменов: собственный домен, поддомен статики, CDN, шрифты, аналитика, рекламные сети, виджеты чата, платёжный провайдер, карты. На коммерческом сайте таких доменов обычно от 8 до 25, и каждый требует отдельного резолвинга при первом обращении.

Худший сценарий — мобильный пользователь на нестабильной сети, впервые зашедший на сайт: холодный кеш, каждый новый домен добавляет от 50 до 200 мс, причём последовательно, потому что браузер узнаёт о стороннем домене только после разбора HTML.

Что с этим делать:

• Сократить число доменов. Каждый удалённый сторонний скрипт убирает целый резолвинг. Аудит третьих сторон обычно находит два-три виджета, которые никто не помнит зачем ставили.
• dns-prefetch — подсказка браузеру заранее разрешить имя, пока он занят другим: <link rel="dns-prefetch" href="//cdn.example.ru">.
• preconnect —помимо резолвинга устанавливает TCP-соединение и выполняет TLS-рукопожатие. Но каждое соединение расходует ресурсы, поэтому применять его надо только к двум-трём критичным доменам.
• Избегать цепочек CNAME. Если static.example.ru указывает на cdn.provider.ru, а тот на edge.pop.provider.ru, резолвинг растягивается на несколько итераций.
• Не хранить критичную статику на отдельном домене. Один домен вместо двух экономит резолвинг и позволяет переиспользовать уже открытое соединение.

Почему это важно: резолвинг напрямую связан с показателями скорости, а они влияют на поведенческие факторы и SEO. Резолвинг входит в TTFB и, соответственно, в LCP.

DNS во внутренней инфраструктуре

Помимо публичной зоны, DNS обычно работает и внутри вашего периметра, и там свои особенности.

Внутренние зоны. Серверы, сервисы и базы данных адресуются по именам вида db-01.internal, а не по IP. Это позволяет менять адреса, не переписывая конфигурации.

Split-horizon (split-brain) DNS. Одно и то же имя отдаёт разные адреса в зависимости от того, откуда пришёл запрос: изнутри сети — внутренний адрес, снаружи — публичный. Это типовой сценарий для корпоративных сервисов и источник трудноуловимых проблем. «В офисе работает, а из дома нет» — почти всегда об этом.

Service discovery. В Kubernetes и подобных средах DNS — основной механизм поиска сервисов: имя сервиса резолвится в адрес, за которым стоит балансировка по подам. Здесь TTL традиционно очень короткий, а нагрузка на внутренний DNS высокая.

Типичные проблемы внутреннего DNS:

• Приложение кеширует результат резолвинга на весь срок работы процесса, игнорируя TTL. Классика для JVM-приложений со старыми настройками. Адрес сервиса изменился, а приложение ходит на старый до перезапуска.
• Внутренние имена пересекаются с реальными публичными доменами. Если вы выбрали для внутренней зоны имя, которое кто-то зарегистрировал в интернете, утечка запросов наружу становится вопросом времени.
• Приложение с настроенным DoH обходит корпоративный резолвер и не видит внутренние зоны.

Приватность и безопасность DNS

Кто видит ваши запросы. Классический DNS передаётся открытым текстом. Резолвер провайдера видит каждое имя, которое вы запрашиваете, — фактически историю посещений. Промежуточные узлы тоже могут наблюдать этот трафик.

Проблему решают шифрованные протоколы: DoT (DNS over TLS, отдельный порт) и DoH (DNS over HTTPS, неотличим от обычного веб-трафика). Но при этом они шифруют сам DNS-запрос и не скрывают, куда вы затем подключаетесь, адрес назначения виден в любом случае.

Кратко назовём основные риски со стороны безопасности:

Про subdomain takeover стоит сказать отдельно. Очень частая проблема: команда завела promo.example.ru с CNAME на внешний сервис, кампания закончилась, аккаунт в сервисе удалили, а DNS-запись забыли. Теперь любой может зарегистрировать этот ресурс у того же провайдера и получить контроль над поддоменом вашего домена со всеми последствиями для доверия, cookie и почтовой репутации. Проверяется инвентаризацией всех CNAME на предмет того, что целевой ресурс существует и принадлежит вам.

Чек-лист здоровья DNS-зоны

Проходите раз в квартал — занимает пятнадцать минут.

• Все указанные NS-серверы отвечают, в списке нет наследия прошлых провайдеров
• NS-записи в зоне совпадают с делегированием у регистратора
• Серверы находятся в разных сетях, а не в одном дата-центре
• Значение serial в SOA увеличивается при правках
• Минимальный TTL в SOA не завышен — от него зависит негативное кеширование
• TTL записей соответствует их изменчивости, нет 60 секунд на стабильных записях
• MX-записи актуальны, тестовое письмо доходит
• SPF, DKIM и DMARC настроены и не содержат устаревших включений
• Все CNAME указывают на существующие ресурсы, принадлежащие вам
• Нет забытых поддоменов от прошлых проектов и тестовых сред
• CAA-записи ограничивают, какие центры сертификации могут выпускать сертификаты для домена
• DNSSEC либо корректно работает, либо выключен целиком — промежуточного состояния быть не должно
• У регистратора включена двухфакторная аутентификация и запрет на передачу домена
• Есть актуальный экспорт зоны в формате BIND
• Домен продлён с запасом и настроено автопродление

Что влияет на скорость резолвинга

DNS — первый шаг любого соединения, и он выполняется до того, как начнётся установка TCP. Экономия здесь сказывается на каждой сессии.

Расположение авторитативных серверов. Если ваши NS стоят только в Москве, а пользователь во Владивостоке, каждый несохранённый в кеше запрос стоит ему лишних 60–90 мс. Это решается с помощью глобального распределённого DNS-хостинга (такого, как EdgeDNS) с поддержкой Anycast, с помощью которого один адрес анонсируется из десятков точек, и пользователь попадает на ближайшую.

Число обращений. Цепочка CNAME, где одно имя указывает на другое, а то на третье, множит число запросов. Особенно заметно на мобильных сетях.

TTL. Слишком короткий TTL означает постоянные повторные запросы. Значение в 60 секунд для стабильной записи — это лишняя нагрузка без пользы.

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

Что означает «домен не резолвится»: алгоритм разбора

Самая частая аварийная ситуация. Порядок действий, который сужает поиск за несколько минут.

Шаг 1. Проверьте делегирование у регистратора. Какие NS указаны для домена и не истёк ли срок регистрации. Просроченный домен — банальная, но регулярная причина, особенно если оплата шла с карты, срок действия которой закончился.

dig example.ru NS +short
whois example.ru | grep -i -E "nserver|paid-till|state"

Шаг 2. Проверьте, отвечают ли сами NS-серверы. Обращайтесь к каждому напрямую:

dig @ns1.provider.ru example.ru A
dig @ns2.provider.ru example.ru A

Если один отвечает, а другой нет — проблема в конфигурации зоны у провайдера или в самом сервере. Если не отвечают оба, а делегирование верное — зона не создана или удалена.

Шаг 3. Пройдите цепочку целиком. Команда dig +trace example.ru покажет, на каком именно звене всё обрывается: корень, зона .ru или ваши серверы.

Шаг 4. Исключите DNSSEC. Если предыдущие шаги показывают корректную конфигурацию, а публичные резолверы отдают SERVFAIL, почти наверняка дело в нарушенной цепочке подписей:

dig example.ru +dnssec
dig example.ru +cd          # запрос с отключённой проверкой подписей

Если с флагом +cd ответ приходит, а без него — SERVFAIL, диагноз подтверждён: DS-запись у регистратора не соответствует ключам зоны.

Шаг 5. Сравните разные резолверы. Если один публичный резолвер отдаёт ответ, а другой нет, вы, скорее всего, наблюдаете переходный период после изменений — часть кеша ещё хранит старые данные.

Как выбрать DNS-хостинг

Отдельно про вторичный DNS: держать зону сразу у двух независимых провайдеров — недорогая страховка от отказа одного из них. При падении первого резолверы автоматически обращаются ко второму. Для критичных сервисов это стандартная практика.

Часто задаваемые вопросы

Что такое DNS? Это система, которая переводит понятные человеку доменные имена вроде example.ru в IP-адреса, по которым устройства обмениваются данными. Работает как распределённый справочник: запрос последовательно проходит через кеш, резолвер провайдера, корневые серверы, серверы зоны и доходит до серверов, обслуживающих ваш домен.

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

Что такое TTL в DNS? Срок в секундах, в течение которого кэширующие серверы могут хранить полученный ответ и не запрашивать его заново. Короткий TTL ускоряет применение изменений, но увеличивает нагрузку на ваши серверы. Длинный экономит запросы, но растягивает миграцию.

В чём разница между регистратором и DNS-хостингом? У регистратора вы владеете доменом и указываете, какие NS-серверы его обслуживают. DNS-хостинг — это сервис, где физически хранятся и отдаются записи зоны. Если NS указывают на стороннего провайдера, правка A-записи в панели регистратора ничего не изменит.

Почему сайт открывается у меня, но не у других? Почти всегда дело в кешировании: разные резолверы обновляют записи в разное время. Проверьте, что отдают напрямую ваши авторитативные серверы командой dig @ns1.provider.ru example.ru. Если ответ там правильный, конфигурация верна и нужно дождаться истечения TTL.

Что такое рекурсивный запрос? Запрос, при котором клиент просит вернуть окончательный ответ, а не промежуточную подсказку. Так ваш компьютер обращается к резолверу провайдера. Резолвер, в свою очередь, использует итеративные запросы к корневым серверам и серверам зон, каждый из которых отвечает только «спроси вот у этих».

Можно ли поставить CNAME на корневой домен? Стандарт этого не допускает: у корня зоны обязательно есть SOA и NS-записи, а CNAME не может сосуществовать с другими записями того же имени. Провайдеры решают задачу нестандартными типами — ALIAS, ANAME или CNAME flattening, которые внешне ведут себя как CNAME, но отдают итоговый адрес.

Что делать, если dig возвращает SERVFAIL? Чаще всего это нарушенная цепочка DNSSEC: DS-запись у регистратора не соответствует ключам, которыми подписана зона. Такое происходит при смене DNS-провайдера без предварительного отключения DNSSEC. Проверьте командой dig example.ru +dnssec и при подтверждении отключите DNSSEC у регистратора, дождитесь распространения, затем настройте заново.

Сколько NS-серверов должно быть у домена? Минимум два, и они должны быть в разных сетях, а лучше — в разных дата-центрах. Это требование к отказоустойчивости: при недоступности одного резолверы обратятся к другому. Убедитесь, что все указанные серверы действительно работают — неотвечающий NS в списке добавляет задержку на таймаут.

Влияет ли DNS на скорость загрузки сайта? Влияет, потому что резолвинг предшествует установке соединения и выполняется до загрузки первого байта. Экономия составляет десятки миллисекунд на каждом новом домене в цепочке. Наибольший эффект даёт anycast-размещение серверов рядом с аудиторией и отказ от длинных цепочек CNAME.