Популярные инструменты

Тема

Проверка DNS домена

Проверьте DNS домена целиком: делегирование в реестре, каждый NS-сервер, опрошенный напрямую, SOA, DNSSEC и почтовые записи. 40 проверок, и у каждой есть исправление.

Уровни по Zonemaster и RFC · каждый DNS-сервер опрошен по TCP · Google Public DNS · RDAP

Идём от корневого сервера к реестру .nl, затем напрямую спрашиваем каждый DNS-сервер домена sidn.nl · 40 проверок · около 3 среестр .nl → каждый DNS-сервер · 40 проверок

Примеры
ПримерЗаписано 23 окт. 2026 г. · с нашего сервера.nl3 NSDNSSEC подписан

sidn.nl проходит все выполненные проверки, включая DNSSEC

регистратор: SIDN·2,9 с

40 в норме

A+: ничего выше уровня «инфо». Каждый DNS-сервер ответил авторитетно и согласуется с остальными, таймеры в пределах диапазона Zonemaster, а Google Public DNS успешно проверяет цепочку DNSSEC от корня.

Сначала проблемы

Запросы по TCP с нашего сервера на периферии Cloudflare: корневой сервер, реестр .nl и каждый DNS-сервер напрямую; Google Public DNS и Cloudflare — для почтовых записей и валидации. Мы не ведём журнал того, что вы проверяете.

Что входит в проверку DNS домена?

Проверка DNS домена проходит тот путь, которым домен находит резолвер, и тестирует каждый шаг: делегирование в реестре, каждый DNS-сервер, опрошенный напрямую, согласие этих серверов между собой, запись SOA, DNSSEC и почтовые записи. Здесь выполняется 40 проверок в семи группах, и каждая оценивается на уровне, который задаёт её источник.

Большинство сервисов проверки спрашивают резолвер и оценивают то, что он вернул. Так серверы за ним остаются невидимыми: резолвер отвечает с того DNS-сервера, который работает, и сломанный сервер незаметен, пока не откажут и остальные. Здесь каждый DNS-сервер опрашивается по TCP с выключенной рекурсией, копия NS-записей в реестре сравнивается с собственной копией зоны, а цепочка DNSSEC проверяется от DS в реестре до подписей в зоне.

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

Кореньh.root-servers.net
.comРеестр .comh.gtld-servers.net
8 DNS-серверовRoute 53 + NS1
Зонаgithub.com
  • DNSSEC7 проверокцепочка доверия от корня: github.com — обрыв на .com (нет DS)
  • Родитель и делегирование6 проверокперенаправление реестра: 8 имён · 295 байт · glue не нужен
  • DNS-серверы14 провероккаждый сервер опрошен напрямую: авторитетно: 8 из 8 · по TCP · EDNS · без рекурсии
  • Согласованность3 проверкисогласуются ли серверы: 2 серийных номера SOA, по одному на DNS-хостинг · одинаковые MX и SPF
  • SOA4 проверкитаймеры ниже минимумов Zonemaster: уведомления
  • CAA1 проверка7 записей · разрешены 4 УЦ
  • DNS для почты5 проверокMX: Microsoft 365 · SPF: 10 из 10 запросов · DMARC quarantine
Куда смотрит каждая группа проверок на реальном пути github.com (23 октября 2026 г.): от корня через реестр .com к DNS-серверам зоны в Route 53 и NS1.
Проверка DNS домена github.com: оценка A, 40 проверок в семи группах и путь от корня к 8 DNS-серверамПроверка DNS домена github.com: оценка A, 40 проверок в семи группах и путь от корня к 8 DNS-серверамОценкаТолько по уровням: ни одной критической проблемы, ни одной ошибки, два предупреждения — это A. Кольцо показывает балл: 90 из 100.40 проверок, по ячейке на каждуюСгруппированы так же, как на странице. Жёлтые и синие ячейки — предупреждения и уведомления; заштрихованные выполнить не удалось.Сначала проблемыГруппы, где есть что исправить, открыты наверху, и в каждой строке указаны источник правила и исправление.ПутьКорневой сервер, реестр .com, который ведёт Verisign, затем каждый DNS-сервер, опрошенный напрямую: его ответ, серийный номер и EDNS.Цепочка доверияПолоса DNSSEC рядом с путём: зелёная там, где цепочка держится, пунктирная там, где она заканчивается, и красная там, где рвётся.
Проверка DNS домена github.com. Выберите номер, чтобы узнать, что показывает каждая часть.

Как выставляется оценка?

Буква зависит только от уровней того, что не прошло, и никогда от таблицы баллов: любая критическая проблема — это F, две ошибки и больше — D, одна ошибка или пять предупреждений и больше — C, три или четыре предупреждения — B, одно или два предупреждения (или только уведомления) — A, а если нет ничего выше уровня «инфо» — A+.

Уровни задаёт тот, на кого ссылается проверка: профиль Zonemaster по умолчанию, если тест определён там, иначе MUST или SHOULD из RFC. Число из 100 лишь ранжирует домены внутри одной буквы (100 − 30 за каждую критическую проблему, 12 за ошибку, 4 за предупреждение, 1 за уведомление). Проверки, которые наш сервер не может выполнить, никогда не засчитываются против домена; если не удаётся выполнить четверть проверок или больше, оценка помечается как частичная.

  1. A+100ничего выше уровня «инфо»INFO «определённо не указывает на проблему»sidn.nl100
  2. A90–991–2 предупреждения или только уведомленияNOTICE «администратору зоны следует об этом знать, но это вовсе не обязательно проблема»github.com90example.com95bücher.de90
  3. B75–893–4 предупрежденияWARNING «при некоторых обстоятельствах станет проблемой, но обычный пользователь вряд ли это заметит»cloudflare.com87google.com83
  4. C60–741 ошибка или 5 и более предупрежденийERROR «весьма вероятно (или наверняка) негативно скажется на работе зоны»в выборке нет
  5. D45–592 и более ошибкиdnssec-failed.org55
  6. F0–44любая критическая проблемаCRITICAL «зону можно обоснованно считать несуществующей»домен в .com44

балл = 100 − 30 × критические − 12 × ошибки − 4 × предупреждения − 1 × уведомления, в пределах диапазона буквы

частичнаячетверть проверок или больше не удалось выполнить с нашего сервера, и оценка это отмечает

Шкала оценок с доменами, которые мы проверили 23 октября 2026 г., по их записанной оценке. Уровни процитированы по определениям серьёзности Zonemaster.

Совпадают ли NS-записи родительской и дочерней зоны?

Должны: реестр (родитель) и зона (дочерняя) публикуют каждый свой набор NS, и по RFC 1912 §2.8 они должны совпадать. Когда реестр указывает на сервер, который не отвечает за зону, это lame-делегирование: сервер отвечает REFUSED или отвечает без флага авторитетности (AA).

Резолверы переходят к следующему серверу, так что один lame-сервер стоит лишь времени; когда lame все указанные серверы, домен перестаёт разрешаться. Zonemaster оценивает имена, которые есть только в реестре, как ошибку (EXTRA_NAME_PARENT), имена, которые есть только в зоне, — как уведомление, а отсутствие хотя бы одного рабочего сервера — как критическую проблему.

github.comсовпадают

Реестр .com
  • ns-520.awsdns-01.net
  • ns-421.awsdns-52.com
  • ns-1707.awsdns-21.co.uk
  • ns-1283.awsdns-32.org
  • dns1–4.p08.nsone.net
Зона
  • те же 8

авторитетно (AA) отвечают 8 из 8

домен в .netрасходятся

Реестр .net
  • ns1.domaindirect.com
  • ns2.domaindirect.comREFUSED
  • ns3.domaindirect.com
Зона
  • ns1.hover.com
  • ns2.hover.com

нет общих имён · ns2.domaindirect.com: REFUSED · 2 ошибки

домен в .comlame-делегирование

Реестр .com
  • ns63.domaincontrol.comREFUSED
  • ns64.domaincontrol.comREFUSED
Зона
  • никто не отвечаетSERVFAIL

все серверы отвечают REFUSED · резолверы отвечают SERVFAIL · CRITICAL

Три делегирования, записанные 23 октября 2026 г.. Имена двух неисправных скрыты; их DNS-серверы и ответы настоящие.

Сколько NS-серверов нужно домену?

Не меньше двух, а рекомендуется три. RFC 1034 §4.1 требует, чтобы каждая зона была доступна как минимум на двух серверах, а RFC 2182 §5 рекомендует три для большинства зон уровня организации. Один DNS-сервер — это ошибка в Zonemaster; два проходят с информационной пометкой.

Где они стоят, важнее, чем сколько их, поэтому проверка NS-серверов смотрит и на их сети. Серверы в одной сети отказывают вместе: Zonemaster предупреждает, когда все адреса находятся в одной автономной системе (IPV4_ONE_ASN), даже для anycast-хостов вроде Google, Cloudflare или Akamai, где каждый адрес отвечает из многих точек. Anycast распределяет нагрузку, но оператор всё равно один.

  • google.com4 NS · 1 сетьодна сеть
  • github.com8 NS · 2 сетиразнесены
  • sidn.nl3 NS · 2 сетиразнесены
  • cloudflare.com5 NS · 1 сетьодна сеть
  • nasa.gov6 NS · 1 сетьодна сеть
  • example.com2 NS · 1 сетьодна сеть

AS1921 ipcomAS13335 CloudflareAS15169 GoogleAS16509 AmazonAS21342 AkamaiAS48283 SIDNAS62597 NS1

«Рекомендуется предоставлять три сервера для большинства зон уровня организации, причём по меньшей мере один из них должен быть хорошо удалён от остальных». RFC 2182 §5
По точке на DNS-сервер, цвет — сеть (AS), из которой анонсирован его адрес, по проверкам, записанным 23 октября 2026 г.. Одна сеть — это предупреждение Zonemaster IPV4_ONE_ASN, с anycast или без.

Правильны ли значения записи SOA?

Если их задал крупный DNS-хостинг, они почти наверняка в порядке, даже если какой-то сервис проверки их отмечает. Refresh, retry и expire управляют только вторичными серверами, которые копируют зону передачей зоны. Minimum — это TTL отрицательного кэширования (RFC 2308): как долго резолверы помнят, что имени не существует.

RIPE-203 (1999) рекомендует refresh 86400, retry 7200, expire 3600000 и minimum 172800, причём последнее значение появилось ещё до RFC 2308. Zonemaster задаёт более низкие минимумы: refresh 14400 и retry 3600 (уведомления), expire 604800 (единственное предупреждение), minimum от 300 до 86400 (уведомление). Значения по умолчанию у Cloudflare, Route 53 и Azure ниже минимумов для refresh и retry; expire в 3 дня у Google Cloud DNS — единственное предупреждение среди крупных хостингов.

refreshZonemaster ≥ 4 ч · ◆ 1 дн.retryZonemaster ≥ 1 ч · ◆ 2 чexpireZonemaster ≥ 7 дн. · ◆ 41,7 дн.minimumZonemaster 5 мин – 1 дн. · ◆ 2 дн.
Cloudflare2,8 ч40 мин7 дн.30 мин2 уведомления
Amazon Route 532 ч15 мин14 дн.1 дн.2 уведомления
Google Cloud DNS6 ч1 ч3 дн.5 мин1 предупреждение
Azure DNS1 ч5 мин28 дн.5 мин2 уведомления
GoDaddy8 ч2 ч7 дн.1 чнорма
Namecheap BasicDNS12 ч1 ч7 дн.1 чнорма
google.com (собственные)15 мин15 мин30 мин1 мин1 предупреждение · 3 уведомления

ниже минимума ZonemasterнормауведомлениепредупреждениеRIPE-203 (1999)

Значения каждого хостинга в том виде, в каком их отдавали его зоны через dig 23 октября 2026 г.: у Cloudflare, Route 53 и Google Cloud DNS они совпадают с документацией; справка GoDaddy называет minimum 600, а его зоны-примеры отдают 3600; опубликованных значений по умолчанию для Azure DNS и Namecheap BasicDNS мы не нашли, поэтому для них показаны значения их зон. Логарифмическая шкала от 1 минуты до 6 недель.

Проверка DNSSEC: DS, DNSKEY и подписи

Проверка DNSSEC проходит по цепочке доверия: запись DS в реестре должна быть хешем ключа (DNSKEY) в зоне, этот ключ должен подписывать набор ключей зоны, а каждая подпись (RRSIG) должна проходить проверку и находиться в пределах срока действия. Эта проверка сама вычисляет хеш и проверяет каждую подпись, а затем спрашивает Google Public DNS, проходит ли зона валидацию.

Порвите любое звено, и валидирующие резолверы ответят SERVFAIL: домен пропадёт для всех, кто за ними. dnssec-failed.org, тестовая зона, которую намеренно держат сломанной, показывает сразу два разрыва. Алгоритмы оцениваются по реестру IANA (RFC 9904): рекомендуются 8, 13 и 15, а 5 и 7, которые подписывают с SHA-1, больше нельзя использовать (RFC 9905), и Zonemaster оценивает их как ошибку.

cloudflare.comзащищено

  1. DS 2371 в .comалгоритм 13 · SHA-256 · 329968…26F2B9
  2. хеш совпадает с ключом 2371
  3. DNSKEY 2371 · KSKфлаги 257 · ECDSA P-256 (13)
  4. подписывает набор ключей · осталось 50,8 дня из 61 день
  5. DNSKEY 34505 · ZSKфлаги 256 · ECDSA P-256 (13)
  6. подписывает записи · SOA: осталось 1 день из 2 дня
  7. Google Public DNSфлаг AD установлен: защищено

dnssec-failed.orgнедействительно

  1. DS 42069 в .orgалгоритм 13 · SHA-256
  2. в зоне нет ключа 42069
  3. DNSKEY 50719 · KSKнастоящий KSK зоны (ключ подписи ключей)
  4. его подпись набора ключей истекла 112 дней назад
  5. DNSKEY 32784 · ZSKподписывает SOA: действует, осталось 5,7 дня из 7 дней
  6. до него не доходит ничего доверенного
  7. Google Public DNSSERVFAIL; с флагом CD ответ есть: недействительно (bogus)

Алгоритмы подписи (реестр IANA, RFC 9904)

  • RECOMMENDED8 RSASHA256 · 13 ECDSAP256SHA256 · 15 ED25519используйте эти
  • MAY14 ECDSAP384SHA384 · 16 ED448разрешены
  • NOT RECOMMENDED10 RSASHA512Zonemaster WARNING
  • MUST NOT5 RSASHA1 · 7 RSASHA1-NSEC3-SHA1 · 1 · 3 · 6 · 12RFC 9905 · Zonemaster ERROR

обе цепочки выше подписаны алгоритмом 13

Две цепочки, записанные 23 октября 2026 г.: у cloudflare.com она держится; у dnssec-failed.org рвётся на DS и ещё раз на истёкшей подписи.

DNS для почты: MX, SPF и DMARC

Почтовые проверки читают то же, что читают принимающие серверы: MX-записи (или null MX, который сообщает, что домен не принимает почту, RFC 7505), одну запись SPF в пределах лимита RFC 7208 в 10 DNS-запросов и политику DMARC (RFC 9989, который заменил RFC 7489 в мае 2026 года).

SPF не просто находится, а вычисляется: каждый include отслеживается и учитывается. Записи github.com нужно ровно 10 запросов плюс один пустой: она допустима, но запаса не осталось. Домен, который никогда не отправляет почту, должен об этом сказать: example.com публикует набор для «паркованного» домена — null MX, v=spf1 -all и p=reject. Подробнее — в проверке SPF и проверке DMARC.

github.comотправляет и принимает

MX
0 github-com.mail.protection.outlook.comMicrosoft 365 · 1 хост · не псевдоним
SPF
v=spf1 ip4:192.30.252.0/22 include:spf.protection.outlook.com include:_netblocks.google.com include:_netblocks2.google.com include:mail.zendesk.com include:_spf.salesforce.com include:servers.mcsv.net include:mktomail.com include:sendgrid.net ip4:62.253.227.114 ip4:166.78.69.169 ip4:166.78.69.170 ip4:166.78.71.131 ~all10 из 10 DNS-запросов1 из 2 пустых запросов · допустимо, запаса нет
DMARC
p=quarantine; sp=rejectотчёты на 1 адрес · поддомены: reject

example.comпаркованный набор

MX
0 .null MX: почту не принимает (RFC 7505)
SPF
v=spf1 -allпочту не отправляет · 0 запросов
DMARC
p=reject; sp=rejectвсё, что выдаёт себя за example.com, отклоняется
github.com и example.com в том виде, в каком они были опубликованы 23 октября 2026 г..

Как проверить DNS из командной строки (dig)

Четыре шага с dig и delv повторяют основу этой проверки: пройти делегирование от корня, спросить один DNS-сервер напрямую с выключенной рекурсией, сравнить DS в реестре с ключами зоны и дать валидирующему резолверу оценить цепочку.

Добавьте +tcp, чтобы увидеть то же, что видит наш сервер; без него вы проверяете UDP, а этого веб-инструмент в сети Cloudflare сделать не может. В заголовке ответа aa обозначает авторитетный ответ; REFUSED или отсутствие флага aa у сервера, указанного в реестре, — это lame-делегирование.

Терминал · dig 9.20

$ dig +trace +tcp github.com NS
;; (сокращено)
com.          172800 IN NS a.gtld-servers.net.   ;; от h.root-servers.net 1
github.com.   172800 IN NS ns-520.awsdns-01.net. ;; от h.gtld-servers.net: 8 NS 2

$ dig @ns-421.awsdns-52.com github.com SOA +norec +tcp
;; flags: qr aa; QUERY: 1, ANSWER: 1 3
github.com.   900 IN SOA ns-1707.awsdns-21.co.uk. awsdns-hostmaster.amazon.com.
              1 7200 900 1209600 86400 4

$ dig @a.gtld-servers.net github.com DS +norec
;; status: NOERROR, ANSWER: 0 ;; нет DS: не подписан 5

$ delv @8.8.8.8 cloudflare.com SOA
; fully validated 6
cloudflare.com. 300 IN SOA ns3.cloudflare.com. dns.cloudflare.com.
                2417999975 10000 2400 604800 300
  1. Корень отправляет .com к его 13 серверам
  2. Набор NS для github.com из реестра, хранится 2 дня
  3. aa: авторитетный ответ, а не кэш
  4. SOA: серийный номер 1, затем refresh, retry, expire, minimum
  5. Нет DS в .com: DNSSEC проверять нечего
  6. delv проверил цепочку от корня
Настоящие ответы для github.com и cloudflare.com (23 октября 2026 г.), сокращённые. Пронумерованные метки соответствуют пояснениям.

Почему разные проверки DNS дают разные результаты?

Потому что они сверяются с разными числами. Классические сервисы проверки отмечают значения провайдеров по умолчанию: intoDNS называет expire google.com в 1800 секунд «NOT OK» и выдаёт ошибку на два серийных номера github.com, хотя для двух DNS-хостингов это нормально. Zonemaster оценивает серийные номера как предупреждение и распознаёт null MX; наша собственная первая версия ошибалась в обоих случаях.

И видят сеть они из разных мест. Zonemaster (AFNIC и шведский Internetstiftelsen) спрашивает по UDP и TCP, через IPv4 и IPv6. Эта проверка работает на периферии Cloudflare: она спрашивает только по TCP, не подключается по IPv6 и не может соединиться с собственными адресами Cloudflare, поэтому такие серверы читаются через 1.1.1.1, а их проверки помечаются как не проверено, а не как проваленные. Как альтернатива intoDNS она показывает источник каждого уровня вместо голого OK или NOT OK.

СлучайintoDNSZonemasterDNS Robot v1Эта проверка
github.comдва серийных номера SOA (два DNS-хостинга)ошибка“Looks like your nameservers do not agree on the SOA serial.”предупреждениеMULTIPLE_SOA_SERIALSсбой“Serial mismatch detected: 1656468023 vs 1.”предупреждениеобъяснено: по серийному номеру на DNS-хостинг
google.comSOA expire 1 800 сне OK“Your SOA EXPIRE number is: 1800. That is NOT OK”предупреждениеEXPIRE_MINIMUM_VALUE_LOWERсбой“too low (min recommended: 14 days)”предупреждениес пояснением, на что влияет expire
example.comнулевой MX (0 .)ошибка“0 No A Record (no glue either)”инфоZ09_VALID_NULL_MXнорма“Found 1 MX record(s)”нормаnull MX распознан
cloudflare.comSOA retry 2 400 с—не цитируетсяуведомлениеRETRY_MINIMUM_VALUE_LOWERсбой“too high (max recommended: 15min)”уведомлениезначение Cloudflare по умолчанию
cloudflare.comподписан DNSSECне проверяетсянет теста DNSSECнормаDNSSEC02 · 05 · 08: цепочка проверенавнимание“DNSSEC does not appear to be enabled for this domain.”нормаDS → KSK → RRSIG проверены, Google валидирует
Одни и те же домены в четырёх проверках. Результаты intoDNS и v1 процитированы с их страниц и из ответов за 22–23 октября 2026 г.; уровни Zonemaster взяты из спецификаций его тестов. Последний столбец — эта проверка: альтернатива intoDNS, которая оценивает каждое замечание на уровне, заданном его источником.

Проверка DNS домена: вопросы

Что такое проверка DNS домена?

Проверка DNS домена, или валидация DNS, показывает, настроен ли DNS так, чтобы домен был доступен из всего интернета: делегирование в реестре, каждый DNS-сервер, запись SOA, DNSSEC и почтовые записи. Каждое замечание оценивается по тому, насколько оно может навредить, от «инфо» до «критично», а этот валидатор DNS показывает применённое правило (тест Zonemaster или раздел RFC) и исправление.

Валидация домена — это то же самое, что проверка DNS?

Не всегда. «Валидацией домена» (domain validation) называют и проверку, которую удостоверяющий центр проводит перед выпуском DV-сертификата, и TXT-запись, которую Google Workspace или Microsoft 365 просят добавить, чтобы подтвердить владение доменом. Этот инструмент проверяет DNS домена: делегирование, DNS-серверы, SOA, DNSSEC и почтовые записи. Для сертификата воспользуйтесь проверкой SSL-сертификата.

Что такое lame-делегирование и как его исправить?

Lame-делегирование — это DNS-сервер из списка реестра, который не отвечает за ваш домен: он говорит REFUSED или отвечает без авторитетности. Исправлять нужно там, где расхождение: добавьте зону у этого DNS-хостинга или смените DNS-серверы у регистратора на те, где зона есть. Если lame все указанные серверы, домен не разрешается вообще.

Мой DNS-хостинг работает через anycast. Почему предупреждение про одну сеть?

Потому что один оператор — это одна точка отказа. Anycast позволяет каждому адресу отвечать из многих точек, и это защищает от отказа отдельной площадки, но не от сбоя у самого провайдера или ошибки в его конфигурации. Поэтому Zonemaster держит IPV4_ONE_ASN на уровне предупреждения, а RFC 2182 просит размещать серверы в разных сетях. Второй DNS-хостинг в другой сети снимает предупреждение.

Таймеры SOA помечены. Нужно ли их менять?

Обычно нет. Refresh, retry и expire важны только для вторичных серверов, которые копируют вашу зону передачей зоны; крупные хостинги вроде Cloudflare и Route 53 не используют их для вашей зоны, и их значения по умолчанию в порядке. Предупреждением Zonemaster считает только expire меньше недели. Меняйте значения, только если сами держите первичный и вторичные серверы.

Почему некоторые проверки помечены «не проверено»?

Потому что наш сервер не смог их выполнить, а не потому, что что-то не так. Он работает в сети Cloudflare, из которой нельзя подключиться к собственным адресам Cloudflare, спрашивает только по TCP и не подключается по IPv6. Такие серверы читаются через резолвер Cloudflare 1.1.1.1. Непроверенные проверки никогда не снижают оценку; если их четверть или больше, оценка помечается как частичная.

Почему DNS-серверы отдают разные серийные номера SOA?

Либо вторичный сервер ещё не догнал изменение, либо домен использует два DNS-хостинга, которые не передают зону друг другу, и у каждого свой серийный номер. Второй случай нормален: серверы Route 53 у github.com отдают 1, а его серверы NS1 — 1656468023. Zonemaster отмечает любое расхождение как предупреждение; мы объясняем, какой это случай.

Это проверка DNSSEC? И снижает ли оценку отсутствие DNSSEC?

Да: она сверяет DS в реестре с ключами зоны и проверяет каждую подпись, а затем спрашивает Google Public DNS. Неподписанная зона — это одно предупреждение Zonemaster (DS07_NOT_SIGNED), так что оценка остаётся не выше A. Сломанная цепочка гораздо хуже, чем никакой: валидирующие резолверы отвергают домен, и эта ошибка опускает оценку до C или ниже.

Как часто нужно проверять DNS домена?

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

Вы сохраняете домены, которые я проверяю?

Нет. Проверка выполняется на нашем сервере на периферии Cloudflare и спрашивает корневой сервер, реестр, ваши DNS-серверы, Google Public DNS и резолвер Cloudflare; ничего не записывается в журнал вместе с вашим адресом. Готовый результат хранится 10 минут, чтобы повторный запуск или ссылка открывались сразу, а затем удаляется. Ваши DNS-серверы получают от нашего сервера около 20 запросов за проверку.

Другие инструменты DNS