Вы набираете в браузере адрес сайта, нажимаете Enter и через секунду видите страницу. Кажется, что браузер просто «открыл домен». Но доменное имя само по себе не сообщает компьютеру, где физически находится сайт.
Серверу нужен сетевой адрес. Человеку намного удобнее запомнить hostingi.org, чем набор цифр IPv4 или длинную последовательность IPv6. Связать понятное имя с нужным ресурсом помогает DNS.
DNS часто сравнивают с телефонной книгой интернета. Сравнение неплохое, но немного упрощенное. Современный DNS хранит не только соответствие домена IP-адресу. Через него определяется, где обслуживается почта, какие серверы отвечают за доменную зону, как подтверждается владение доменом и многое другое.
Чтобы понять DNS без лишней теории, проще проследить, что происходит после ввода адреса сайта.
Вы набрали адрес сайта, но браузер пока не знает, куда идти
Допустим, пользователь вводит example.ru.
Первым делом компьютер пытается выяснить IP-адрес, связанный с этим именем. При этом запрос не обязательно сразу отправляется куда-то далеко. Нужный ответ мог сохраниться в кэше браузера, операционной системы или DNS-резолвера, которым пользуется устройство.
Если свежего ответа нет, начинается поиск.
Обычно устройство обращается к рекурсивному DNS-резолверу. Его может предоставлять интернет-провайдер, публичный DNS-сервис или корпоративная сеть. Задача резолвера заключается в том, чтобы найти ответ за клиента.
DNS устроен иерархически. В верхней части этой системы находятся корневые серверы. Они не хранят IP каждого сайта в интернете. Вместо этого они помогают определить, где искать информацию о доменной зоне следующего уровня.
Для example.ru поиск приведет к инфраструктуре зоны .RU, а затем к авторитетным DNS-серверам конкретного домена. Именно авторитетный сервер содержит опубликованные владельцем или DNS-провайдером записи зоны.
Получив нужную запись, резолвер возвращает результат пользователю и обычно сохраняет его в кэше на время, определенное TTL.
Только после разрешения имени браузер может устанавливать соединение с сервером, который должен обслужить сайт.
В реальной жизни весь процесс часто выглядит быстрее этого описания, потому что DNS активно использует кэширование.
Где находятся DNS-записи домена
После регистрации домена для него указываются DNS-серверы. Их часто называют NS-серверами или серверами имен.
Они сообщают интернету, где находится авторитетная информация о зоне домена.
Например, домен можно зарегистрировать у одной компании, разместить сайт у второй, а DNS обслуживать у третьей. Это совершенно нормальная схема.
Регистратор отвечает за регистрацию доменного имени. Хостинг предоставляет место или сервер для сайта. DNS-сервис хранит и обслуживает записи зоны. На практике одна компания часто предлагает все три услуги, поэтому создается впечатление, что домен, DNS и хостинг являются одним целым.
Это не так.
И понимание этой разницы очень помогает при переездах. Если сайт переносится на другой хостинг, домен необязательно переносить к новому регистратору. Иногда достаточно изменить одну DNS-запись.
A и AAAA показывают адрес сервера
Самая понятная DNS-запись называется A.
Она связывает имя с IPv4-адресом. Условно запись может говорить: сайт example.ru находится по адресу 203.0.113.10.
AAAA выполняет похожую функцию для IPv6.
Если хостинг выдал владельцу сайта IP и попросил «направить домен на сервер», чаще всего речь идет именно о создании или изменении A-записи, а при использовании IPv6 еще и AAAA.
У домена могут существовать отдельные записи для основного имени и поддоменов. Например, example.ru направляется на один сервер, api.example.ru на другой, а old.example.ru на третий.
Это одна из причин не менять DNS вслепую. За одним доменом иногда скрывается несколько независимых сервисов.
CNAME нужен, когда удобнее сослаться на другое имя
CNAME связывает одно доменное имя с другим доменным именем.
Представим поддомен shop.example.ru. Вместо жесткой привязки к определенному IP он может ссылаться на адрес, который предоставил внешний сервис.
Это удобно, когда IP конечной системы контролируете не вы. Внешний поставщик может изменить свою инфраструктуру, а CNAME продолжит указывать на его имя.
CNAME особенно часто встречается при подключении сторонних платформ, CDN и различных веб-сервисов.
Но воспринимать его как универсальную замену A-записи не стоит. Для CNAME существуют правила и ограничения, а конкретная DNS-платформа может предлагать дополнительные механизмы для корневого имени домена.
MX отвечает за почту, и именно о нем часто забывают при переезде
Сайт работает, но письма на info@example.ru перестали приходить. Такая ситуация нередко возникает после неосторожной смены DNS.
MX-записи определяют почтовые серверы, которые должны принимать почту для домена.
У MX есть приоритет. Если записей несколько, почтовая система использует эти значения для выбора сервера, причем меньшее числовое значение означает более высокий приоритет.
Вот почему перенос сайта и перенос почты являются разными задачами.
Можно направить A-запись на новый веб-сервер и вообще не менять MX, если почта продолжает обслуживаться прежним или отдельным почтовым сервисом.
А можно заменить NS-серверы целиком и случайно потерять старые MX-записи. Тогда веб-сайт заработает на новом хостинге, а почта сломается.
Перед сменой серверов имен всегда полезно сохранить всю существующую DNS-зону.
TXT выглядит невзрачно, но используется постоянно
TXT позволяет публиковать текстовые данные в DNS.
Обычный посетитель сайта этих записей не видит, зато они нужны множеству сервисов.
Через TXT часто подтверждают владение доменом. Сервис просит добавить определенную строку, затем проверяет DNS и убеждается, что человек действительно контролирует зону.
TXT также широко используется в почтовой инфраструктуре. SPF помогает описать, какие системы могут отправлять почту от имени домена. DKIM использует DNS для публикации данных, необходимых для проверки подписи сообщений. DMARC задает политику обработки писем, которые не проходят соответствующие проверки.
Поэтому набор непонятных длинных TXT-строк в панели не нужно удалять только ради «порядка». Сначала выясните, каким сервисам они принадлежат.
NS определяет, кто отвечает за DNS-зону
NS-записи указывают серверы имен, авторитетные для домена или делегированной зоны.
Именно здесь важно различать изменение отдельной записи и смену DNS-сервиса целиком.
Если вы меняете A-запись, вы фактически говорите существующей DNS-системе: теперь сайт находится по другому IP.
Если вы меняете NS у регистратора, вы говорите: теперь информацию о DNS-зоне нужно спрашивать у других серверов.
Во втором случае новая зона должна содержать все необходимые записи. A, AAAA, MX, TXT, CNAME и другие данные не «переезжают» автоматически только потому, что вы указали новые NS.
Некоторые сервисы умеют импортировать обнаруженные записи, но результат все равно стоит проверять вручную.
Что такое TTL и почему DNS не меняется мгновенно
TTL расшифровывается как Time To Live. Для обычного владельца сайта важнее практический смысл: TTL сообщает DNS-резолверам, как долго ответ можно хранить в кэше до повторной проверки.
Представим, что A-запись example.ru указывала на старый сервер. Резолвер запросил ее и сохранил ответ. Через десять минут владелец изменил IP.
Авторитетный DNS уже отдает новый адрес, но резолвер может продолжать использовать старый ответ, пока его кэш остается действительным.
Именно поэтому после смены DNS один человек иногда уже видит новый сайт, а другой еще попадает на старый.
Фраза «DNS распространяется по интернету» удобна, но немного вводит в заблуждение. Не существует единой волны, которая последовательно обходит весь мир и переписывает записи. Значительную роль играет истечение ранее закэшированных ответов.
Если переезд планируется заранее, TTL нужной записи можно уменьшить до переключения. Делать это за несколько минут до смены IP поздно: старое большое значение уже могло попасть в кэши.
После завершения работ TTL можно вернуть к обычному значению.
Почему после смены DNS сайт у вас работает, а у друга нет
Это не обязательно ошибка.
Ваш компьютер и компьютер друга могут использовать разные DNS-резолверы. Один уже запросил свежую запись, другой все еще хранит старую.
Дополнительный кэш может существовать в операционной системе, браузере, маршрутизаторе и других промежуточных системах.
Поэтому проверять изменение только с одного компьютера недостаточно.
Можно запросить DNS через разные резолверы или воспользоваться сервисами проверки DNS из нескольких точек. Но и здесь важно понимать, что вы проверяете. Если изменили A-запись, смотрите A. Если меняли серверы имен, проверяйте NS.
Очистка локального DNS-кэша иногда помогает увидеть свежий ответ на собственном компьютере, но она не заставляет весь интернет забыть старые данные.
Домен зарегистрирован, но сайт не открывается
Регистрация домена сама по себе не создает сайт.
Чтобы страница открывалась, должно одновременно выполняться несколько условий.
Домен зарегистрирован и активен. Для него настроены рабочие DNS-серверы. DNS-запись направляет имя на правильный IP или другой нужный адрес. На сервере добавлен этот домен. Веб-сервер знает, какой сайт показывать для имени. Если используется HTTPS, сертификат выпущен и настроен.
Нарушение любого звена может выглядеть для пользователя одинаково: «сайт не работает».
Например, правильная A-запись ведет на новый сервер, но владелец забыл добавить домен в панели хостинга. Запрос приходит куда нужно, однако сервер не знает, какой проект обслуживать.
Или сайт открывается по HTTP, но браузер показывает ошибку HTTPS, потому что сертификат еще не выпущен.
Или домен направлен правильно, но в браузере все еще виден старый сайт из-за кэша.
DNS является только одним звеном цепочки.
Можно ли держать домен и хостинг у разных компаний
Да, и это обычная практика.
Допустим, домен зарегистрирован у одного российского регистратора, сайт размещен на хостинге другой компании, DNS обслуживает отдельный сервис, а почта работает у четвертого поставщика.
Технически такая схема совершенно нормальна.
У нее даже есть преимущества. Смена хостинга не требует переноса домена. Можно выбрать DNS-сервис с нужными функциями. Почта не зависит от веб-сервера.
Минус заключается в том, что владельцу нужно понимать, где управляется каждый компонент. Когда доступы потеряны, а никто не помнит, у какой компании находятся NS, диагностика становится неприятной.
Для небольшого личного сайта хранить домен, DNS и хостинг у одного надежного провайдера иногда просто удобнее. Для бизнеса разделение сервисов может дать больше гибкости.
Здесь нет единственно правильной схемы.
Нужно ли менять NS при смене хостинга
Не всегда.
Это одна из самых полезных вещей, которую стоит запомнить.
Если DNS уже обслуживается там, где вы хотите его оставить, а меняется только сервер сайта, часто достаточно обновить A и при необходимости AAAA.
Почта, TXT-записи, поддомены и остальные настройки при этом останутся на месте.
Менять NS имеет смысл, когда вы действительно хотите передать обслуживание всей DNS-зоны другому провайдеру.
Например, DNS раньше предоставлял старый хостинг, от которого вы полностью отказываетесь. Тогда нужно создать зону у нового поставщика, перенести все записи, проверить их и изменить NS у регистратора.
Схема «новый хостинг прислал свои NS, значит обязательно нужно поставить их» не является универсальной.
Несколько DNS-записей могут работать одновременно и вести в разные места
DNS-зона похожа не на один указатель, а на набор правил.
Основной сайт может открываться с одного IP.
Поддомен api работает на другом сервере.
Почту принимает специализированный почтовый сервис.
Поддомен cdn указывает на внешнюю сеть доставки контента.
TXT подтверждает домен в сервисах и участвует в настройке почты.
Поэтому просьба «пришлите DNS сайта» технически не очень точна. Нужно понимать, какая именно запись интересует.
Это особенно важно перед удалением старых записей. Непонятный CNAME может оказаться частью работающего сервиса, а TXT поддерживать почтовую аутентификацию.
Как безопасно менять DNS
Сначала сохраните текущую зону. Скриншот лучше, чем ничего, но удобнее иметь список записей с типами, именами и значениями.
Определите, что именно требуется изменить. Если переезжает только сайт, возможно, достаточно одной A-записи.
Если планируется переключение NS, заранее создайте полную зону у нового DNS-провайдера. Не забудьте почту и поддомены.
При запланированном переезде заранее уменьшите TTL изменяемых записей, если это действительно нужно.
Не выключайте старый сервер сразу после переключения. Часть пользователей некоторое время может получать прежний адрес из кэша.
После изменения проверьте сайт, HTTPS, почту и важные поддомены.
Если что-то перестало работать, не начинайте хаотично менять все записи подряд. Сначала определите, на каком участке цепочки проблема.
Как понять, что проблема действительно в DNS
Есть несколько характерных признаков.
Домен не разрешается в IP вообще. Возвращается неправильный IP. После недавней смены часть пользователей видит старый сервер. Почта перестала работать после замены NS. Поддомен не открывается, хотя основной сайт доступен.
Но ошибка 500 на странице почти наверняка требует смотреть уже не DNS, а приложение или сервер. Медленная работа WordPress тоже обычно не исправляется изменением NS.
Если домен успешно указывает на правильный IP, запрос приходит на нужный сервер и тот отвечает ошибкой приложения, DNS свою работу уже выполнил.
Это простое разделение экономит массу времени при диагностике.
Нужно ли обычному владельцу сайта разбираться во всем DNS
Нет.
Для управления обычным сайтом достаточно понимать несколько вещей.
A и AAAA связывают имя с IP-адресом. CNAME связывает имя с другим именем. MX относится к приему почты. TXT используется для разных служебных задач и подтверждений. NS определяет, где обслуживается DNS-зона. TTL влияет на время хранения ответов в кэше.
Этого уже достаточно, чтобы не потерять почту при переносе сайта, не менять серверы имен без необходимости и понимать, почему новый IP не появляется у всех пользователей в одну секунду.
Все остальные детали можно изучать по мере необходимости.
DNS кажется сложным главным образом потому, что в панели управления пользователь сразу видит множество сокращений. Но за ними скрывается довольно понятная идея.
Человек помнит имя сайта. DNS помогает найти технические данные, связанные с этим именем. Разные типы записей отвечают за разные задачи, а кэширование позволяет не выполнять полный поиск при каждом открытии страницы.
И когда в следующий раз хостинг попросит «изменить A-запись» или почтовый сервис выдаст TXT для подтверждения домена, это уже не будет выглядеть как набор случайных букв.
