Что такое система доменных имён (DNS)?

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

В этом руководстве: почему DNS больше, чем телефонная книга интернета · как на самом деле работает разрешение имён · домен, DNS, сервер имён и хостинг — в чём разница · распространённые типы записей DNS · что на самом деле означает «распространение DNS» · как безопасно изменить DNS · как проверить свои записи · основы безопасности DNS · частые ошибки · чек-лист миграции · часто задаваемые вопросы.

Почему DNS — это больше, чем телефонная книга интернета

Сравнение с телефонной книгой — разумная отправная точка: оно передаёт базовую идею поиска имени, чтобы найти что-то техническое. Но оно заметно не дотягивает до того, что DNS делает на самом деле.

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

DNS также возвращает больше, чем адреса. Один домен может публиковать записи, которые направляют почту, подтверждают владение доменом для стороннего сервиса, определяют, какие удостоверяющие центры могут выпускать сертификаты, указывают на совершенно другие сервисы или делегируют поддомен другому провайдеру. Адресация веб-сайта — одна из задач DNS, а не единственная.

Как работает разрешение DNS: пошагово

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

1.  Браузер, операционная система или приложение запрашивает имя — например, ищет example.com.

2.  Стаб-резолвер устройства, лёгкий клиент, встроенный в операционную систему, передаёт запрос рекурсивному резолверу, который обычно работает у интернет-провайдера, публичного DNS-сервиса или в корпоративной сети.

3.  Рекурсивный резолвер сначала проверяет собственный кэш. Если у него уже есть пригодный, не устаревший ответ, он возвращает его немедленно, ни к кому больше не обращаясь.

4.  Если пригодного кэшированного ответа нет, резолвер от имени клиента опрашивает иерархию DNS.

5.  Он начинает с корневого сервера имён, который сам не знает ответа, но направляет резолвера к нужным серверам имён домена верхнего уровня (TLD) — в данном случае к серверам, отвечающим за .com.

6.  Сервер имён TLD тоже не знает окончательного ответа, но направляет резолвера конкретно к авторитативным серверам имён example.com.

7.  Резолвер запрашивает авторитативный сервер имён, который хранит фактическую зону DNS домена и возвращает запрошенную запись — или соответствующий ответ, если записи не существует.

8.  Рекурсивный резолвер кэширует результат в соответствии с TTL (временем жизни) записи и возвращает ответ запрашивающему устройству.

Большая часть этого происходит за миллисекунды. Благодаря кэшированию резолверу часто не нужно повторять полный путь по иерархии для каждого запроса.

Рекомендуемая диаграмма: процесс разрешения имени

[Для живой страницы рекомендуется оригинальная диаграмма, а не заимствованная графика. Предлагаемая схема:]

Устройство / приложение

-> стаб-резолвер

-> рекурсивный резолвер (сначала проверяет кэш)

-> корневой сервер имён (перенаправление)

-> сервер имён TLD (перенаправление)

-> авторитативный сервер имён (возвращает запись)

-> рекурсивный резолвер (кэширует согласно TTL)

-> устройство

Домен, DNS, сервер имён, регистратор и хостинг: в чём разница

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

Распространённые типы записей DNS

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

Что на самом деле означает «распространение DNS»

«Распространение» — удобное отраслевое выражение, но оно описывает видимый эффект, а не сам механизм. Изменения DNS не копируются одновременно на каждое устройство в интернете. На самом деле происходит истечение кэша, распределённое по множеству независимых резолверов, каждый по своему собственному расписанию.

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

Поэтому два человека могут запросить один и тот же домен в один момент времени и на короткое время получить разные ответы: их трафик может проходить через разные рекурсивные резолверы, каждый со своей кэшированной копией и своим оставшимся TTL. Это не ошибка ни в одном из ответов — оба были верны на момент кэширования.

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

•  Очистка кэша браузера — не то же самое, что очистка кэша DNS операционной системы или рекурсивного резолвера — устойчивый результат может независимо сохраняться в любом из них, и исправление одного не исправляет остальные.

•  Смена серверов имён несёт сразу два вида риска — риск делегирования (указание на неверные авторитативные серверы) и риск содержимого зоны (в новой зоне отсутствуют записи, которые были в старой).

•  «До 24–48 часов» — это приблизительное, часто упоминаемое окно, а не техническая гарантия — фактическое время зависит от задействованных значений TTL и поведения отдельных резолверов и может быть короче или длиннее.

Как безопасно изменить DNS

Это три разных действия с тремя разными профилями риска. Их смешение — одна из самых частых причин ошибок, которых можно было избежать.

A. Смена серверов имён

Это полностью делегирует домен другому авторитативному DNS-провайдеру — по сути заменяя всю зону целиком. Из трёх действий это самое значительное по влиянию, поскольку одновременно могут измениться все записи, ранее опубликованные доменом, включая те, о которых вы забыли.

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

Б. Редактирование записей DNS

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

В. Смена резолвера на устройстве

Это меняет, к какому рекурсивному резолверу обращается ваш компьютер или телефон — например, переход от резолвера интернет-провайдера по умолчанию к публичному сервису. Это влияет на скорость поиска и, в зависимости от резолвера, на конфиденциальность и фильтрацию. На фактически опубликованные записи домена это никак не влияет.

Процесс безопасной миграции сайта или почты

1.  Экспортируйте или иным образом полностью задокументируйте текущую зону DNS, прежде чем что-либо менять.

2.  Определите каждую запись, связанную с сайтом, почтой, верификацией и безопасностью, используемую в настоящее время — не только те, что вы помните.

3.  Подтвердите целевые значения с новым провайдером или сервером, на который вы переходите.

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

5.  Полностью создайте и проверьте новую зону, прежде чем менять делегирование на неё.

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

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

8.  Держите старый сервис доступным в течение переходного периода, а не отключайте его сразу.

9.  Активно отслеживайте сбои во время переключения, а не проверяйте только один раз в конце.

10.  Держите наготове протестированный план отката, который вы действительно сможете выполнить под давлением, а не просто держите его в уме.

Замена серверов имён без воссоздания записей MX, TXT (включая SPF и DKIM), DMARC и верификационных записей — одна из самых частых причин прерывания почты и поломки сторонних интеграций после миграции.

Как проверить записи DNS

Инструмент публичного DNS-поиска показывает DNS-данные, видимые в данный момент через путь запроса этого инструмента. Он помогает изучить записи A, AAAA, MX, TXT, NS и другие для домена — до или после изменения, но его результат не доказывает, что каждый рекурсивный резолвер в мире уже обновил свой кэш; где-то резолвер может по-прежнему отдавать более старый, не истёкший ответ.

Основы безопасности DNS

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

•  Двухфакторная аутентификация — как для аккаунта регистратора, так и для отдельного аккаунта управления DNS, поскольку это могут быть разные логины.

•  Доступ по принципу минимальных привилегий — предоставляйте членам команды только тот уровень доступа, который им действительно нужен, а не полный контроль над аккаунтом по умолчанию.

•  Ограниченные учётные данные API — если вы автоматизируете изменения DNS, ограничивайте область действия API-ключей и регулярно их обновляйте.

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

•  Блокировка регистратора и восстановление доступа — понимайте, как можно восстановить доступ к аккаунту при его потере, и защищайте этот путь.

•  DNSSEC — добавляет аутентификацию источника и проверку целостности к ответам DNS, затрудняя определённые атаки подмены и отравления кэша. Он не шифрует обычные DNS-запросы и не скрывает активность просмотра — это отдельная задача, решаемая другими технологиями.

•  Мониторинг изменений серверов имён и записей — неожиданные изменения часто становятся первым видимым признаком компрометации аккаунта.

•  Защита email-адреса владельца регистрации и администратора — этот почтовый ящик часто служит путём восстановления доступа ко всему аккаунту; потеря контроля над ним сама по себе серьёзный риск.

•  Журналы изменений и записи для отката — ведите датированную запись о том, что изменилось и какими были предыдущие значения, чтобы можно было быстро отменить неудачное изменение.

Ни одна из этих мер, по отдельности или вместе, не делает аккаунт неуязвимым для любой атаки — они снижают риск и сокращают время восстановления, что является реалистичной целью.

Частые ошибки в DNS

•  Замена серверов имён без предварительного копирования существующей зоны.

•  Удаление записей MX, SPF, DKIM, DMARC или верификационных записей во время миграции сайта, часто потому что никто не задокументировал их существование.

•  Добавление CNAME там, где при том же имени уже существуют конфликтующие записи.

•  Указание записи MX напрямую на IP-адрес вместо имени хоста.

•  Путаница между трансфером регистратора и сменой серверов имён — это разные действия с разными последствиями.

•  Предположение, что любая проблема с DNS — это «распространение», вместо проверки на фактическую неправильную настройку.

•  Редактирование DNS одновременно у нескольких провайдеров во время миграции с потерей понимания, какой из них авторитативен.

•  Полное забывание об IPv6 или сохранение устаревшей записи AAAA, указывающей на старый сервер.

•  Установка значений TTL, необычно длинных или необычно коротких, без операционной причины для этого.

•  Внесение изменений без сохранения предыдущих значений для отката.

Практический чек-лист миграции

☐  Полный экспорт текущей зоны DNS сохранён перед любым изменением

☐  Каждая запись, связанная с сайтом, почтой, верификацией и безопасностью, определена и внесена в список

☐  Целевые значения подтверждены с новым провайдером или сервером

☐  TTL снижен заблаговременно, чтобы старые кэшированные ответы успели истечь

☐  Новая зона создана и проверена перед изменением делегирования

☐  Изменения по возможности внесены по одному уровню за раз

☐  Корневой домен протестирован после изменения

☐  www (или эквивалент) протестирован после изменения

☐  Доставка почты протестирована после изменения

☐  Критичные поддомены протестированы после изменения

☐  Записи MX, SPF, DKIM и DMARC отдельно проверены, а не просто предполагаются

☐  Старый сервис оставался активным в течение переходного периода

☐  Активный мониторинг настроен на время переключения

☐  Протестированный, задокументированный план отката готов перед началом

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

DNS размещает мой сайт?

Нет. DNS сообщает устройствам, где найти ваш сайт, публикуя записи вроде A или AAAA, указывающие на адрес вашего хостинг-сервера. Сами файлы, база данных и приложение работают на хостинг-сервере — DNS это запись в справочнике, а не само здание.

DNS — это то же самое, что сервер имён?

Нет. DNS — это общая система и протокол; сервер имён — конкретный сервер, отвечающий на запросы DNS, либо авторитативно для зоны, либо рекурсивно от имени клиента. Серверы имён домена — это одна часть того, как DNS работает для этого домена, а не вся система.

В чём разница между авторитативным DNS-сервером и рекурсивным резолвером?

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

Сколько времени занимают изменения DNS?

Это зависит от TTL задействованных записей и от того, как отдельные резолверы кэшируют ответы — часто упоминаемые окна вроде «24–48 часов» являются приблизительным ориентиром, а не технической гарантией. Запись с коротким, заранее сниженным TTL может обновиться намного быстрее; давно закэшированный ответ может сохраняться у отдельных резолверов далеко за пределами типичной оценки.

Что происходит при смене серверов имён?

Вы делегируете домен другому авторитативному DNS-провайдеру, который заменяет всю ранее использовавшуюся зону домена — не одну запись. Каждый тип записи, на который полагался домен, включая MX, TXT и верификационные записи, должен корректно существовать в новой зоне, иначе соответствующий сервис может перестать работать.

Что такое DNSSEC?

DNSSEC (Domain Name System Security Extensions) добавляет к ответам DNS криптографические подписи, чтобы резолвер мог проверить, что запись действительно пришла из легитимного авторитативного источника и не была изменена в пути. Он защищает целостность и происхождение ответов DNS, а не содержимое вашего сайта или почты.

DNSSEC шифрует DNS-трафик?

Нет. DNSSEC обеспечивает аутентификацию источника и целостность данных — доказательство того, что ответ подлинный и неизменённый. Он не шифрует ни запрос, ни ответ и не скрывает, какие домены ищет устройство; это отдельная задача, решаемая другими технологиями.

Могут ли мой регистратор и провайдер DNS быть разными компаниями?

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

Могут ли мой сайт и почта использовать разных провайдеров?

Да, и это распространённая практика. DNS делает это возможным, позволяя разным типам записей указывать на разные назначения — запись A или AAAA может указывать на одного хостинг-провайдера, в то время как записи MX указывают на совершенно отдельный сервис почты, и всё это в рамках одной зоны DNS.

Почему мой сайт работает для одних пользователей, но не для других после изменения DNS?

Обычно это связано с кэшированием, а не с неудачным изменением. Трафик разных пользователей проходит через разные рекурсивные резолверы, и каждый может по-прежнему хранить кэшированный ответ с момента до вашего обновления, действительный до истечения его TTL. Несоответствие обычно устраняется само по себе по мере истечения каждого кэша.

Изменение DNS ускоряет интернет?

Не напрямую. Смена используемого рекурсивного резолвера может повлиять на то, насколько быстро разрешаются запросы, и хорошо настроенный, географически близкий резолвер может немного сократить время отдельных запросов, но разрешение DNS — лишь малая часть общего времени загрузки страницы. Оно не увеличивает скорость вашего соединения и не обходит сетевые ограничения.

Как проверить, существуют ли ещё мои записи MX и TXT?

Используйте инструмент DNS-поиска, чтобы напрямую запросить текущие записи MX и TXT домена и сравнить их с задокументированными ожидаемыми значениями. Это показывает, что инструмент поиска возвращает по этим записям сейчас — самый прямой способ обнаружить запись, случайно потерянную во время миграции.

Главное в двух словах

•  DNS связывает доменные имена с техническими сервисами за ними — адресами, почтовыми серверами, верификационными данными и другим, а не только с одним IP-адресом на домен.

•  Многие сбои, связанные с DNS, возникают из-за отсутствующих или конфликтующих записей, ошибок делегирования либо миграций без документированного плана — а не из-за загадочных задержек «распространения».

•  Безопасные изменения зависят от актуальной копии зоны, тщательной проверки, поэтапного внедрения, активного мониторинга и по-настоящему рабочего плана отката.

Проверьте свой DNS перед внесением изменений

Проверяйте публичные записи DNS, MX, TXT, NS и связанные с ними записи вашего домена до и после миграции. При сложных переносах сайта и почты храните проверенную копию текущей зоны и вносите изменения поэтапно, меняя за один раз только одну часть конфигурации.

Также полезно: Управление бизнес-критичными доменами