Как проверить DNS-записи домена: A, MX, TXT по шагам

Переехали на новый хостинг в пятницу: файлы на месте, панель "зелёная", а у клиентов сайт то открывается, то нет, а письма с заказами пропали. Часто виноват не Битрикс и не "упавший" сервер, а DNS – телефонная книга домена. За 5–10 минут вы проверите A, MX, TXT и NS через dig online или CLI, сверите IP и почту с панелью хостинга и поймёте: ждать TTL или чинить запись.

DNS – это не "магия 48 часов", а записи с TTL (сроком кеша). Сайт смотрит на A/AAAA, почта – на MX и TXT/SPF, а NS говорят, кто вообще отдаёт зону. После переезда сначала сверьте A с новым IP, затем MX (hostname, не IP), потом SPF. Если на публичных резолверах всё верно – ищите причину не в DNS.

Речь про сайты на своём хостинге и CMS "1С-Битрикс: Управление сайтом". Это не Bitrix24 CRM – там другая модель доступа к имени.

Разовая проверка "сайт открывается?" – в гайде как проверить работоспособность сайта. Срок оплаты имени – отдельно: как проверить срок регистрации домена. Здесь только DNS-записи.

Разберите, какие записи критичны для сайта и почты

На пальцах DNS – записная книжка: браузер спрашивает "куда вести example.ru?", почтовый сервер – "куда слать письма". Вам нужны не все типы из энциклопедии, а четыре рабочих слоя.

CNAME обычно вешает www на основной домен (или наоборот). A и CNAME на одном имени вместе не живут – если "склеили" оба, получите сюрприз.

Сделайте: выпишите целевой IP, MX-хост и SPF из панели хостинга до правки DNS. Не делайте: чинить только A и забывать почту – сайт может "жить", а заказы уйдут в никуда.

Проверьте DNS online dig за минуту

Терминал не обязателен. Online dig (dns dig online) – та же идея, что утилита dig на сервере: спросить DNS и показать ответ. Удобные точки входа: DNS dig на bx-monitor.ru, reg.ru dig, Google Admin Toolbox Dig.

1. Откройте online dig и введите домен без https:// – только example.ru.
2. Запросите тип A: в ответе должен быть IP нового сервера, не старого.
3. Запросите MX: смотрите hostname и приоритет (меньшее число – выше приоритет).
4. Запросите TXT: найдите строку SPF (v=spf1 ...) и сверьте ip4/include.
5. Запросите NS: список должен совпасть с NS у регистратора.
6. Запишите TTL из ответа – это сколько секунд резолверы могут держать старое значение.
7. Повторите A у другого публичного резолвера (например Google 8.8.8.8), если сервис умеет выбирать сервер.

Схема чтения:
Домен → A (IP сайта) → MX (почта) → TXT/SPF → NS (кто зона) → TTL (сколько ждать кеш)

Локальный браузер врёт чаще, чем кажется: у вас уже новый IP, у бухгалтера в другом городе – старый кеш провайдера. Online dig и запрос к 8.8.8.8 показывают "мир снаружи", а не только ваш ноутбук.

Сделайте: прогоните четыре типа подряд и сравните с панелью. Не делайте: судить только по "у меня открывается" после Ctrl+F5.

Проверьте DNS через CLI, если нужен точный снимок

Когда online-формы мало или нужен скрипт, хватает nslookup (Windows) или dig (Linux/macOS). dig по умолчанию запрашивает A – это нормально.

nslookup -type=A example.ru
nslookup -type=MX example.ru
dig example.ru A +short
dig example.ru MX +short
dig @8.8.8.8 example.ru A
dig @ns1.provider.ru example.ru A

После смены DNS: dig NS → dig A @ваш-ns → dig A @8.8.8.8. Если у NS уже новый IP, а у 8.8.8.8 ещё старый – вы в окне TTL, не в "сломанном Битрикс".

Сделайте: сохраните вывод dig в день переезда. Не делайте: править зону без снимка до/после.

Исправьте типичные ошибки после переезда хостинга

Классика: новый VPS готов, CMS поднята, а клиенты всё ещё попадают на старый сервер. Хостинг "живой", домен смотрит не туда. Если выбираете, куда переезжать, ориентируйтесь на проверенный shared/VPS вроде Beget – но DNS всё равно сверяйте сами.

1. Сверьте A с IP из панели нового хостинга – один символ в IP ломает всё.
2. Проверьте www: отдельная A или CNAME на корень – иначе "голый" домен новый, www старый.
3. Проверьте MX: часто остаётся mail.старый-хостинг.ru, пока сайт уже на новом IP.
4. Обновите SPF: уберите ip4 старого сервера, добавьте новый или include почтового сервиса.
5. Убедитесь, что правите зону там, куда указывают актуальные NS – не "старую" панель регистратора, если делегирование уже уехало.
6. Снизьте TTL заранее (за сутки до cutover), если планируете смену A – окно ожидания станет короче.

MX никогда не должен быть "голым" IP в значении записи – только имя почтового хоста. После правки MX на практике часто ждут 1–2 часа, но ориентир всё равно TTL в ответе dig.

Сделайте: чек-лист A → www → MX → SPF в одном сообщении команде. Не делайте: считать "сайт открылся у меня" доказательством, что почта тоже переехала.

Пройдите чек-лист после смены NS

Смена NS (nameserver) – это смена "адресата" зоны у реестра. Это не то же самое, что правка одной A-записи. Окно 24–48 часов типично именно для делегирования на стороне TLD/реестра. Его нельзя "ускорить", просто снизив TTL внутри старой зоны.

1. В кабинете регистратора выпишите новые NS, которые задали.
2. Через dig/online запросите NS домена – список должен совпасть.
3. Только после этого правьте A/MX/TXT в панели тех NS, куда делегировали.
4. Опросите авторитетный NS: dig @ns1... example.ru A – там уже новая картина?
5. Опросите 8.8.8.8 / 1.1.1.1 – если расходится, ждите истечения кешей, не крутите CMS.
6. Проверьте почту отдельно (MX/TXT), даже если сайт уже "поехал".

Вердикт по времени: смена A при TTL 300 часто видна за 5–15 минут. Смена NS – до суток-двух на стороне реестра. Фраза "подождите 72 часа на любую правку" – грубый миф; смотрите тип изменения и TTL.

"Propagation" – не рассылка обновлений кнопкой, а истечение кешей резолверов. Пока TTL (или negative cache NXDOMAIN) не выгорел, кто-то видит старое.

Сделайте: сначала совпадение NS, потом правки записей. Не делайте: править A у старого DNS-провайдера после смены делегирования.

Отличите DNS от "сайт упал" и срока домена

Владелец Битрикс-сайта часто чинит агенты, кеш или SSL, а домен всё ещё указывает на старый IP. Правило отсечения:

• A/MX/NS на публичных резолверах неверны → чините DNS, не админку CMS;
• записи верны, а HTTP/SSL/таймаут – идите в чек-лист доступности (работоспособность сайта);
• домен не резолвится и WHOIS показывает истечение – сначала срок имени (срок регистрации домена);
• нужны регулярные алерты, а не ручной dig по пятницам – смотрите мониторинг сайта на Битрикс.

Быстрый повторный снимок DNS – через инструмент dig на bx-monitor.ru. Для почтового маршрута отдельно удобна проверка MX. Если хотите держать контроль постоянно, зайдите в demo BX Pulse – ручной dig не заменит привычку смотреть изменения.

Сделайте: за 2 минуты отсеките DNS от HTTP/SSL/срока домена. Не делайте: перезапускать Битрикс, пока A смотрит не туда.

Что дальше: закрепите результат проверки

1. Сохраните снимок: A, MX, TXT/SPF, NS, TTL и дату проверки.
2. Сверьте каждое значение с панелью хостинга и регистратора.
3. Если расхождение есть – правьте зону на актуальных NS и снова dig.
4. Если записи верны – переходите к HTTP/SSL/хостингу, не крутите DNS по кругу.
5. Перед следующим переездом снизьте TTL заранее и повторите этот чек-лист в день cutover.

Итог: вы получите понятный снимок DNS и критерий успеха – A на новый IP, MX на нужный хост, SPF без старого сервера, NS совпадают с регистратором. Дальше либо ждёте TTL осознанно, либо чините запись, либо переходите из DNS к диагностике сайта.

Материал проверен. Автор: Максим Мольков, основатель BX Pulse, разработчик 1С-Битрикс.
Источники: online dig Рег.ру (reg.ru/nettools/dig), Google Admin Toolbox Dig (toolbox.googleapps.com), man dig / ISC BIND, база знаний Рег.ру по MX (help.reg.ru), практика диагностики после смены DNS (FoxCloud KB), материалы по TTL и кешу DNS (thatmy.com, Cloudflare DNS troubleshooting).