- Опубликовано: 25 июл 2026
- 24
Домен подключён, а сайт не открывается: DNS без мистики
Часть 5 из 14 · Серия «Хостинг без магии»
Домен зарегистрирован. Хостинг оплачен. Файлы загружены.
В панели хостинга сайт уже существует, SSL заказан, а рядом с доменом горит зелёная отметка:
Домен подключён
Владелец открывает адрес в браузере и видит:
- страницу регистратора;
- старый сайт;
- ошибку «Сервер не найден»;
- заглушку хостинга;
- сайт без
www, но ошибку сwww; - правильный сайт через мобильный интернет и старый — через домашний Wi-Fi;
- ошибку только на одном компьютере;
- совершенно другой сервер при подключении по IPv6.
Начинается знакомая последовательность:
обновить страницу
перезапустить браузер
перезагрузить роутер
удалить и снова добавить домен
поменять DNS ещё раз
подождать «распространения»
Иногда сайт действительно начинает открываться. Но что именно произошло, остаётся неизвестным.
Из-за этого DNS выглядит как система, где изменения «летают по интернету» неопределённое количество времени, а результат зависит от удачи.
На самом деле процесс можно разложить на несколько отдельных вопросов:
- Какие DNS-серверы отвечают за домен?
- Какой IP-адрес они возвращают для нужного имени?
- Не хранит ли кто-то старый ответ в кэше?
- Принимает ли выбранный сервер запросы именно для этого домена?
Проверяя эти уровни по порядку, большинство проблем можно найти за несколько минут.
DNS не открывает сайт
DNS выполняет более узкую задачу: сопоставляет доменное имя с технической информацией, например IP-адресом сервера.
Упрощённо:
Пользователь вводит:
example.com
↓
DNS сообщает:
203.0.113.25
↓
Браузер подключается:
203.0.113.25
↓
Веб-сервер выбирает:
сайт example.com
DNS не знает:
- в какой папке лежит сайт;
- установлен ли WordPress;
- правильно ли настроен PHP;
- работает ли база данных;
- существует ли SSL-сертификат;
- какой проект должен обслуживать веб-сервер;
- возвращает ли приложение ошибку 500.
Он лишь помогает найти сервер или другой сетевой ресурс.
Поэтому правильная DNS-запись ещё не гарантирует работающий сайт. Но без правильной записи браузер до нужного сервера вообще не доберётся.
У DNS есть несколько участников
Когда вы вводите домен, браузер обычно не обращается напрямую к DNS-серверу владельца сайта.
Упрощённая цепочка выглядит так:
браузер
↓
операционная система
↓
локальный роутер
↓
рекурсивный DNS-резолвер
↓
корневая зона
↓
зона доменной области
↓
авторитетные DNS-серверы домена
Рекурсивный резолвер ищет ответ от имени пользователя и может сохранять его в кэше. Авторитетный DNS-сервер хранит официальные записи конкретной DNS-зоны. ICANN определяет авторитетный сервер как DNS-сервер, на котором находится официальная база записей зоны, включая адреса веб- и почтовых серверов.
На практике важны два типа серверов:
- авторитетные — хранят актуальную конфигурацию домена;
- рекурсивные — получают эти данные и кэшируют их для пользователей.
Если авторитетный сервер уже отвечает правильно, а домашний провайдер ещё возвращает старое значение, проблема находится в кэше рекурсивного резолвера, а не в панели хостинга.
Уровень №1. Кто управляет DNS-зоной домена
Первое, что нужно проверить, — NS-записи.
NS расшифровывается как Name Server. Эти записи сообщают, какие авторитетные DNS-серверы отвечают за домен.
Пример:
example.com. NS ns1.hosting.example.
example.com. NS ns2.hosting.example.
Делегирование означает передачу ответственности за DNS-зону определённым авторитетным серверам. Чтобы делегирование начало действовать, родительская зона должна указывать на серверы, которым передана эта ответственность.
Где задаются NS-серверы
Обычно они задаются у регистратора домена.
Регистратор — компания, через которую зарегистрирован домен.
DNS-зона при этом может обслуживаться:
- самим регистратором;
- хостинг-провайдером;
- отдельным DNS-провайдером;
- CDN;
- собственной DNS-инфраструктурой.
Важно различать два места:
Панель регистратора
→ определяет, кому делегирован домен
Панель DNS-провайдера
→ хранит A, AAAA, CNAME, MX, TXT и другие записи
Если у регистратора указаны DNS-серверы хостинга, редактировать A-запись в старой панели регистратора бесполезно. Она больше не является авторитетным источником.
Первая частая ошибка: запись изменили не в той панели
Представим:
У регистратора указаны:
ns1.hosting.example
ns2.hosting.example
Но владелец меняет A-запись в DNS-редакторе регистратора:
example.com → 203.0.113.25
Эта зона не используется. Интернет спрашивает записи у ns1.hosting.example и ns2.hosting.example.
В панели регистратора всё выглядит правильно, но авторитетные серверы продолжают возвращать старый IP.
Как проверить реальные NS
В Linux, macOS или Windows с установленным dig:
dig NS example.com
Короткий вывод:
dig +short NS example.com
Пример результата:
ns1.hosting.example.
ns2.hosting.example.
Через nslookup:
nslookup -type=NS example.com
Если результат не совпадает с панелью, возможны варианты:
- изменение ещё кэшируется;
- домен не был сохранён;
- у регистратора произошла ошибка;
- проверяется не тот домен;
- делегирование настроено некорректно.
Вторая частая ошибка: NS смешаны
Иногда у домена указаны серверы двух разных провайдеров:
ns1.old-provider.example
ns2.old-provider.example
ns1.new-provider.example
ns2.new-provider.example
Если их DNS-зоны различаются, пользователи будут получать разные ответы.
Один авторитетный сервер скажет:
example.com → 192.0.2.10
Другой:
example.com → 203.0.113.25
Результат выглядит как случайность:
- сайт то старый, то новый;
- проблема появляется не у всех;
- обновление страницы иногда меняет результат;
- один публичный резолвер показывает один IP, другой — другой.
Все авторитетные серверы одной зоны должны отдавать согласованные данные.
Проверить каждый сервер отдельно:
dig @ns1.hosting.example example.com A
dig @ns2.hosting.example example.com A
Коротко:
dig +short @ns1.hosting.example example.com A
dig +short @ns2.hosting.example example.com A
Если ответы различаются, ждать бессмысленно: нужно исправить зоны или набор NS-серверов.
Уровень №2. На какой адрес указывает домен
После проверки NS переходим к записям адреса.
Для сайта чаще всего используются:
A;AAAA;CNAME.
Cloudflare описывает TTL как время, в течение которого DNS-резолвер может хранить ответ перед повторной проверкой, а CNAME — как ссылку одного имени на другое, которое в итоге должно привести к имени с действительной A- или AAAA-записью.
A-запись: IPv4-адрес
A-запись связывает имя с IPv4-адресом.
Пример:
example.com. A 203.0.113.25
Проверить:
dig +short example.com A
Результат:
203.0.113.25
Если хостинг сообщил другой IP, домен направлен не туда.
Что означает имя @
В DNS-панелях корень зоны часто обозначается:
@
Для зоны example.com запись:
@ A 203.0.113.25
обычно означает:
example.com A 203.0.113.25
Но некоторые панели ожидают:
- пустое поле;
- полное имя;
- имя без конечной точки.
Следуйте формату конкретной панели.
AAAA-запись: IPv6-адрес
AAAA-запись связывает имя с IPv6-адресом.
Пример:
example.com. AAAA 2001:db8::25
Проверка:
dig +short example.com AAAA
Если существует одновременно A и AAAA, часть пользователей может подключаться по IPv4, а часть — по IPv6.
Это создаёт неприятную ситуацию:
IPv4 → новый сервер
IPv6 → старый сервер
или:
IPv4 → сайт работает
IPv6 → соединение зависает
Почему нельзя забывать про старую AAAA-запись
Владелец меняет A-запись при переезде:
A → новый сервер
Но оставляет:
AAAA → старый сервер
На компьютере без IPv6 сайт работает правильно. На устройстве с IPv6 открывается старый сайт или появляется ошибка.
Проверять нужно оба типа:
dig +short example.com A
dig +short example.com AAAA
Если новый хостинг не предоставляет IPv6, ненужную AAAA-запись следует удалить.
Не стоит указывать случайный IPv6-адрес «на всякий случай».
CNAME: одно имя ссылается на другое
CNAME используется, когда одно доменное имя должно следовать за другим.
Например:
www.example.com. CNAME example.com.
Это означает:
www.example.com
↓
example.com
↓
203.0.113.25
Проверить:
dig +short www.example.com CNAME
Результат:
example.com.
Затем:
dig +short example.com A
CNAME не является перенаправлением браузера
При CNAME адрес в браузере не меняется.
Пользователь открывает:
www.example.com
DNS помогает найти сервер, но браузер продолжает отправлять HTTP-запрос для имени www.example.com.
Если нужно перенаправить пользователя:
www.example.com
→
example.com
требуется HTTP-редирект на стороне веб-сервера или приложения.
DNS-запись сама не создаёт редирект.
Корневой домен и www — разные имена
Записи:
example.com
www.example.com
нужно рассматривать отдельно.
Можно настроить:
example.com A 203.0.113.25
www.example.com CNAME example.com
или:
example.com A 203.0.113.25
www.example.com A 203.0.113.25
Если настроено только одно имя, второе может не работать.
Проверка:
dig +short example.com A
dig +short www.example.com A
dig +short www.example.com CNAME
После DNS оба имени также должны быть добавлены в конфигурацию сайта и SSL-сертификат, если планируется их использование.
Поддомен — отдельное DNS-имя
Поддомен:
shop.example.com
не обязан автоматически указывать туда же, куда:
example.com
Для него нужна собственная запись:
shop A 203.0.113.25
или:
shop CNAME example.com
Исключение — wildcard-запись:
* A 203.0.113.25
Она может направлять неизвестные поддомены на один адрес, но не заменяет явные записи во всех сценариях.
Создавать wildcard без необходимости не стоит: опечатка в поддомене тоже начнёт вести на сервер, а диагностика станет менее очевидной.
Почему иногда отображается старый сайт
Если DNS возвращает старый IP, причина обычно одна из трёх:
- авторитетная запись не изменена;
- один из NS-серверов отдаёт старые данные;
- рекурсивный резолвер хранит старый ответ в кэше.
Проверка должна отделять эти ситуации.
Авторитетный ответ против кэшированного
Допустим, новые авторитетные серверы уже возвращают:
203.0.113.25
Но обычный запрос показывает:
192.0.2.10
Сначала узнаём NS:
dig +short NS example.com
Затем спрашиваем напрямую:
dig +short @ns1.hosting.example example.com A
И сравниваем с публичными резолверами:
dig +short @1.1.1.1 example.com A
dig +short @8.8.8.8 example.com A
Возможный результат:
Авторитетный сервер: 203.0.113.25
1.1.1.1: 203.0.113.25
8.8.8.8: 192.0.2.10
Это означает, что зона уже исправлена, но один резолвер пока использует кэшированный ответ.
Google Public DNS прямо отмечает, что после смены DNS-серверов или DNS-провайдера резолвер может возвращать старые, но ещё не просроченные данные.
Что такое TTL
TTL — Time to Live.
Он определяет, как долго резолвер может использовать сохранённый DNS-ответ перед повторным запросом к авторитетному серверу.
Пример:
example.com. 3600 A 203.0.113.25
Значение:
3600 секунд = 1 час
Если резолвер получил старый IP за минуту до изменения записи, он может продолжать использовать его почти ещё час.
TTL не является таймером полного обновления
Распространённое представление:
Мы поставили TTL 3600, значит через час весь интернет переключится.
Точнее сказать:
Каждый кэшированный ответ может храниться до истечения оставшегося TTL.
Разные резолверы запросили запись в разное время.
Поэтому один обновится сразу, другой — через 15 минут, третий — ближе к концу часа.
Новый TTL не действует на уже сохранённый ответ
Допустим, сейчас TTL равен:
86400 секунд
то есть суткам.
Владелец одновременно:
- меняет TTL на 300 секунд;
- меняет IP.
Резолвер, который уже сохранил старую запись с TTL 86400, не узнает о новом TTL до истечения старого ответа.
Поэтому перед плановым переездом TTL снижают заранее — пока старая запись ещё работает.
Как подготовить DNS к переезду
За день или другой разумный срок до переключения:
уменьшить TTL
например, до 300–600 секунд
После того как прежние длинные кэши успели истечь:
изменить A/AAAA/CNAME
После проверки нового сервера:
вернуть обычный TTL
например, 3600 секунд или больше
Слишком короткий TTL постоянно увеличивает число DNS-запросов. Слишком длинный затрудняет быстрые изменения.
Для обычного сайта час часто является понятным компромиссом, но конкретное значение зависит от требований проекта.
Что обычно называют «распространением DNS»
DNS-запись не отправляется одновременно на все устройства интернета.
Обычно происходят два отдельных процесса:
1. Изменение авторитетной зоны
Новый провайдер должен сохранить запись и синхронизировать её между своими авторитетными серверами.
2. Истечение старых кэшей
Рекурсивные резолверы продолжают использовать прежние ответы до истечения TTL.
Поэтому корректнее говорить не «запись распространяется», а:
авторитетные серверы уже обновлены,
а часть резолверов ещё хранит старые ответы
RFC 1034 описывает кэширование как фундаментальную часть DNS и указывает, что нулевой TTL запрещает кэширование, тогда как обычные значения позволяют использовать ранее полученные ответы.
Отрицательное кэширование: домена не было, а потом он появился
Кэшироваться может не только найденный IP.
Представим:
- пользователь открыл
shop.example.com; - записи ещё не существовало;
- резолвер получил ответ
NXDOMAIN; - запись добавили через минуту;
- у пользователя адрес продолжает «не существовать».
Это отрицательное кэширование.
Поэтому после создания нового поддомена часть пользователей некоторое время может продолжать получать ошибку, хотя авторитетный сервер уже отвечает правильно.
Локальный DNS-кэш
Старый ответ может храниться:
- в браузере;
- в операционной системе;
- в роутере;
- в локальном корпоративном DNS;
- у интернет-провайдера;
- в публичном резолвере.
Очистка кэша компьютера не изменит данные у провайдера, но помогает исключить локальный уровень.
Очистка DNS-кэша в Windows
Откройте командную строку от имени пользователя или администратора:
ipconfig /flushdns
Ожидаемый ответ:
Successfully flushed the DNS Resolver Cache.
После этого полностью перезапустите браузер.
Проверить адрес:
nslookup example.com
Проверка DNS в Linux
На системах с systemd-resolved:
resolvectl query example.com
Очистка кэша:
sudo resolvectl flush-caches
Но конкретный способ зависит от используемой службы DNS-кэширования.
Проверить обычный ответ:
getent hosts example.com
И напрямую через dig:
dig example.com
Проверка DNS в macOS
Обычная проверка:
dig example.com
или:
dscacheutil -q host -a name example.com
Команды очистки локального кэша зависят от версии macOS. Часто используется сочетание очистки системного кэша и перезапуска DNS-службы.
Но прежде чем очищать что-либо, полезнее сравнить ответ с авторитетным сервером. Если он сам отдаёт старый IP, локальный кэш ни при чём.
Браузер может использовать собственный защищённый DNS
Современный браузер может отправлять DNS-запросы через DNS over HTTPS к выбранному сервису.
В результате:
nslookupпоказывает один IP;- браузер использует другой;
- изменение системного DNS не влияет на браузер;
- очистка системного кэша не решает проблему.
Для диагностики:
- перезапустите браузер;
- проверьте приватное окно;
- временно отключите защищённый DNS;
- сравните результат в другом браузере;
- используйте
curlс принудительным адресом.
Файл hosts может переопределить DNS
Файл hosts позволяет вручную связать имя с IP-адресом.
В Windows:
C:\Windows\System32\drivers\etc\hosts
В Linux и macOS:
/etc/hosts
Пример:
192.0.2.10 example.com
Пока строка существует, компьютер может игнорировать публичный DNS и открывать указанный сервер.
Это полезно для проверки сайта до переключения DNS, но становится источником путаницы, если запись забыли удалить.
Проверяйте hosts, если:
- проблема существует только на одном компьютере;
- домен всегда открывает старый сервер;
- публичные DNS показывают другой IP;
- ранее сайт тестировали до переезда.
Как проверить новый сервер до изменения DNS
Необязательно сначала переключать домен, а потом узнавать, работает ли сайт.
Есть два удобных способа.
Временная запись в hosts
Добавляем:
203.0.113.25 example.com
203.0.113.25 www.example.com
После этого только данный компьютер будет открывать домен с нового IP.
Можно проверить:
- главную страницу;
- административную панель;
- авторизацию;
- изображения;
- формы;
- базу данных;
- HTTPS, если сертификат уже выпущен;
- редиректы.
После теста строку нужно удалить.
curl --resolve
Без изменения системного файла:
curl \
--resolve example.com:80:203.0.113.25 \
http://example.com/
Для HTTPS:
curl \
--resolve example.com:443:203.0.113.25 \
https://example.com/
Команда подключится к указанному IP, но отправит имя example.com.
Это важно: запрос к одному IP без доменного имени может открыть другой сайт на том же сервере.
Почему нельзя проверять сайт только по IP
На одном IP могут находиться сотни сайтов.
Веб-сервер выбирает нужный проект по имени из HTTP-запроса:
Host: example.com
Если открыть:
http://203.0.113.25/
сервер может показать:
- заглушку;
- первый настроенный сайт;
- техническую страницу;
- ошибку;
- другой домен.
Это не доказывает, что example.com настроен неправильно.
Проверка должна сохранять доменное имя:
curl \
--resolve example.com:80:203.0.113.25 \
http://example.com/
DNS правильный, но открывается чужой сайт
Предположим:
dig +short example.com A
показывает нужный IP.
Но браузер открывает заглушку хостинга или другой проект.
Значит DNS свою задачу выполнил. Проблема находится на веб-сервере.
Возможные причины:
- домен не добавлен в панель;
- домен добавлен в другой аккаунт;
- сайт привязан только к
www; - корневая папка указана неверно;
- сервер не знает имя
example.com; - используется другой виртуальный хост;
- домен добавлен как алиас не того сайта;
- CDN направляет запрос на другой origin;
- настройка ещё не применена на сервере.
Проверить заголовки:
curl -I http://example.com/
Подробное соединение:
curl -v http://example.com/
Принудительная проверка нужного сервера:
curl \
-v \
--resolve example.com:80:203.0.113.25 \
http://example.com/
DNS правильный, но браузер пишет «Соединение отклонено»
Это уже не DNS-проблема.
Имя успешно преобразовалось в IP, но сервер:
- не слушает порт 80;
- блокирует соединение;
- выключен;
- находится за неверно настроенным firewall;
- принимает только HTTPS;
- недоступен по указанному IPv4 или IPv6.
Проверить:
curl -v http://example.com/
или:
curl -v https://example.com/
Если DNS не работает, ошибка будет похожа на:
Could not resolve host
Если адрес найден, но соединение невозможно:
Connection refused
или:
Connection timed out
Это разные уровни диагностики.
Почему старый сайт продолжает открываться после переезда
Даже после переключения DNS старый сервер может получать часть запросов.
Возможные причины:
- старые кэши ещё не истекли;
- осталась AAAA-запись;
- один NS отдаёт старый IP;
- CDN кэширует старую страницу;
- файл
hostsнаправляет на старый сервер; - старый домен используется в редиректе;
- браузер показывает локально закэшированную страницу;
- приложение генерирует ссылки на старый адрес;
- DNS изменили только для
www, но не для корня.
Поэтому старый хостинг не следует отключать сразу после изменения DNS.
Обычно его оставляют работающим на период перехода, чтобы пользователи со старым кэшем не увидели ошибку.
Для динамического сайта при этом возникает другая проблема: заказы и данные могут поступать на два сервера. В статье о переезде разберём, как уменьшить это окно и синхронизировать изменения.
Что такое SOA и зачем его проверять
SOA — служебная запись DNS-зоны.
Она содержит параметры зоны, включая серийный номер, который часто меняется при обновлении конфигурации.
Проверка:
dig example.com SOA
Каждый авторитетный сервер:
dig @ns1.hosting.example example.com SOA
dig @ns2.hosting.example example.com SOA
Если серверы возвращают разные серийные номера и разные записи, синхронизация DNS-провайдера может быть нарушена.
Google Public DNS рекомендует при устойчивых старых ответах проверять SOA и сравнивать serial на авторитетных серверах: разные значения могут указывать на несогласованные данные зоны.
Как проверить всю цепочку через dig +trace
Команда:
dig +trace example.com
показывает последовательность запросов:
корневые серверы
↓
серверы доменной зоны
↓
авторитетные серверы example.com
↓
A/AAAA-ответ
Она полезна, когда:
- NS у регистратора настроены неверно;
- часть делегирования отсутствует;
- авторитетные серверы не отвечают;
- нужно увидеть путь без обычного рекурсивного кэша.
Но +trace не заменяет обычные проверки публичных резолверов: пользователи обращаются через кэш, поэтому их реальный ответ может временно отличаться.
Несуществующий домен и SERVFAIL — не одно и то же
NXDOMAIN
Означает, что запрошенного имени не существует.
Возможные причины:
- запись не создана;
- поддомен написан с ошибкой;
- спрашивается не та зона;
- отрицательный ответ ещё кэшируется.
SERVFAIL
Сервер не смог успешно получить или проверить ответ.
Возможные причины:
- ошибка DNSSEC;
- авторитетные серверы недоступны;
- нарушение делегирования;
- некорректный ответ зоны;
- временный сбой DNS-инфраструктуры.
Пустой ответ
Имя может существовать, но не иметь записи запрошенного типа.
Например:
dig example.com AAAA
не возвращает адрес, хотя A-запись существует.
Поэтому важно смотреть не только текст ошибки браузера, но и конкретный DNS-код ответа.
DNSSEC: когда правильные записи всё равно не работают
DNSSEC добавляет проверку подлинности DNS-ответов.
Если DNSSEC включён у регистратора, а зона переехала к другому провайдеру без обновления криптографических данных, validating-резолверы могут возвращать:
SERVFAIL
При этом:
- авторитетный сервер напрямую показывает правильную A-запись;
- некоторые пользователи видят сайт;
- другие не могут разрешить домен;
- публичные резолверы ведут себя по-разному.
При смене DNS-провайдера нужно либо:
- корректно обновить DNSSEC-параметры;
- либо заранее отключить старую конфигурацию DNSSEC и включить новую после перехода.
Если вы не используете DNSSEC осознанно, не копируйте старые DS-записи наугад.
CDN и проксирование меняют видимый IP
Если домен подключён к CDN или reverse proxy, DNS может возвращать не IP вашего хостинга, а адреса сети посредника.
Это нормально:
пользователь
↓
CDN
↓
сервер хостинга
В таком случае команда:
dig +short example.com A
покажет адрес CDN.
Проверять origin-сервер нужно отдельно:
curl \
--resolve example.com:443:ORIGIN_IP \
https://example.com/
Для записей A, AAAA и CNAME некоторые DNS-провайдеры позволяют включать проксирование, при котором пользователю возвращаются адреса прокси-сети, а не исходного сервера.
Если CDN показывает старую версию сайта, проблема может быть не в DNS, а в кэше CDN.
MX-записи не направляют сайт
MX определяет серверы входящей почты.
Пример:
example.com. MX 10 mail.example.com.
Изменение MX:
- не направляет сайт;
- не меняет A-запись;
- не создаёт почтовый ящик;
- не настраивает отправку писем приложением.
При переезде сайта можно оставить почту у старого провайдера, если MX-записи не менять.
И наоборот: смена NS переносит ответственность за всю DNS-зону. Если в новой зоне забыть MX и TXT-записи, сайт может заработать, а почта — перестать.
Поэтому перед сменой NS нужно перенести не только A-запись, но всю используемую DNS-конфигурацию.
Что нужно скопировать при смене DNS-серверов
Минимально проверьте:
- A;
- AAAA;
- CNAME;
- MX;
- TXT;
- SPF;
- DKIM;
- DMARC;
- записи подтверждения сервисов;
- поддомены;
- SRV;
- CAA;
- wildcard-записи;
- нестандартные API-имена.
Переезд DNS-зоны — не то же самое, что изменение одного IP.
Если новая зона содержит только:
example.com A 203.0.113.25
могут перестать работать:
- почта;
- подтверждение домена;
- сторонние сервисы;
- мессенджеры;
- корпоративные приложения;
- поддомены;
- панели;
- API.
Типовые схемы подключения домена
Схема №1. DNS обслуживает хостинг
У регистратора:
NS → серверы хостинга
В панели хостинга:
A/AAAA/CNAME/MX/TXT
Преимущества:
- всё настраивается в одном месте;
- записи сайта и почты создаются автоматически;
- проще для начинающего пользователя.
Недостатки:
- при смене хостинга приходится переносить всю DNS-зону;
- отключение услуги может повлиять на DNS;
- нужно внимательно копировать почтовые записи.
Схема №2. DNS остаётся у регистратора
У регистратора:
NS → серверы регистратора
Там же:
A → IP хостинга
MX → почтовый провайдер
TXT → SPF/DKIM/DMARC
Преимущества:
- при смене хостинга меняется только A/AAAA;
- DNS не зависит от аккаунта хостинга;
- проще сохранить почту отдельно.
Недостатки:
- настройки находятся в нескольких панелях;
- автоматическое добавление записей хостингом может не работать.
Схема №3. Отдельный DNS/CDN-провайдер
У регистратора:
NS → DNS/CDN-провайдер
У DNS-провайдера:
A/CNAME → хостинг
MX → почтовый сервис
Преимущества:
- расширенное управление;
- проксирование;
- CDN;
- аналитика;
- независимость от хостинга;
- удобные API.
Недостатки:
- ещё один аккаунт и слой инфраструктуры;
- возможна путаница между DNS и CDN-кэшем;
- origin-IP может быть скрыт.
Ни одна схема не является универсально лучшей. Важно понимать, где находится авторитетная зона.
Как это устроено на Siteko. Штатная схема — первая: DNS-серверы хостинга
ns1.siteko.netиns2.siteko.net. Домен, зарегистрированный через Siteko, делегируется на них автоматически при заказе; для домена у стороннего регистратора достаточно указать эти же два сервера в его панели. Записи для сайта и почты создаются в зоне автоматически при добавлении домена в панель хостинга. Схемы №2 и №3 тоже работают: в этом случае в сторонней DNS-панели направьте A-запись на IP сервера хостинга — он виден в панели рядом с доменом.
Пошаговая диагностика: домен не открывает сайт
Шаг 1. Проверяем NS
dig +short NS example.com
Вопрос:
Это DNS-серверы той панели, где изменялись записи?
Если нет — редактировалась неиспользуемая зона.
Шаг 2. Проверяем авторитетные серверы
dig +short @ns1.hosting.example example.com A
dig +short @ns2.hosting.example example.com A
Они должны отвечать одинаково.
Также проверяем IPv6:
dig +short @ns1.hosting.example example.com AAAA
Шаг 3. Проверяем обычные публичные резолверы
dig +short @1.1.1.1 example.com A
dig +short @8.8.8.8 example.com A
Если авторитетный сервер уже новый, а публичный резолвер старый, ждём истечения кэша или используем предоставляемую резолвером функцию очистки. Google Public DNS предоставляет отдельный инструмент сброса кэша и рекомендует при смене DNS-хостинга сначала очищать зарегистрированный домен, а затем поддомены.
Шаг 4. Проверяем A и AAAA отдельно
dig +short example.com A
dig +short example.com AAAA
Если AAAA указывает на старый сервер, исправляем или удаляем её.
Шаг 5. Проверяем www
dig +short www.example.com A
dig +short www.example.com AAAA
dig +short www.example.com CNAME
Корень и www должны быть настроены осознанно.
Шаг 6. Проверяем новый сервер напрямую
curl \
--resolve example.com:80:203.0.113.25 \
http://example.com/
Для HTTPS:
curl \
--resolve example.com:443:203.0.113.25 \
https://example.com/
Если сайт не работает даже при принудительном IP, DNS ни при чём.
Шаг 7. Проверяем обычный запрос
curl -v https://example.com/
Смотрим:
- какой IP выбран;
- установилось ли соединение;
- какой сертификат получен;
- какой HTTP-код вернулся;
- куда ведёт редирект.
Шаг 8. Проверяем локальные переопределения
- файл
hosts; - защищённый DNS браузера;
- VPN;
- корпоративный прокси;
- локальный DNS;
- роутер;
- кэш операционной системы.
Шаг 9. Сравниваем другую сеть
Откройте сайт:
- через мобильный интернет;
- через домашний Wi-Fi;
- через другой публичный DNS;
- с другого устройства.
Если результат различается, вероятны кэш или сетевая особенность.
Быстрый набор команд
DOMAIN="example.com"
echo "=== NS ==="
dig +short NS "$DOMAIN"
echo
echo "=== A ==="
dig +short A "$DOMAIN"
echo
echo "=== AAAA ==="
dig +short AAAA "$DOMAIN"
echo
echo "=== WWW ==="
dig +short A "www.$DOMAIN"
dig +short AAAA "www.$DOMAIN"
dig +short CNAME "www.$DOMAIN"
echo
echo "=== PUBLIC RESOLVERS ==="
dig +short @1.1.1.1 A "$DOMAIN"
dig +short @8.8.8.8 A "$DOMAIN"
echo
echo "=== SOA ==="
dig +short SOA "$DOMAIN"
После получения NS можно запросить каждый напрямую.
Таблица: симптом, причина и проверка
| Симптом | Вероятная причина | Что проверить |
|---|---|---|
| Домен не существует | Нет записи или кэшируется NXDOMAIN | A/AAAA у авторитетного сервера |
| Открывается старый сайт | Старый IP в DNS или кэше | Авторитетный ответ и публичные резолверы |
| Сайт то старый, то новый | NS-серверы отдают разные зоны | Запросить каждый NS напрямую |
Работает без www |
Для www нет записи |
A/AAAA/CNAME для www |
Работает только с www |
Не настроен корневой домен | A/AAAA для @ |
| Работает через мобильную сеть | Домашний резолвер хранит кэш | Сравнить публичные DNS |
| Не работает только на одном ПК | hosts, браузерный или системный кэш |
Локальные настройки |
| На части устройств старый сайт | Старая AAAA-запись | Проверить IPv6 |
| DNS показывает верный IP, но открывается заглушка | Домен не настроен на веб-сервере | Проверить виртуальный хост |
| По IP работает, по домену нет | Сервер не знает доменное имя | Host-конфигурация сайта |
Could not resolve host |
DNS не вернул адрес | NS, A/AAAA и кэш |
Connection refused |
Адрес найден, порт не обслуживается | Веб-сервер и firewall |
SERVFAIL |
Ошибка делегирования или DNSSEC | NS, DS и авторитетные ответы |
| После смены NS пропала почта | Не перенесены MX/TXT | Скопировать всю DNS-зону |
| CDN показывает старую страницу | Кэш посредника | Проверить origin через --resolve |
Что не следует делать
Не меняйте NS и A одновременно без необходимости
Если меняются и DNS-серверы, и адрес сайта, становится сложнее понять, на каком уровне произошла ошибка.
При возможности:
- подготовьте зону у нового DNS-провайдера;
- скопируйте все записи;
- проверьте их;
- смените NS;
- после стабилизации меняйте адрес сайта.
Не добавляйте четыре случайных NS-сервера
Дополнительные серверы полезны только тогда, когда обслуживают одну согласованную зону.
Смешивание провайдеров без синхронизации создаёт случайные ответы.
Не создавайте одновременно A и CNAME для одного имени
Обычный CNAME должен быть единственной записью такого назначения для данного имени; DNS-платформы часто запрещают сочетать его с A или AAAA для того же hostname.
Выберите одну понятную схему.
Не оставляйте старую AAAA-запись
Проверка только A недостаточна.
Не отключайте старый хостинг сразу
Часть пользователей может временно обращаться к старому адресу из кэша.
Не проверяйте сайт только по IP
Сохраняйте доменное имя через hosts или curl --resolve.
Не удаляйте почтовые записи при смене DNS
Сначала экспортируйте или перепишите всю зону.
Не обновляйте страницу сотни раз
Браузер не заставляет авторитетный DNS изменить ответ. Сначала установите, какой уровень возвращает старые данные.
Грабли DNS
| Грабля | Результат | Решение |
|---|---|---|
| Записи изменены не у авторитетного провайдера | Интернет продолжает видеть старую зону | Проверить NS |
| Смешаны DNS-серверы двух компаний | Пользователи получают разные IP | Оставить один согласованный набор |
| Изменена только A-запись | IPv6 ведёт на старый сервер | Проверить AAAA |
| Настроен только корневой домен | www не работает |
Создать запись для www |
| CNAME принимают за редирект | Адрес в браузере не меняется | Настроить HTTP-перенаправление |
| TTL уменьшили одновременно с IP | Старые кэши продолжают жить долго | Снижать TTL заранее |
| Сайт проверяют по IP | Открывается чужой виртуальный хост | Использовать Host или --resolve |
Забыли запись в hosts |
Один компьютер открывает старый сайт | Удалить локальное переопределение |
| При смене NS перенесли только A | Перестаёт работать почта | Перенести MX и TXT |
| Старый сервер выключили сразу | Часть пользователей видит ошибку | Оставить его на переходный период |
| DNSSEC остался от старой зоны | Резолверы возвращают SERVFAIL |
Обновить или отключить DS |
| Путают DNS-кэш и CDN-кэш | Записи верные, страница старая | Проверить origin отдельно |
| Ждут «48 часов», не проверяя зону | Ошибка конфигурации не исправляется | Запросить авторитетные серверы |
| Постоянно меняют записи | Невозможно понять текущую схему | Зафиксировать конфигурацию и проверять по шагам |
Что приложить к обращению в поддержку
Плохое обращение:
Домен не работает. Проверьте.
Полезное:
Домен: example.com
Ожидаемый IP:
203.0.113.25
Текущие NS:
ns1.hosting.example
ns2.hosting.example
Авторитетные ответы:
ns1 → 203.0.113.25
ns2 → 203.0.113.25
Публичные резолверы:
1.1.1.1 → 203.0.113.25
8.8.8.8 → 192.0.2.10
AAAA-записи нет.
Через:
curl --resolve example.com:443:203.0.113.25
сайт открывается правильно.
Через обычный браузер в моей сети открывается старый сайт.
По этому описанию уже понятно:
- DNS-зона настроена правильно;
- новый сервер работает;
- один резолвер хранит старый кэш;
- менять файлы сайта или Document Root не требуется.
Минимальный чек-лист подключения домена
Делегирование
Какие NS указаны у регистратора?
Совпадают ли они с используемой DNS-панелью?
Все ли NS отвечают одинаково?
Адреса
Какой A-адрес у корневого домена?
Есть ли AAAA?
Куда указывает www?
Есть ли нужные поддомены?
Кэш
Какой TTL?
Что возвращает авторитетный сервер?
Что возвращают публичные резолверы?
Есть ли локальный hosts?
Веб-сервер
Добавлен ли домен в панель хостинга?
Правильная ли корневая папка?
Работает ли сайт через curl --resolve?
Настроены ли оба имени: с www и без?
Связанные сервисы
Перенесены ли MX?
Сохранены ли SPF, DKIM и DMARC?
Есть ли записи подтверждения сервисов?
Не сломан ли DNSSEC?
Что в итоге
Когда домен не открывает сайт, не нужно начинать с бесконечного ожидания «распространения DNS».
Проверьте четыре уровня:
1. Делегирование
Какие NS отвечают за домен?
2. Записи
Какой A, AAAA или CNAME они возвращают?
3. Кэш
Не хранит ли резолвер старый ответ?
4. Веб-сервер
Принимает ли выбранный IP запросы для этого домена?
Если авторитетные DNS-серверы возвращают старый IP, исправляйте зону.
Если авторитетные серверы новые, а публичный резолвер старый, проблема в кэше.
Если DNS везде правильный, но показывается заглушка, проверяйте настройки сайта на сервере.
Если curl --resolve открывает сайт правильно, новый сервер уже готов, даже если часть пользователей временно видит старый адрес.
Главный принцип:
DNS-ошибка перестаёт быть мистикой, когда вы отдельно проверяете источник записи, полученный адрес, кэш и веб-сервер.
После того как домен начинает вести на правильный сервер, браузер устанавливает HTTPS-соединение.
И здесь появляется следующая группа вопросов: сертификат выпущен, но браузер всё равно предупреждает об опасности; www не входит в сертификат; страница загружает изображения по HTTP; после переезда возникает бесконечный редирект.
В следующей части разберём SSL и HTTPS без паники.
Была статья полезной:
