Если сайт открывается у одного сотрудника и не открывается у другого, запрос «какой IP у домена» слишком узок. Нужно понять, какой резолвер отвечает, из какой сети, для какого имени и с каким результатом. Эта статья — практический диагностический маршрут для Windows и Linux. Типы записей подробнее разобраны в основной статье о DNS и nslookup; здесь сосредоточимся на неисправностях.
1. Зафиксируйте имя, сеть и выбранный DNS
Зачем появился DNS и что проверяет nslookup
DNS заменил необходимость распространять единый список адресов между компьютерами распределённой системой имён. Её классическая архитектура описана в RFC 1034/1035 1987 года: зоны обслуживаются ответственными серверами, а резолверы получают данные и кешируют ответы. Сегодня поверх этой основы работают дополнительные типы записей, DNSSEC и разные транспорты. Nslookup остаётся простым инструментом прямого запроса DNS-сервера; в Windows он встроен, в Linux обычно входит в пакет инструментов BIND.
Пользователь вводит имя и тип, утилита отправляет запрос выбранному серверу, получает DNS-сообщение и показывает его содержимое. Она не проверяет работу HTTP, сертификат, доступность почтового сервера и полный путь приложения через системный резолвер. Именно поэтому «nslookup отвечает» и «сайт открывается» — разные результаты. Базовое описание пространства имён и делегирования — RFC 1034.
Подготовьте инструменты и воспроизводимый пример
На Debian/Ubuntu: sudo apt-get update, затем sudo apt-get install bind9-dnsutils. Проверьте command -v nslookup и nslookup -version. В Windows откройте PowerShell и выполните Get-Command nslookup.exe. Если корпоративная политика запрещает публичные резолверы, не обходите её: в примерах вместо 1.1.1.1 укажите разрешённый DNS.
Дальше используются зарезервированные example.com и учебные IP 192.0.2.10/2001:db8::10. Фрагменты вывода — иллюстрации формата, а не текущие записи этих доменов. Для воспроизведения конкретных значений нужна собственная лабораторная зона. Для диагностики реального домена подставляйте его имя и сохраняйте фактический ответ, время и сервер.
Get-Date -Format o
Get-DnsClientServerAddress -AddressFamily IPv4
nslookup.exe -type=A example.com. 1.1.1.1Точка после имени означает полностью квалифицированное имя и исключает присоединение локального search suffix. Второй позиционный аргумент — сервер запроса. Без него утилита выбирает DNS из своей конфигурации; это не обязательно тот сервер, который использует конкретное приложение через VPN/DoH.
Как читать первые строки ответа
Server: resolver.example.net
Address: 192.0.2.53
Non-authoritative answer:
Name: example.com
Address: 192.0.2.10Server/Address наверху обозначают отвечающий DNS-сервер, а нижний Address — результат для искомого имени. Их часто путают. Non-authoritative answer сообщает о неавторитетном ответе, обычно от рекурсивного резолвера; это не признак ошибки. Server: Unknown может означать отсутствие обратной PTR-записи для самого DNS-сервера при полностью исправных запросах.
Запишите точное полное имя, время ошибки, интерфейс, VPN-профиль и адрес DNS. Для внутренних имён не используйте публичный резолвер: он не обязан знать приватную зону, а запрос раскрывает её имя внешнему сервису. Публичный домен и корпоративный split DNS проверяются раздельно.
Get-DnsClientServerAddress | Select-Object InterfaceAlias,AddressFamily,ServerAddresses
Get-DnsClient | Select-Object InterfaceAlias,ConnectionSpecificSuffix
Get-NetIPConfiguration
nslookup app.corp.example. 10.77.0.53Адреса и имена в примере учебные. Точка после полного имени устраняет неоднозначность DNS search suffix. Не сравнивайте запрос app на одном компьютере с app.corp.example. на другом: итоговые имена могут различаться.
В выводе nslookup первые Server/Address относятся к резолверу, а не к сайту. Метка UnKnown у сервера часто означает отсутствие PTR его IP; она сама по себе не доказывает отказ DNS. Справка Microsoft nslookup описывает интерактивный и обычный режимы.
2. Проверьте A и AAAA раздельно
Один домен может иметь несколько A, несколько AAAA или CNAME. Приложение выбирает конкретный адрес по своим правилам, а IPv6-путь может быть неисправен при полностью исправном IPv4.
nslookup -type=A app.corp.example. 10.77.0.53
nslookup -type=AAAA app.corp.example. 10.77.0.53
nslookup -type=CNAME app.corp.example. 10.77.0.53Проверяйте всю цепочку CNAME, а не только первую строку. Например, alias может указывать на имя в другой зоне, и проблема окажется в разрешении конечного имени. Отсутствие AAAA при наличии A не является отказом домена; это может быть штатный IPv4-only сервис.
Для Windows доступны более структурированные данные:
Resolve-DnsName -Name 'app.corp.example.' -Type A -Server '10.77.0.53' -DnsOnly -NoHostsFile
Resolve-DnsName -Name 'app.corp.example.' -Type AAAA -Server '10.77.0.53' -DnsOnly -NoHostsFile-DnsOnly и -NoHostsFile ограничивают дополнительные механизмы разрешения. Сравнивайте ответы одного типа и одного сервера; иначе разница может быть следствием разных маршрутов запроса.
Адреса, псевдонимы и набор записей
nslookup -type=A www.example.com. 1.1.1.1
nslookup -type=AAAA www.example.com. 1.1.1.1
nslookup -type=CNAME www.example.com. 1.1.1.1A возвращает IPv4, AAAA — IPv6, CNAME — каноническое имя псевдонима. Запрос A к псевдониму может показать CNAME и адрес его цели; это несколько связанных записей, а не два конкурирующих IP. После CNAME проверьте A/AAAA конечной цели тем же резолвером. Несколько адресов одного типа — нормальный RRset: порядок вывода нельзя считать порядком предпочтения приложения.
www.example.com canonical name = edge.example.net
Name: edge.example.net
Addresses: 2001:db8::10
192.0.2.10
192.0.2.11
Aliases: www.example.comВ этом иллюстративном выводе владельцем адресов является edge.example.net. Если edge разрешается иначе в корпоративном и публичном DNS, один и тот же CNAME может приводить клиентов к разным конечным узлам. Традиционный CNAME не совмещают с другими обычными данными того же владельца; поведение ALIAS/ANAME у провайдера — функция его платформы, не новый способ интерпретации стандартного CNAME. Различия RRset и CNAME уточняет RFC 2181.
Увидьте TTL и поля записи
В Windows доступна структурированная альтернатива:
Resolve-DnsName -Name example.com. -Type A -Server 1.1.1.1 -DnsOnly |
Select-Object Name,Type,TTL,Section,IPAddressTTL — секунды разрешённого кеширования, а не время жизни домена. Если два запроса к кеширующему серверу выполняются с интервалом 10 секунд, TTL обычно уменьшается примерно на 10. Если он вернулся к исходному, ответ мог быть обновлён или получен от другой кеширующей ноды. TTL CNAME и A цели могут отличаться, поэтому изменение цели не обязано одновременно исчезнуть во всех кешах.
3. Отличите NXDOMAIN, отсутствие типа и SERVFAIL
NXDOMAIN означает, что сервер сообщает об отсутствии запрошенного имени. NOERROR с пустым ответом нужного типа может означать существующее имя без этой записи. SERVFAIL означает невозможность обработки запроса: среди причин недоступный upstream, ошибка DNSSEC, неправильная делегация или проблема authoritative-сервера.
Узнать подробности в Windows можно интерактивно:
nslookup
server 10.77.0.53
set timeout=3
set retry=1
set debug
set type=A
app.corp.example.
exitИнтерпретация конкретного текста ошибок отличается между реализациями nslookup. Для явного RCODE и флагов ответа на Linux удобно дополнительно применять dig из dnsutils:
dig @10.77.0.53 app.corp.example. A +noall +comments +answer +authorityВ header ищут status, в flags — наличие aa/ra, в ANSWER — результат, в AUTHORITY — сведения отрицательного ответа. Сохраните фактический вывод, не заменяйте его картинкой из другой системы. Отрицательные ответы тоже могут кешироваться; немедленное повторение не обязательно проверяет источник заново.
Три принципиально разных результата
NXDOMAIN означает отсутствие запрошенного имени в данном DNS-представлении. NOERROR с пустым answer для конкретного типа означает NODATA: имя может существовать, но AAAA, например, отсутствует. SERVFAIL означает невозможность корректно завершить обработку: причины включают недоступность authoritative, проблемы делегирования и DNSSEC. Timeout означает отсутствие своевременного ответа; он вообще не сообщает о существовании имени.
Практический порядок: проверьте A и AAAA отдельно, сохраните RCODE в debug-выводе, повторите на втором разрешённом резолвере, затем опросите authoritative. Если authoritative отвечает корректно, а валидирующий резолвер даёт SERVFAIL, исследуйте делегирование и DNSSEC, а не добавляйте случайную A-запись.
Разберите DNS-сообщение по секциям
nslookup
server 1.1.1.1
set debug
set type=A
example.com.
set nodebug
exitВ отладочном выводе Question содержит запрошенные имя, тип и класс; Answer — найденные ответы; Authority — сведения об авторитетной зоне/отрицательном ответе; Additional — дополнительные записи. AA показывает авторитетность ответа, RD — запрос рекурсии, RA — её доступность, TC — усечение. Эти флаги не обозначают шифрование. AD относится к аутентифицированным данным, но доверять ему можно только в соответствующей доверенной схеме резолвера. Структура сообщения описана в RFC 1035.
Параметры интерактивного режима конкретной реализации проверяют через help. Строки server, set и exit вводятся внутри nslookup, не как самостоятельные команды PowerShell. Именно смешение этих двух оболочек часто делает копируемые инструкции неработоспособными.
4. Разберите timeout и TCP 53
Timeout говорит об отсутствии своевременного ответа, но не определяет уровень причины. Сначала проверьте доступный маршрут до резолвера и правила UDP/TCP 53. Пинг может быть запрещён при исправном DNS, а успешный TCP handshake не проверяет обработку DNS-запроса.
Test-NetConnection -ComputerName '10.77.0.53' -Port 53Эта команда проверяет TCP, не UDP. Для DNS-запроса поверх TCP используйте интерактивный nslookup:
nslookup
server 10.77.0.53
set vc
set type=A
app.corp.example.
exitКоманда set vc включает virtual circuit. Если UDP не работает, а TCP-запрос успешен, проверяют UDP ACL, MTU, фрагментацию и обработку больших ответов. Для Linux сравните dig @10.77.0.53 app.corp.example. A и ту же команду с +tcp.
Не открывайте порт 53 из Интернета на корпоративный recursive resolver ради такого теста. Проверка производится из разрешённой клиентской сети. Forwarder, отвечающий только на TCP, не заменяет корректно настроенный доступ клиентов по DNS.
Проверьте транспорт и таймаут отдельно
Test-NetConnection -ComputerName 192.0.2.53 -Port 53
nslookup.exe -timeout=3 -retry=1 -type=A example.com. 192.0.2.53
nslookup.exe -vc -type=A example.com. 192.0.2.53192.0.2.53 — учебный адрес; для выполнения замените его настоящим DNS. Test-NetConnection проверяет TCP 53, не UDP. -vc заставляет nslookup использовать TCP; если обычный запрос работает, а TCP нет, DNS может ломаться на больших ответах или при fallback после усечения. -timeout ограничивает ожидание, -retry — повторы в выбранной реализации. В интерактивном режиме используйте set timeout=3, set retry=1, set vc.
Запрос DNS обычно использует UDP, но TCP обязателен для полноценной реализации современного DNS; он не предназначен только для zone transfer. При TC клиент может повторить запрос по TCP. Разрешение одного UDP 53 в ACL недостаточно. Это требование подробно описано в RFC 7766.
Если TCP работает, а UDP нет, проверяйте UDP ACL, обратный путь и размер пакета. ICMP ping к DNS не доказывает доступность его службы. Отсутствие ping тоже не доказывает отказ DNS: ICMP могут фильтровать. Внутреннее имя не отправляют публичному резолверу ради проверки транспорта.
5. Найдите authoritative-сервер домена
Для публичной зоны сначала запросите NS, затем IP одного из возвращённых имён NS, после чего обратитесь к этому серверу напрямую. В примере example.com — зарезервированный демонстрационный домен; его реальные ответы могут меняться.
nslookup -type=NS example.com. 1.1.1.1
nslookup -type=SOA example.com. 1.1.1.1Подставьте фактический IP выбранного authoritative NS в следующий запрос, не адрес случайного резолвера. В debug/dig проверьте флаг authoritative. Non-authoritative answer на recursive DNS ожидаем: это не признак недостоверности данных.
При различиях между NS проверьте состояние зоны и её репликацию. SOA serial полезен для сравнения, но равный serial сам по себе не доказывает равенство каждой записи. Для публичной делегации дополнительно используют dig +trace example.com. NS; этот тест требует доступности внешних DNS и не предназначен для приватной зоны за VPN.
NS, SOA и прямой опрос authoritative
nslookup -type=NS example.com. 1.1.1.1
nslookup -type=SOA example.com. 1.1.1.1
nslookup -type=A ns1.example.net. 1.1.1.1
nslookup -type=A www.example.com. 192.0.2.53В последней команде используйте полученный адрес авторитетного сервера вместо учебного. NS — серверы обслуживания зоны, не обязательно адрес сайта и не рекурсивный DNS вашего компьютера. SOA содержит primary name server, contact в специальной записи, serial, refresh, retry, expire и minimum. Serial — номер версии зоны, а не TTL каждого адреса. Он может выглядеть как дата, но такой формат не обязателен.
example.com
primary name server = ns1.example.net
responsible mail addr = hostmaster.example.com
serial = 2026101101
refresh = 3600
retry = 600
expire = 1209600
default TTL = 300Это пример, не фактическая SOA example.com. Contact hostmaster.example.com обычно представляет hostmaster@example.com с DNS-правилами экранирования. Refresh/retry/expire регулируют поведение вторичных серверов. Поле, подписанное некоторыми nslookup как default TTL, не нужно трактовать как универсальный TTL всех записей.
Найдите расхождение между делегированием и зоной
Опросите каждый authoritative по IP и сравните ответ и SOA serial. Разные serial могут означать неполную синхронизацию; одинаковые serial не исключают ошибку содержимого. При подозрении на делегирование используйте dig +trace example.com. NS из сети, где разрешены прямые DNS-запросы. Trace показывает переходы root → TLD → зона, но не воспроизводит кеш корпоративного резолвера. Публикация новых NS в панели DNS-провайдера не меняет автоматически делегирование у регистратора.
6. Проверьте split DNS и политику VPN
Внутри компании имя может указывать на внутренний адрес, снаружи — на публичный, либо отсутствовать вовсе. Это штатная split DNS-схема. Для её проверки используйте один клиент, одинаковое полное имя и конкретные резолверы; фиксируйте, включён ли VPN.
Get-DnsClientNrptPolicy -Effective
nslookup app.corp.example. 10.77.0.53
Get-DnsClientServerAddress -AddressFamily IPv4NRPT может направлять часть пространств имён на специальные серверы. Явно адресованный nslookup помогает проверить конкретный сервер, но не полностью воспроизводит политику приложения и системного резолвера. Поэтому следующим шагом проверяют Resolve-DnsName без -Server и само приложение.
Если внутреннее имя разрешается публичным сервером неправильно, не добавляйте его в hosts как постоянное решение. Уточните VPN DNS suffix, route до корпоративного DNS, NRPT и настройки профиля. Hosts скрывает проблему и создаёт дополнительную неуправляемую копию адреса.
Воспроизведите проблему с включённым и выключенным VPN
Get-DnsClientServerAddress
Get-DnsClientNrptPolicy
Resolve-DnsName -Name app.corp.example. -DnsOnly
Resolve-DnsName -Name app.corp.example. -Server 10.77.10.53 -DnsOnlyapp.corp.example — условное внутреннее имя. Первый Resolve-DnsName проверяет системный путь, второй — конкретный сервер. Различие помогает найти проблему политики выбора DNS, но не разрешает менять корпоративный резолвер на публичный. NRPT может задавать DNS-политику для отдельных namespaces; адаптер VPN также влияет на выбор пути. Сохраните вывод в обоих состояниях VPN и укажите, на каком этапе меняется ответ.
На systemd-resolved-хосте выполните resolvectl status и resolvectl query app.corp.example. Адрес 127.0.0.53 в resolv.conf часто является локальным stub, а реальные upstream находятся в per-link настройках. Прямое редактирование генерируемого resolv.conf может быть перезаписано network manager. Не отключайте resolved только потому, что видите loopback.
Браузер может использовать отдельный DoH-резолвер, приложение — hosts или свой кеш, корпоративный агент — собственный прокси. Проверяйте фактическую схему конкретного клиента. Системный DNS и прямой запрос nslookup полезны как разные измерения, а не как взаимозаменяемые доказательства.
7. Отделите кеш клиента от кеша сервера
После изменения A-записи старый ответ может находиться в recursive cache, кеше Windows, браузера или приложения. TTL определяет срок кеширования конкретного DNS-ответа; он не является универсальным таймером «обновления всего Интернета». Снижение TTL уже опубликованной записи не удаляет ранее кешированные ответы.
Get-DnsClientCache | Where-Object Entry -Like '*corp.example*'
Resolve-DnsName 'app.corp.example.' -Server '10.77.0.53' -Type A -DnsOnlyСначала сравните конкретный recursive server с authoritative. Только если stale-ответ локален, очищайте кеш конкретного тестового клиента: Clear-DnsClientCache. Это не очищает DNS-сервер, браузер или внешний resolver. Сохраните результат до очистки, чтобы не потерять доказательство.
Браузер с собственным DoH может использовать другой путь. Проверяйте корпоративные настройки браузера и адрес фактического соединения. Успешный nslookup при ошибке браузера не даёт основания менять DNS-зону без дополнительных данных.
Почему «очистить кеш» часто не помогает
Clear-DnsClientCache сбрасывает кеш Windows-клиента, но не кеш корпоративного сервера, браузера, CDN и authoritative. Прямой nslookup к заданному серверу не является проверкой содержимого Windows DNS Client cache. Поэтому сначала сравните authoritative и используемый рекурсивный сервер; только затем решайте, какой кеш мешает.
Get-DnsClientCache | Where-Object Entry -Like '*example.com*'
Clear-DnsClientCache
Resolve-DnsName -Name example.com. -Type A -DnsOnlyДля запланированного изменения IP заранее уменьшите TTL и дождитесь истечения прежнего значения до переключения. Снижение TTL в момент изменения не сокращает уже сохранённый старый ответ. Отрицательные ответы тоже кешируются: RFC 2308 описывает связь отрицательного TTL с SOA. Для NXDOMAIN/NODATA это не обязательно тот же срок, что у прежней A-записи.
Если authoritative уже новый, а рекурсивный ещё старый с уменьшающимся TTL, наблюдайте до предусмотренного истечения. Если authoritative сами расходятся, очистка клиентского кеша не устранит проблему. В протоколе изменения укажите старое/новое значение и результаты отдельно для каждого сервера.
8. Проверьте MX, TXT и PTR без ошибочных выводов
При проблемах доставки почты запросите MX, затем A/AAAA каждого mail exchanger. Меньшее число MX preference означает более высокий приоритет, но недоступность одного сервера и поведение конкретного отправителя требуют проверки отдельно.
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 -type=PTR 25.30.77.10.in-addr.arpa. 10.77.0.53PTR-пример соответствует 10.77.30.25 и относится к внутреннему DNS. TXT может содержать несколько строк одного значения; их нельзя механически считать несколькими независимыми SPF-политиками. DKIM ищут по известному selector, а не по случайному имени.
Получение MX подтверждает наличие DNS-данных, не доступность SMTP и не корректность TLS. Отсутствие PTR не доказывает, что forward DNS не работает. Для разъяснения самих записей используйте практическое руководство по DNS-записям, чтобы не смешивать аудит почтовой политики с диагностикой резолвера.
MX: куда отправлять почту и что означает приоритет
nslookup -type=MX example.com. 1.1.1.1
nslookup -type=A mx1.example.net. 1.1.1.1
nslookup -type=AAAA mx1.example.net. 1.1.1.1В примере 10 mx1.example.net и 20 mx2.example.net меньшее число 10 предпочтительнее. Одинаковые приоритеты позволяют распределять попытки доставки; конкретное поведение зависит от MTA. Это не порт, не рейтинг безопасности и не процент трафика. После MX проверьте адреса каждого exchange, затем доступность SMTP отдельно. MX не показывает, где размещён веб-сайт.
Особый случай 0 . — Null MX: домен явно не принимает почту, а точка не является именем почтового сервера. Его назначение определено в RFC 7505. Отсутствие MX и явный Null MX имеют различную семантику; не создавайте фиктивный MX, чтобы убрать предупреждение проверки.
TXT: SPF, DKIM, DMARC и подтверждение владения
nslookup -type=TXT example.com. 1.1.1.1
nslookup -type=TXT _dmarc.example.com. 1.1.1.1
nslookup -type=TXT selector1._domainkey.example.com. 1.1.1.1DKIM selector берут из конфигурации отправителя или заголовка письма, его нельзя вычислить из домена. TXT-ответ может быть разбит на несколько строк в кавычках; части одного RR соединяются, разные RR не объединяют в одну строку. В SPF отдельные значения include, ip4 и -all интерпретируются по его синтаксису, а не просто по присутствию слова SPF. Вывод TXT доказывает публикацию данных, но не факт успешной подписи письма. Для почтовой проверки дополнительно анализируют Authentication-Results реального тестового сообщения.
PTR и обратная зона
nslookup 192.0.2.10 1.1.1.1
nslookup -type=PTR 10.2.0.192.in-addr.arpa. 1.1.1.1Обе формы запрашивают обратное имя IPv4. PTR управляется владельцем соответствующей адресной зоны, обычно провайдером IP, и не создаётся автоматически при добавлении A. Forward-confirmed reverse DNS требует проверить A/AAAA имени из PTR и убедиться, что среди них есть исходный адрес. Несовпадение DNS не равно отсутствию TCP-связи, но для почтовой репутации и журналирования может быть значимым.
9. Почему nslookup не показывает все поддомены
DNS обычно отвечает на запрос известного имени, а не выдаёт каталог всех имён домена. Запрос NS не является перечислением поддоменов. Wildcard может отвечать даже на несуществующие ранее имена; положительный A сам по себе не доказывает отдельную созданную запись.
Для своих зон список получают из панели DNS или административного экспорта. Запрашивают известные www, mail, vpn и прикладные имена по реестру, затем сравнивают с фактической конфигурацией. Certificate Transparency может давать отдельные наблюдаемые имена, но не полную актуальную инвентаризацию DNS.
Не используйте случайный успешный ответ wildcard как основание создать сотни «найденных» страниц в SEO-отчёте. И не включайте zone transfer наружу ради удобного списка: AXFR предназначен для управляемого обмена зоной и должен ограничиваться разрешёнными вторичными серверами.
Проверьте известные поддомены, не обещая полный список
nslookup -type=A www.example.com. 1.1.1.1
nslookup -type=A mail.example.com. 1.1.1.1
nslookup -type=CNAME shop.example.com. 1.1.1.1
nslookup -type=A avg-nonexistent-20261011.example.com. 1.1.1.1Случайное имя в последней строке помогает заметить wildcard: если оно получает ответ, это не доказывает существование явно заведённого поддомена. Сопоставьте с DNS-панелью и конфигурацией зоны. Wildcard может зависеть от наличия других узлов; его нельзя свести к «любое имя всегда ведёт на IP». Подробности — RFC 4592.
ANY не является запросом «всей зоны». Сервер вправе дать минимальный ответ, что закрепляет RFC 8482. AXFR — механизм передачи зоны с отдельными разрешениями; для собственного домена полный перечень получают из панели/экспорта или разрешённой административной передачи. Не открывайте AXFR всему Интернету ради удобства справочника. Данные certificate transparency и поискового индекса тоже не являются гарантированно полным списком текущих DNS-узлов.
10. Завершите диагностику проверкой приложения
В отчёте фиксируют имя, тип записи, resolver, RCODE, returned addresses, TTL, authoritative-ответ, интерфейс/VPN и время. После устранения причины повторяют запрос тем же способом и открывают фактический сервис. Для HTTPS отдельно проверяют сертификат, Host/SNI и ответ веб-сервера.
Последовательность решения: точное имя → конкретный DNS → код ответа → authoritative-источник → кеш/политика → приложение. Такой маршрут позволяет отличить ошибку зоны от сетевого запрета и не «лечить DNS» сменой всех серверов сразу. Изменения выполняют на доказанном уровне, сохраняя исходную конфигурацию и результат до/после.
Свяжите DNS с проверкой сайта и SEO
После подтверждения A/AAAA проверьте HTTPS-ответ с сохранением правильного имени и TLS SNI. Чтобы временно обойти DNS при диагностике конкретного веб-узла, можно использовать curl --resolve:
curl --resolve www.example.com:443:192.0.2.10 -I https://www.example.com/Здесь IP заменяют реальным адресом сервера. Такой запрос сохраняет имя в URL, Host и проверке сертификата; открытие голого https://IP не воспроизводит виртуальный хост. Отказ сертификата не устраняют --insecure в постоянном рецепте. Сравните www и apex, HTTP→HTTPS, canonical и итоговый статус страницы, затем убедитесь, что системный клиент получает тот же рабочий узел.
Для тикета соберите: время и сеть/VPN, полное имя, тип запроса, DNS-сервер, RCODE, ответ/TTL, результат authoritative, различия между резолверами и проверку приложения. Такой отчёт позволяет другому администратору повторить действия. Для SEO DNS — только слой доступности: корректная A-запись не гарантирует индексацию, robots, sitemap и содержимое страницы проверяют отдельно.
Нужна диагностика DNS?
Если nslookup показывает неожиданный результат, проверьте DNS-серверы, зоны, маршрутизацию и доступность инфраструктуры.