Домен куплен, хостинг оплачен, сайт загружен на сервер, но по привычному адресу ничего не открывается. Или открывается сайт, зато перестала приходить почта. Еще интереснее бывает после переезда: с одного компьютера посетитель уже видит новую версию, с другого продолжает открываться старая. Виновником в таких ситуациях часто называют DNS, хотя сама система обычно работает совершенно нормально. Ошибка находится в одной записи, лишней точке, старом IP-адресе или попытке изменить сразу все настройки, не разобравшись, за что отвечает каждая из них.
DNS кажется сложным только до тех пор, пока перед глазами находится таблица с буквами A, AAAA, CNAME, MX, TXT, NS, TTL и непонятными значениями. На практике владельцу обычного сайта не требуется становиться сетевым инженером. Достаточно понимать несколько типов записей и знать, что произойдет после их изменения.
Особенно полезно разобраться в DNS, если домен и хостинг куплены у разных компаний, сайт переезжает на другой сервер, подключается корпоративная почта или требуется подтвердить владение доменом для стороннего сервиса. В этих ситуациях DNS превращается из незаметной технической системы в обычный рабочий инструмент.
Что такое DNS и зачем он нужен сайту
У сервера есть IP-адрес, а у сайта есть понятное человеку доменное имя. Браузеру необходимо связать одно с другим. Этим и занимается Domain Name System, сокращенно DNS. В самом упрощенном виде она отвечает на вопрос: «Куда отправить пользователя, который ввел этот домен?»
Если вы только знакомитесь с устройством сайтов, сначала полезно понимать разницу между хостингом и доменным именем. Хостинг предоставляет ресурсы сервера, а домен служит постоянным адресом проекта. DNS связывает эти две части.
При этом DNS умеет значительно больше, чем просто указывать IP сайта. Через него определяется, какие серверы принимают почту домена, куда ведет поддомен, какие DNS-серверы являются авторитетными для зоны, а также публикуются служебные данные для подтверждения владения доменом и защиты электронной почты.
Поэтому фраза «настроить DNS» сама по себе ничего не объясняет. Сначала нужно определить задачу. Для привязки сайта к серверу потребуется одна запись, для почты другая, для подтверждения домена третья.
Чем DNS-запись отличается от DNS-сервера
Это один из главных источников путаницы. В панели регистратора можно увидеть и поля для NS-серверов, и редактор DNS-зоны. Они связаны между собой, но выполняют разные функции.
NS указывает, какие серверы отвечают за DNS-зону домена. А уже внутри этой зоны находятся A, AAAA, MX, TXT, CNAME и другие записи.
Представим, что домен зарегистрирован у одной компании, а хостинг куплен у другой. Можно заменить NS домена на серверы хостинг-провайдера. После этого редактировать DNS-зону нужно будет у хостера. Другой вариант состоит в том, чтобы оставить NS регистратора и просто изменить A-запись на IP нового сервера. Оба подхода рабочие.
Главное правило простое: редактировать записи нужно там, где фактически обслуживается DNS-зона. Если NS указывают на серверы регистратора, изменение A-записи в панели хостинга может вообще ни на что не повлиять.
A-запись: как домен связывается с IPv4-адресом
A-запись является одной из самых понятных. Она связывает имя с IPv4-адресом.
Допустим, сервер сайта имеет адрес 192.0.2.25. Для основного домена example.ru создается A-запись, значением которой будет этот IP. После распространения DNS браузеры узнают, на какой сервер отправлять запросы к example.ru.
В редакторе зоны корневой домен может обозначаться символом @, полным именем или пустым полем. Это зависит от панели управления. Поэтому не стоит механически копировать инструкцию для другого регистратора: обозначения интерфейса могут отличаться, хотя сама DNS-запись остается той же.
A-запись особенно важна при переносе сайта. Если новый сервер уже подготовлен, достаточно изменить IP, чтобы постепенно направить посетителей на новую площадку. Сам перенос сайта на другой хостинг лучше выполнить до переключения DNS, чтобы новый сервер был полностью готов принимать трафик.
AAAA-запись и IPv6
AAAA выполняет похожую задачу, но связывает доменное имя с IPv6-адресом. Такой адрес выглядит заметно длиннее привычного IPv4.
Наличие AAAA не является обязательным условием работы обычного сайта. Если хостинг поддерживает IPv6 и вы понимаете, какой адрес нужно указать, запись можно использовать. Если поддержки нет, создавать AAAA «для современности» не требуется.
Особенно неприятна ситуация, когда A-запись уже ведет на новый рабочий сервер, а забытая AAAA продолжает указывать на старую или недоступную машину. Часть пользователей может обращаться к сайту по IPv6 и видеть совсем не тот результат, который ожидает владелец.
Поэтому при миграции проверяют не только A, но и существующие AAAA-записи.
CNAME: когда одно имя указывает на другое
CNAME позволяет сделать одно доменное имя псевдонимом другого имени. В отличие от A-записи, здесь обычно указывается не IP-адрес, а другой hostname.
Например, поддомен www можно направить на основной домен. Или отдельный поддомен использовать для стороннего сервиса, который просит создать CNAME с определенным значением.
Это удобно, когда конечный IP может меняться без участия владельца домена. Сторонний сервис управляет своей инфраструктурой, а ваша запись продолжает ссылаться на предоставленное им имя.
Однако CNAME нельзя бездумно ставить везде вместо A. Для корня домена действуют ограничения DNS, а некоторые провайдеры предлагают собственные варианты вроде ALIAS или ANAME. Если инструкция сервиса прямо говорит создать CNAME для конкретного поддомена, лучше следовать именно ей.
Что делать с www: A или CNAME
Адреса example.ru и www.example.ru технически являются разными именами. Если вы хотите, чтобы сайт открывался в обоих вариантах, DNS должен знать о каждом из них.
Для www часто создают CNAME на основной домен. Возможен и вариант с отдельной A-записью на тот же IP.
Но DNS решает только вопрос доставки запроса. Какой адрес будет основным для посетителей и поисковых систем, определяется уже настройками веб-сервера и сайта. Обычно выбирается один вариант, а второй перенаправляется на него постоянным редиректом.
Например, если основным является https://example.ru, то запрос к https://www.example.ru должен приводить туда же через корректное перенаправление. Не стоит оставлять две независимые копии сайта только потому, что обе DNS-записи работают.
MX-записи: почему сайт работает, а почта нет
MX сообщает, какие серверы принимают электронную почту для домена. Поэтому можно идеально настроить сайт и одновременно полностью сломать корпоративную почту, если при изменении DNS забыть перенести MX.
Такое часто происходит при замене NS-серверов. В старой DNS-зоне были настроены MX, TXT для SPF, DKIM и другие почтовые записи. Владелец меняет NS на серверы нового хостинга, создает A-запись для сайта и считает задачу выполненной. Сайт действительно открывается, но письма на адрес info@example.ru перестают доходить.
Причина проста: вместе со сменой NS фактически сменилась вся обслуживаемая DNS-зона, а почтовые записи в нее не перенесли.
Если почта размещается отдельно от сайта, при переезде хостинга MX вообще не обязательно менять. Важно сохранить существующие значения в новой зоне.
Приоритет MX-записей
У MX есть параметр приоритета. Чем меньше число, тем выше приоритет сервера. Например, почтовая система может предоставить несколько MX со значениями 10, 20 и 30.
Не нужно самостоятельно менять эти числа ради «ускорения почты». Они задают порядок, в котором отправляющая сторона должна обращаться к серверам.
Если почтовый провайдер дал точный набор MX-записей, их лучше внести без творческих изменений. Это относится и к именам серверов, и к приоритетам.
TXT-запись: обычный текст с очень важной работой
TXT выглядит наиболее свободной записью, поскольку содержит текстовое значение. На практике через нее решается множество служебных задач.
Сайт или сервис может попросить добавить TXT для подтверждения владения доменом. Почтовые системы используют TXT для SPF и других механизмов. В DNS могут публиковаться различные токены проверки и политики безопасности.
Главная ошибка новичка состоит в попытке «улучшить» полученное значение. Если сервис выдал длинную строку подтверждения, ее нужно скопировать точно. Лишний пробел, потерянный символ или вставленные кавычки способны сделать проверку нерабочей.
При этом наличие нескольких TXT-записей само по себе нормально. Нельзя лишь бездумно создавать несколько конфликтующих SPF-политик для одного имени.
SPF, DKIM и DMARC тоже связаны с DNS
Когда используется почта на собственном домене, одной MX-записи недостаточно для хорошей доставляемости.
SPF помогает определить, какие серверы имеют право отправлять письма от имени домена. DKIM позволяет проверять цифровую подпись сообщения. DMARC задает политику обработки писем, которые не проходят необходимые проверки, и может использоваться для отчетности.
Настройки зависят от конкретной почтовой платформы, поэтому универсальную строку SPF или DKIM нельзя брать из случайной статьи и вставлять в свой домен.
Если почта обслуживается сторонним сервисом, именно он должен предоставить нужные значения. DNS в этой схеме служит местом публикации настроек, а не источником самих параметров.
NS-записи: кто управляет DNS-зоной
NS, или Name Server, определяют авторитетные серверы имен для домена. Именно к ним в конечном итоге обращается система DNS за актуальной информацией о зоне.
После покупки домена и хостинга провайдер часто предлагает указать свои NS. Для новичка это удобно: домен, сайт и DNS оказываются в одной панели.
Но перенос NS требует внимательности. Вместе с ним нужно перенести все необходимые записи старой зоны. Недостаточно помнить только IP сайта. Могут существовать MX для почты, TXT для подтверждений, CNAME для сервисов и отдельные поддомены.
Перед заменой NS полезно открыть старую зону и сохранить ее содержимое. Еще лучше заранее создать необходимые записи на новых DNS-серверах, если провайдер позволяет это сделать до переключения.
Что такое TTL и почему DNS не меняется мгновенно
TTL расшифровывается как Time To Live. Параметр определяет, сколько времени DNS-ответ может храниться в кэше до повторного запроса актуальной информации.
Именно кэширование объясняет странную картину после изменения IP: владелец уже видит новый сайт, коллега продолжает видеть старый, а проверка через другой DNS-сервер показывает третье состояние.
Это не означает, что интернет «сломался». Разные резолверы могли сохранить предыдущую запись в разное время.
Если серьезный перенос планируется заранее, TTL иногда уменьшают до миграции. Тогда старые значения быстрее перестают использоваться. После завершения работ TTL можно вернуть к обычному значению.
Снижать его за пять минут до изменения уже не так полезно, поскольку предыдущая запись с большим TTL могла быть закэширована раньше.
Почему фраза «DNS обновляется 72 часа» не совсем точна
В инструкциях часто встречается совет просто ждать до 24, 48 или 72 часов. Такой запас удобен поддержке, но создает впечатление, будто после каждого изменения запускается обязательный многодневный процесс.
На практике многое зависит от типа изменения, TTL, кэшей провайдеров и конкретной инфраструктуры. Новое значение нередко становится заметно значительно быстрее.
При этом старый кэш у отдельных пользователей действительно может сохраняться некоторое время.
Поэтому после изменения DNS правильнее не только ждать, но и проверять, какие ответы возвращают разные DNS-серверы. Если спустя разумное время авторитетные серверы сами отдают неправильное значение, ожидание ничего не исправит. Нужно искать ошибку в зоне.
Зачем очищать DNS-кэш на компьютере
Операционная система тоже может кэшировать DNS-ответы. Поэтому после изменения записи компьютер иногда продолжает обращаться к старому IP.
В Windows для очистки локального DNS-кэша используется команда `ipconfig /flushdns`, запущенная в командной строке с подходящими правами.
Но очистка локального кэша не заставляет весь интернет немедленно забыть старые записи. Она влияет только на конкретное устройство. Если устаревшее значение находится у DNS-резолвера интернет-провайдера, локальная очистка может не изменить результат.
Для проверки удобно сравнивать ответы нескольких независимых DNS-серверов.
Почему после смены DNS сайт открывается у одних и не открывается у других
Это классическая ситуация во время миграции.
Часть резолверов уже получила новый IP, часть продолжает использовать закэшированный старый. Если старый сервер выключили сразу после изменения A-записи, пользователи со старым DNS-ответом увидят недоступный сайт.
Поэтому старую площадку разумно некоторое время оставлять работающей. Особенно это важно для коммерческих проектов, где даже несколько часов недоступности означают потерянные обращения или заказы.
При переносе динамического сайта возникает дополнительная проблема: посетители могут одновременно попадать на две копии. Для магазина это уже риск расхождения заказов и базы данных. Миграцию таких проектов нужно планировать внимательнее, чем перенос обычной визитки.
Почему после смены NS перестала работать почта
Если до изменения NS почта работала, а после перестала, первым делом сравните MX и связанные TXT-записи старой и новой зон.
Сам сайт может продолжать работать идеально, потому что A-запись была создана правильно. Почтовая инфраструктура при этом никак не обязана находиться на том же сервере.
Особенно легко потерять DKIM. Его значение бывает длинным и визуально не связано с привычными настройками сайта. В результате письма технически отправляются, но возникают проблемы с аутентификацией и доставляемостью.
При любом переносе DNS-зоны нужно рассматривать ее целиком, а не только как строку с IP сайта.
Можно ли держать домен и хостинг у разных компаний
Да. Это совершенно нормальная схема.
Домен может быть зарегистрирован у одного регистратора, DNS обслуживаться другим сервисом, сайт находиться на третьей площадке, а почта работать у четвертого поставщика.
Такая конфигурация дает гибкость, но требует понимания связей между компонентами. Новичку часто удобнее единая панель, поскольку меньше мест, где можно ошибиться.
При этом перенос сайта не требует обязательного переноса домена к новому регистратору. Если текущий регистратор устраивает, достаточно изменить DNS-настройки.
Само доменное имя является отдельным активом, поэтому при выборе и регистрации полезно заранее разобраться, как устроены домены и их жизненный цикл.
Нужно ли менять NS при каждом переезде сайта
Нет.
Если DNS-зона уже обслуживается удобным и надежным сервисом, а меняется только сервер сайта, часто достаточно обновить A и при необходимости AAAA.
Это даже упрощает миграцию: почтовые и служебные записи остаются на месте, а изменяется только адрес веб-сервера.
Замена NS имеет смысл, если вы действительно хотите передать управление всей DNS-зоной другому провайдеру. Делать это только потому, что новый хостер прислал свои nameserver в приветственном письме, необязательно.
Как не сломать DNS при переносе сайта
Самая безопасная стратегия начинается не с изменения записей, а с подготовки нового сервера.
Сначала переносится сайт и база данных. Новая копия проверяется без переключения основного домена, например через технический адрес или локальную подмену hosts. Проверяются PHP, база, формы, HTTPS и основные функции.
Затем фиксируются текущие DNS-записи. Если меняется только сервер, определяется, какие A и AAAA нужно обновить. Если меняются NS, на новых серверах заранее создается полная зона.
После переключения старый хостинг не удаляют в ту же минуту. Ему дают время обслужить пользователей, которые еще получают старые DNS-ответы.
И только когда новый сайт стабильно работает, а DNS распространился, старую площадку можно отключать. Перед удалением данных не помешает сделать отдельный бэкап сайта и сохранить его вне старого аккаунта.
DNS и SSL: почему сертификат иногда не выпускается
Бесплатный SSL-сертификат часто выпускается автоматически через панель хостинга. Для проверки домена центр сертификации должен убедиться, что запрос относится к нужному сайту.
Если A-запись еще ведет на старый сервер, домен вообще не разрешается или www направлен в другое место, автоматическая проверка может завершиться ошибкой.
Поэтому после переезда сначала убеждаются, что нужные имена корректно указывают на новый сервер, и только потом разбираются с выпуском сертификата.
Сам HTTPS и DNS решают разные задачи. DNS помогает найти сервер, а SSL-сертификат защищает HTTPS-соединение и подтверждает соответствие сертификата используемому имени.
DNS и CDN: кто в такой схеме куда указывает
После подключения CDN схема может измениться. Домен начинает указывать не прямо на исходный сервер, а на инфраструктуру сети доставки контента или обратного прокси.
CDN принимает запрос посетителя и уже затем обращается к origin-серверу, если нужных данных нет в кэше или запрос требует обработки приложением.
Именно поэтому после подключения такого сервиса обычная проверка IP может показать адрес, который не принадлежит вашему хостингу. Это нормально.
Перед изменением записей полезно понимать, как CDN взаимодействует с хостингом, иначе можно случайно обойти прокси, направив домен прямо на origin, или наоборот создать неправильную цепочку.
Почему нельзя копировать DNS-настройки из случайной инструкции
В DNS мало универсальных значений.
IP зависит от вашего сервера. MX предоставляет ваш почтовый сервис. DKIM генерируется для конкретной почтовой конфигурации. TXT для подтверждения выдает тот сервис, который требует проверку. CNAME тоже должен вести на конкретное имя.
Поэтому инструкция полезна для понимания того, какую запись создать, но не обязательно для копирования ее значения.
Если в статье написано «создайте A-запись 192.0.2.1», это почти наверняка пример. В реальной зоне должен находиться IP именно вашего сервера.
Почему две одинаковые записи могут мешать друг другу
Несколько A-записей для одного имени технически допустимы и могут использоваться для распределения запросов. Но если владелец не планировал такую схему, оставшийся старый IP способен создать очень странное поведение.
Один запрос попадет на новый сервер, другой на старый. Пользователь обновит страницу и внезапно увидит другую версию сайта.
Похожая проблема возникает с AAAA, о которой забыли после смены IPv4.
Поэтому перед добавлением новой записи нужно посмотреть, что уже существует для этого имени. Не всегда правильное действие заключается в создании еще одной строки. Иногда нужно изменить или удалить старую.
Как проверить DNS после изменения
Начать можно с самого простого: проверить, какой IP возвращается для основного домена и www, затем сравнить его с ожидаемым адресом.
Если настраивалась почта, отдельно проверяются MX. Для подтверждений и почтовых политик смотрят TXT. При смене NS убеждаются, что авторитетными стали именно новые серверы.
Важно проверять не только со своего компьютера. Независимый DNS lookup помогает увидеть данные со стороны и исключить влияние части локального кэша.
Если результаты отличаются, нужно учитывать TTL и время после изменения. Если же авторитетный сервер возвращает неверные данные, ждать бессмысленно: ошибка уже находится в самой зоне.
Какие DNS-записи нужны обычному сайту
Для простого сайта набор может быть совсем небольшим. Обычно требуется запись, направляющая основной домен на сервер, и настройка www. Если используется IPv6, добавляется AAAA. При почте на домене появляются MX и необходимые TXT. Сторонние сервисы могут добавить свои CNAME или TXT.
Не существует правила, что «правильная» зона должна содержать десять или двадцать записей.
Чем меньше лишних элементов, тем проще сопровождение. Создавать записи на будущее нет смысла.
Особенно не стоит сохранять старые записи неизвестного назначения после многолетних переносов. Но удалять их наугад тоже нельзя. Сначала нужно определить, какой сервис их использует.
Что сохранить перед любым серьезным изменением DNS
Сделайте снимок или экспорт текущей зоны. Запишите старые NS и IP. Если работает корпоративная почта, отдельно сохраните MX, SPF, DKIM и DMARC. Зафиксируйте настройки важных поддоменов.
Такая копия занимает несколько минут, зато дает понятную точку возврата.
Полезно также записывать время изменения. Когда через несколько часов кто-то сообщает, что у него «все еще старый сайт», вы сможете сопоставить это с TTL и понять, похоже ли поведение на обычное кэширование.
Если DNS меняет не владелец, а разработчик, после завершения работ стоит получить краткое описание того, что именно было изменено. Через год эта информация может оказаться значительно полезнее памяти.
Когда проблема вообще не в DNS
DNS часто обвиняют просто потому, что он непонятен.
Если домен уже разрешается в правильный IP и сервер отвечает, ошибка 500 обычно связана не с DNS. Если страница открывается, но загружается десять секунд, изменение nameserver тоже вряд ли поможет. Если сертификат истек, это отдельная задача.
Медленная работа требует своей диагностики скорости сайта, а серверные ошибки нужно искать по HTTP-коду и журналам.
Полезная привычка состоит в том, чтобы сначала определить уровень проблемы. Домен не разрешается вообще? Проверяем DNS. Домен ведет на неправильный IP? Проверяем A и AAAA. Запрос приходит на правильный сервер, но приложение отвечает 500? DNS уже выполнил свою работу.
Самая опасная кнопка в DNS-панели
У DNS нет одной особенно опасной кнопки. Опасна привычка менять несколько вещей одновременно.
Владелец видит, что сайт не открывается, и за пять минут меняет NS, A-запись, удаляет AAAA, включает проксирование CDN и заодно перевыпускает SSL. После этого становится практически невозможно понять, что было первоначальной проблемой и какое действие создало новую.
Гораздо надежнее менять один понятный параметр и проверять результат.
Если вы знаете, что сайт переехал с IP 192.0.2.10 на 192.0.2.25, изменение A-записи имеет ясную цель. Если вы не можете объяснить, зачем меняете NS, лучше сначала разобраться, а уже потом нажимать «Сохранить».
DNS проще, когда понимаешь назначение каждой записи
Для владельца сайта вся система в итоге сводится к нескольким понятным ролям. A ведет имя на IPv4-адрес. AAAA делает то же для IPv6. CNAME связывает одно имя с другим. MX определяет почтовые серверы. TXT публикует служебную информацию. NS сообщает, где обслуживается DNS-зона. TTL влияет на срок хранения ответа в кэше.
Этого знания уже достаточно, чтобы спокойно привязать домен к хостингу, не потерять почту при переезде и понимать, почему изменение не всегда видно всем пользователям одновременно.
DNS хорошо работает именно тогда, когда владелец сайта почти о нем не вспоминает. Записи меняются редко, зато последствия неправильной настройки заметны мгновенно. Поэтому здесь особенно полезен принцип «сначала понять, потом менять».
Перед переносом сохраните текущую зону. Не выключайте старый сервер сразу после смены IP. Не забывайте о почтовых записях при замене NS. Проверяйте A и AAAA вместе. Не копируйте чужие значения из примеров и не пытайтесь лечить DNS там, где сервер уже отвечает конкретной ошибкой приложения.
Тогда таблица из A, MX, TXT и CNAME перестает выглядеть набором загадочных сокращений. Это всего лишь карта, которая объясняет интернету, где находится ваш сайт, кто принимает его почту и каким сервисам можно доверять.
