DNS на практике: как проверить A, CNAME, MX, NS, TXT и TTL через nslookup

Нужно узнать, куда направлен домен, почему не открывается поддомен, где обслуживается почта или появилась ли TXT-запись для подтверждения сайта? Для первой проверки часто достаточно одной команды — nslookup.

Эта инструкция рассчитана на начинающих администраторов, маркетологов и SEO-специалистов. В каждом разделе есть конкретный вопрос, команда и объяснение результата. Мы будем проверять отдельные записи и отличать проблему DNS от ошибки сайта или почтового сервиса.

Основные примеры показаны для Windows. В Linux и macOS синтаксис распространённых запросов похож, но формат вывода и доступность утилиты могут отличаться.

1. Как запустить nslookup и правильно указать домен

Откройте командную строку или PowerShell в Windows. Для обычных запросов права администратора не нужны.

nslookup example.com.

Вместо example.com укажите нужный домен. Запрашивайте имя, а не адрес страницы: example.com, а не https://example.com/catalog/.

Точка в конце обозначает полное доменное имя и помогает исключить добавление локального DNS-суффикса. Она особенно полезна при диагностике из корпоративной сети.

Чтобы задать тип записи и конкретный сервер:

nslookup -type=A example.com. 1.1.1.1

Здесь A — тип записи, example.com. — проверяемое имя, 1.1.1.1 — DNS-сервер, которому отправляется запрос. Указание сервера действует для этой команды и не меняет настройки компьютера.

Важно о примерах. Домены example.com, example.net и example.org зарезервированы для документации, но могут иметь реальные DNS-ответы. Их записи способны меняться. Все фрагменты ответа ниже с адресами 192.0.2.x, именами ns1/mail и тестовыми TXT-значениями — учебные, а не текущие настройки этих доменов. Заменяйте имя в команде и читайте свой ответ.

Источник: Microsoft — nslookup.

2. Как прочитать ответ и не перепутать два IP-адреса

Учебный пример:

Server:  resolver.example.net
Address: 192.0.2.53

Non-authoritative answer:
Name:    example.com
Address: 192.0.2.10

Верхняя часть отвечает на вопрос «кто ответил на запрос?». Адрес 192.0.2.53 принадлежит DNS-серверу, а не сайту.

Нижняя часть содержит результат: имя example.com связано с адресом 192.0.2.10. Если строка называется Addresses и адресов несколько, не выбирайте один из них как «единственно правильный» без понимания схемы сервиса.

Non-authoritative answer означает, что ответ не помечен как авторитетный ответ сервера этой зоны. Это обычный результат работы рекурсивного резолвера, который может использовать кэш; само сообщение не означает ошибку.

Если вместо имени сервера написано UnKnown, у его IP может отсутствовать подходящая обратная запись. Если ниже есть корректный ответ, DNS-запрос всё равно мог выполниться успешно.

Что записать при диагностике: проверяемое имя, тип записи, сервер запроса, результат и время. Без этих данных сравнение двух скриншотов может вводить в заблуждение.

3. Как узнать IPv4 и IPv6 сайта: A и AAAA

A связывает имя с IPv4-адресом. AAAA — с IPv6-адресом. Проверяйте их раздельно:

nslookup -type=A example.com. 1.1.1.1
nslookup -type=AAAA example.com. 1.1.1.1

Как понять результат. Один или несколько IPv4 в ответе на A — адреса, которые DNS возвращает для этого имени. Отсутствие AAAA не обязательно является неисправностью: сервис может работать только по IPv4.

Если используется CDN, reverse proxy или балансировщик, вы можете увидеть адрес посредника, а не сервера, где лежат файлы сайта. По DNS-адресу нельзя надёжно установить физический хостинг или владельца сайта.

Прикладной пример. После переноса сайта A уже указывает на новый сервер, но старая AAAA осталась. Часть клиентов использует IPv6 и попадает в другое место. Поэтому при переносе нужно проверять оба типа.

DNS-ответ также не подтверждает, что сайт работает: после него ещё нужны сетевое соединение, TLS и корректный HTTP-ответ.

Основа: Cloudflare — типы DNS-записей.

4. Как узнать DNS-сервер компьютера и NS-серверы домена

Это два разных вопроса.

DNS-сервер компьютера принимает ваши запросы и помогает разрешать имена. Он показан в верхней части ответа nslookup. Настройки сетевых интерфейсов Windows можно посмотреть так:

ipconfig /all

Найдите DNS Servers у нужного адаптера. При VPN, нескольких адаптерах и корпоративных политиках схема выбора сервера может быть сложнее одной строки.

NS-серверы домена — серверы имён, указанные в DNS для зоны:

nslookup -type=NS example.com. 1.1.1.1

Учебный результат:

example.com nameserver = ns1.example.net
example.com nameserver = ns2.example.net

Это имена серверов, а не IP сайта и не адреса почтового сервиса. При необходимости получите их адреса запросами A и AAAA.

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

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

Источники: Microsoft — ipconfig, Cloudflare — NS.

5. Как проверить запись непосредственно у авторитетного сервера

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

Сначала получите NS:

nslookup -type=NS example.com. 1.1.1.1

Затем подставьте имя реально полученного NS-сервера во второй аргумент запроса. Шаблон ниже использует условное имя, которое нужно заменить:

nslookup -type=A example.com. ns1.example.net
nslookup -type=TXT example.com. ns1.example.net

Если нужно исключить дополнительное разрешение имени NS, сначала узнайте его IP и используйте этот IP вместо имени сервера.

Когда это полезно. В панели вы изменили A-запись. У авторитетного сервера уже новый адрес, а у одного резолвера ещё старый. Вероятная причина — кэш. Если старый адрес возвращают сами серверы зоны, проверяйте правильность зоны, сохранение изменений и согласованность NS.

Проверьте несколько серверов из списка NS. Их ответы для одной зоны и одной записи должны соответствовать согласованной конфигурации.

Одного запроса NS недостаточно для полной диагностики делегирования: при расхождениях между родительской и дочерней зоной может понадобиться отдельная проверка цепочки делегирования. Для базовой проверки записи начинайте с указанной последовательности.

6. Как узнать почтовые серверы: MX

MX задаёт серверы, на которые отправляющие системы должны доставлять почту для домена.

nslookup -type=MX example.com. 1.1.1.1

Учебный ответ:

example.com MX preference = 10, mail exchanger = mail1.example.net
example.com MX preference = 20, mail exchanger = mail2.example.net

Чем меньше число, тем выше предпочтение. В примере сначала предпочитается mail1 с числом 10. Запись с числом 20 имеет более низкое предпочтение; как именно её используют при сбоях, зависит также от поведения отправляющей почтовой системы.

Числа не являются процентами нагрузки. MX 10 и MX 20 не означают распределение 10/20 или «первый сервер в два раза быстрее». При одинаковом предпочтении серверы рассматриваются как равноценные кандидаты, но это не гарантия строгого равномерного распределения.

MX содержит имя сервера, не его IP. Для проверки адреса отдельно запросите A и AAAA этого имени. Цель MX не должна быть CNAME.

Важное исключение. MX с предпочтением 0 и именем «.» — Null MX: домен явно сообщает, что не принимает почту. Windows может показать такую цель как (root). Это не обычный почтовый сервер и не просто «главный MX с приоритетом ноль».

Пустой ответ MX не следует автоматически переводить как «почта точно невозможна»: протокол SMTP предусматривает поведение при отсутствии MX. Настройки реального почтового сервиса проверяйте по его инструкции.

MX не сообщает, где расположен веб-сайт, и не задаёт сам по себе SMTP-сервер для отправки писем из приложения.

Источники: Cloudflare — MX, RFC 7505 — Null MX, RFC 5321 — SMTP.

7. Как проверить CNAME и понять, куда ведёт псевдоним

CNAME связывает одно DNS-имя с другим:

nslookup -type=CNAME www.example.com. 1.1.1.1

Учебный ответ:

www.example.com canonical name = example.com

Затем проверьте A и AAAA конечного имени. Если в цепочке несколько псевдонимов, проследите её до имени с адресными записями.

Для маркетолога. Платформа рассылок может попросить создать CNAME для tracking.example.com. Значение берите из кабинета конкретного сервиса, не копируйте из чужого примера. Проверяйте именно полное имя tracking.example.com, а не только example.com.

Для SEO-специалиста. CNAME не является HTTP-редиректом, не меняет адрес в браузере и не создаёт rel=canonical. Доступность домена в DNS, сертификат HTTPS, перенаправление www → без www и SEO-каноникал — разные настройки.

Обычный CNAME не должен сосуществовать с другими обычными данными на том же имени. В корне зоны этому мешают обязательные SOA/NS; функции ALIAS/ANAME и CNAME flattening провайдера работают иначе. Поэтому отсутствие видимого CNAME не всегда доказывает отсутствие настройки псевдонима в панели.

Источники: Cloudflare — CNAME, CNAME flattening.

8. Как прочитать TXT и проверить подтверждение домена

TXT хранит текстовые значения. Их используют для подтверждения владения доменом и разных настроек сервисов.

nslookup -type=TXT example.com. 1.1.1.1

Учебный ответ:

example.com text =
    "service-verification=example-token"

Сравнивайте значение с тем, которое выдал сервис. Не ориентируйтесь только на наличие «какой-нибудь TXT».

TXT может находиться не в корне домена, а на отдельном имени. Если сервис просит имя verify.example.com, запрос example.com не проверяет нужную запись:

nslookup -type=TXT verify.example.com. 1.1.1.1

Частая ошибка в панели. Поле «имя» может ожидать только verify, а провайдер сам добавляет домен. Если в такое поле внести полное имя без учёта интерфейса, можно случайно создать verify.example.com.example.com. Проверяйте итоговое полное имя.

Одна TXT-запись может содержать несколько текстовых фрагментов в кавычках. При интерпретации конкретного протокола они могут соединяться. Несколько отдельных TXT-записей — другая ситуация: не склеивайте все значения подряд.

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

Основа: Cloudflare — TXT.

9. Как проверить SPF, DKIM и DMARC

Все три механизма связаны с почтой, но решают разные задачи и проверяются по разным именам.

SPF — политика допустимых источников отправки для проверяемого домена:

nslookup -type=TXT example.com. 1.1.1.1

Найдите значение, начинающееся с v=spf1. Не создавайте несколько отдельных SPF-политик для одного имени: объединяйте разрешённые источники по инструкции почтового сервиса. Наличие SPF не гарантирует доставку в папку «Входящие».

DKIM — проверка подписи письма. Для запроса нужно знать selector: его выдаёт почтовый сервис; также он указан в параметре s= заголовка DKIM-Signature подписанного письма.

nslookup -type=TXT selector1._domainkey.example.com. 1.1.1.1
nslookup -type=CNAME selector1._domainkey.example.com. 1.1.1.1

selector1 — учебное значение: замените его реальным. Некоторые сервисы предлагают CNAME вместо прямой TXT. Случайный selector не проверяет настройки вашего DKIM.

DMARC — политика для проверки согласованности домена в видимом From с результатами SPF/DKIM:

nslookup -type=TXT _dmarc.example.com. 1.1.1.1

Учебное значение v=DMARC1; p=none означает режим политики без требования карантина или отклонения со стороны этой записи. Параметры quarantine/reject имеют другой смысл. Не ужесточайте политику без проверки всех законных источников почты.

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

Источники: RFC 7208 — SPF, RFC 6376 — DKIM, RFC 7489 — DMARC.

10. Как узнать TTL записи и понять кэширование

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

Для подробного ответа в Windows используйте debug:

nslookup -debug -type=A example.com. 1.1.1.1

В блоке ответа найдите нужное имя, тип A и строку ttl. Учебный фрагмент:

ANSWERS:
    example.com
        type = A
        ttl = 300 (5 mins)
        internet address = 192.0.2.10

300 секунд — 5 минут, 3600 — час, 86400 — сутки.

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

При переносе сайта. Снижайте TTL заранее, до изменения адреса, и дайте истечь ранее закэшированному старому TTL. Если старый ответ уже сохранён на сутки, изменение TTL в панели до 300 не отменяет тот кэш немедленно.

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

Источники: Microsoft — debug, Cloudflare — TTL.

11. Как проверить известный поддомен

У каждого полного имени может быть собственный набор записей. example.com и shop.example.com не обязаны вести на один адрес.

nslookup -type=A shop.example.com. 1.1.1.1
nslookup -type=AAAA shop.example.com. 1.1.1.1
nslookup -type=CNAME shop.example.com. 1.1.1.1

Проверяйте типы, которые соответствуют ожидаемой настройке. Например, поддомен лендинга может быть CNAME, а сайт в корне — A.

Если DNS-ответ получен, но страница не открывается, переходите к HTTPS и настройкам веб-сервера. Веб-сервер должен знать это имя, а сертификат — покрывать его. Правильная A-запись не создаёт сайт или сертификат автоматически.

Wildcard-запись вида *.example.com может давать ответы для некоторых не заданных явно имён. Поэтому успешный запрос случайного имени не всегда означает, что для него существует отдельная запись или работающий сайт.

12. Как узнать все поддомены — и почему nslookup не выдаёт их список

У nslookup нет универсальной команды «показать все поддомены». DNS обычно отвечает на запрос об известном имени и типе, а не перечисляет весь набор имён организации.

Если домен ваш: откройте панель действующего DNS-провайдера или экспорт зоны. Затем сопоставьте записи с настройками сайтов, SaaS-платформ, каталогом сервисов и данными владельцев систем. При делегировании поддомена в другую зону нужно проверить и её панель.

Если у вас нет доступа к панели: журналы Certificate Transparency и поисковые данные могут помочь найти часть публичных имён. Но они не дают полный текущий список: имена бывают устаревшими, внутренними, без публичных сертификатов или прикрытыми wildcard-сертификатом.

Полученное имя проверяйте отдельным DNS-запросом. Не делайте вывод «поддоменов нет» на основании одного источника.

Запрос ANY тоже не решает задачу: он относится к конкретному имени, не перечисляет поддомены и может возвращать ограниченный набор данных. Для A, MX, NS и TXT задавайте отдельные типы.

Основа: RFC 8482 — ограниченные ответы на ANY, Google — Certificate Transparency.

13. Как узнать имя по IP: PTR

Для обратного запроса:

nslookup 192.0.2.10 1.1.1.1

192.0.2.10 — адрес для документации. В рабочей проверке подставьте реальный IP.

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

Что важно. Один PTR не перечисляет все сайты на IP. На одном адресе могут обслуживаться сотни доменов, а PTR может указывать на техническое имя провайдера. Отсутствие PTR не доказывает, что веб-сайт не работает.

Для почтового сервера обратная запись может влиять на проверки принимающих систем. Её наличие и согласованность с другими настройками нужно проверять отдельно.

Основа: Cloudflare — PTR.

14. Как сравнить ответы разных DNS-серверов

nslookup -type=A example.com. 1.1.1.1
nslookup -type=A example.com. 8.8.8.8
nslookup -type=A example.com.

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

Как понять различия. После изменения записи ответы могут отличаться из-за кэша. Но это не единственная причина: возможны разные публичные и внутренние зоны, географическая маршрутизация, CDN и фильтрация. Для сравнения опирайтесь на ожидаемую конфигурацию.

Если внутреннее имя работает в офисе, но отсутствует у публичного резолвера, это может быть нормальный split DNS. Не отправляйте внутренние имена во внешние сервисы без необходимости.

Для передачи проблемы администратору: сохраните имя, тип, сервер запроса, ответ и время; добавьте информацию о сети/VPN. Фраза «DNS не обновился» без этих деталей не определяет причину.

15. Как отличить NXDOMAIN, отсутствие записи и тайм-аут

NXDOMAIN / Non-existent domain. Сервер сообщает, что запрашиваемого имени не существует в его представлении DNS. Проверьте опечатку, полное имя и правильный сервер. Нельзя по одному такому ответу утверждать, что домен не зарегистрирован.

No answer / отсутствие нужного типа. Имя может существовать, но не иметь запрошенной записи. Например, A есть, а AAAA нет. Формулировка зависит от утилиты; при сомнениях используйте debug и сравните запрос другого типа.

DNS request timed out. За время ожидания не получен нужный ответ. Причина может быть в доступности DNS-сервера, сетевых ограничениях или задержке. Это не доказательство отсутствия имени.

SERVFAIL. Сервер не смог завершить разрешение. Возможные причины включают сбой серверов зоны, ошибки делегирования или проверки DNSSEC. Повторяющийся SERVFAIL требует диагностики; не «исправляйте» его вслепую удалением защитных настроек.

REFUSED. Сервер отказался выполнять запрос по своей политике. Например, авторитетный сервер может не обслуживать рекурсивные запросы к чужим зонам.

Отсутствие имени или данных тоже может кэшироваться. После создания ранее отсутствовавшей записи учитывайте отрицательный кэш, а не только TTL новой записи.

Источники: Microsoft — ошибки nslookup, RFC 2308 — отрицательное кэширование.

16. Как проверить DNS после изменений: короткий порядок действий

Если переносите сайт:

• заранее учтите TTL старых записей;
• проверьте A и AAAA у авторитетных серверов;
• сравните ответы используемого и публичного резолверов;
• отдельно проверьте www и другие используемые поддомены;
• затем проверьте HTTPS, работу сайта и нужные HTTP-перенаправления.

Если подключаете почту:

• проверьте MX, предпочтения и адреса целевых серверов;
• проверьте SPF на нужном домене;
• запросите DKIM по реальному selector;
• проверьте _dmarc;
• отправьте тестовое письмо и изучите результаты аутентификации.

Если подтверждаете домен в сервисе:

• перепроверьте точное имя TXT или CNAME и значение из кабинета;
• исключите случайное удвоение доменного суффикса;
• запросите запись у авторитетного сервера;
• проверьте видимость через резолвер;
• повторите проверку в кабинете сервиса.

Наличие записи — только один этап. Кабинет сервиса может проводить собственную проверку с задержкой или ожидать другой тип/имя.

17. Как пользоваться интерактивным режимом и очисткой кэша

Если запросов много, откройте интерактивный nslookup:

nslookup
server 1.1.1.1
set type=MX
example.com.
set type=TXT
example.com.
set debug
example.com.
set nodebug
exit

Внутри этого режима команды вводятся по одной строке. Строки server и set — команды nslookup, а не самостоятельные команды PowerShell. Тип запроса сохраняется, пока вы его не поменяете.

Для просмотра DNS-кэша Windows:

ipconfig /displaydns

При обоснованной необходимости очистки:

ipconfig /flushdns

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

nslookup обращается к DNS-серверу; его результат не следует автоматически считать тем же путём разрешения имени, который использует браузер. На приложение могут влиять hosts, собственный кэш и DNS over HTTPS. Поэтому ситуация «nslookup показывает одно, браузер другое» требует проверки настроек приложения, а не только повторной очистки кэша.

Источник: Microsoft — диагностика DNS-клиента.

18. Как быстро выбрать нужную команду

Скопируйте нужную строку и замените домен. Все запросы ниже направлены одному публичному резолверу:

nslookup -type=A example.com. 1.1.1.1
nslookup -type=AAAA example.com. 1.1.1.1
nslookup -type=CNAME www.example.com. 1.1.1.1
nslookup -type=NS example.com. 1.1.1.1
nslookup -type=MX example.com. 1.1.1.1
nslookup -type=TXT example.com. 1.1.1.1
nslookup -type=TXT _dmarc.example.com. 1.1.1.1
nslookup -debug -type=A example.com. 1.1.1.1

A/AAAA — адреса; CNAME — псевдоним; NS — серверы зоны; MX — доставка почты; TXT — текстовые настройки; debug помогает увидеть подробности, включая TTL.

Для DKIM добавьте реальный selector и учитывайте возможный CNAME. Для проверки поддомена указывайте его полное имя. Чтобы увидеть конфигурацию без влияния кэша рекурсивного резолвера, повторите нужный запрос к авторитетному серверу.

Что запомнить начинающему администратору и SEO-специалисту

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

Верхний IP в nslookup — адрес отвечающего DNS-сервера. MX выбирается по меньшему значению предпочтения. CNAME не является редиректом. TTL не означает «запись гарантированно изменится у всех через это время». По DNS нельзя получить универсальный полный список поддоменов или доказать работоспособность сайта.

Учебные фрагменты ответов показывают, как читать поля, и не описывают текущую конфигурацию example.com. Источники проверены 9 октября 2026 года.

Если после проверки DNS проблема остаётся, пригодятся наши материалы о CLI-командах сетевого оборудования и правилах информационной безопасности компании.

Нужна помощь с переносом сайта, DNS или подключением почты? Свяжитесь с АВАНГАРД ИТ.