Список ошибок, с которыми сталкиваешься, когда ломается DNS, — от A до Z. Здесь три вида записей: коды ответа (RCODE), которые есть в каждом ответе DNS, расширенные ошибки DNS (EDE, RFC 8914), которыми современные резолверы поясняют сбой, и сообщения, которые вместо кода выводят браузеры, ОС и утилиты командной строки. Для каждой записи: что значит, обычная причина и что проверить дальше.
Чтобы увидеть «сырой» код, спросите напрямую: dig example.com показывает status: NXDOMAIN в заголовке и, если резолвер его прислал, строку EDE: в OPT-псевдосекции. Тот же статус показывает DNS Lookup. Три самых частых кода подробно разобраны в статье NXDOMAIN, SERVFAIL, REFUSED: что на самом деле значит ошибка DNS.
Ничего не найдено.
Сервер отклонил DNS Cookie (RFC 7873), присланный клиентом, — обычно из-за смены секрета на сервере или потому, что узлы anycast его не разделяют. Клиент повторяет запрос с новым cookie из ответа, так что единичный BADCOOKIE безвреден. Повторяющиеся сбои указывают на узлы anycast с разными секретами или на промежуточное устройство, переписывающее OPT-запись.
Сбои TSIG в подписанных сообщениях — обычно трансферах зон, NOTIFY или динамических обновлениях между серверами. BADSIG: подпись не сходится (неверный секрет). BADKEY: имя ключа или алгоритм неизвестны другой стороне. BADTIME: часы расходятся больше допустимого (по умолчанию 300 секунд). Сравните имя ключа, алгоритм и секрет на обоих серверах побайтно и проверьте NTP.
Сервер не поддерживает версию EDNS из запроса. Все реальные клиенты используют EDNS версии 0, поэтому BADVERS обычно означает неисправный сервер или промежуточное устройство, а не настоящее несовпадение версий. Проверьте dig +edns=0 example.com @server; если и это падает, сервер неправильно обрабатывает EDNS.
Оператор резолвера отказался разрешать имя, потому что оно в блок-листе: фильтрация вредоносных, фишинговых или рекламных доменов на Quad9, AdGuard или корпоративном DNS-файрволе. Ответ часто NXDOMAIN или адрес-«заглушка». Проверьте репутацию домена и при ложном срабатывании попросите оператора резолвера исключить его.
Резолвер возвращает ранее закэшированную ошибку вместо новой попытки. Типично после кратковременного сбоя авторитативных серверов: проблема устранена, но некоторые резолверы ещё несколько минут отвечают SERVFAIL. Убедитесь, что авторитативные серверы уже отвечают, затем подождите или сбросьте кэш резолвера.
Выводится nslookup в Windows при запуске, ещё до вашего запроса. nslookup ищет PTR-запись для IP своего DNS-сервера, а такого обратного имени нет — обычно у роутера 192.168.x.1. Это косметика: запрос ниже всё равно выполняется. Чтобы убрать сообщение, добавьте PTR-запись для адреса сервера в локальном DNS.
Резолвер не отдаёт ответ из-за внешнего требования — решения суда или национального реестра блокировок, а не собственной политики оператора (это Blocked) и не выбора пользователя (Filtered). Другой резолвер обычно возвращает настоящий ответ — с учётом местного законодательства.
dig не получил вообще никакого ответа ни от одного сервера (новые версии пишут communications error to … timed out). Это не ответ DNS, а сетевой сбой: сервер не работает, порт 53 UDP/TCP закрыт или адрес неверен. Попробуйте dig @1.1.1.1, чтобы исключить локальный резолвер, проверьте путь через Traceroute и порт 53 через проверку порта.
curl: (6) Could not resolve host: example.com значит, что системный резолвер не вернул адрес: NXDOMAIN, нет записи A/AAAA или DNS-сервер недоступен. Запустите dig example.com, чтобы понять, что именно. В контейнерах проверьте /etc/resolv.conf внутри контейнера: резолвер хоста вроде 127.0.0.53 оттуда недоступен.
nslookup ждал (по умолчанию 2 секунды) и не получил ответа от DNS-сервера. Один таймаут, за которым пришёл ответ, — просто медленный канал или потери; повторяющиеся таймауты значат, что сервер недоступен, перегружен или закрыт файрволом. Попробуйте другой сервер: nslookup example.com 1.1.1.1, и увеличьте ожидание nslookup -timeout=10, чтобы отличить «медленно» от «мёртв».
Windows переводит коды ответа DNS в номера ошибок: 9001 FORMAT_ERROR (FORMERR), 9002 SERVER_FAILURE (SERVFAIL), 9003 NAME_ERROR (NXDOMAIN), 9004 NOT_IMPLEMENTED (NOTIMP), 9005 REFUSED. 9501 DNS_INFO_NO_RECORDS — это NODATA: имя есть, но записи такого типа нет. Resolve-DnsName показывает 9003 как «DNS name does not exist». Смотрите соответствующую запись в списке; локальный кэш сбрасывается командой ipconfig /flushdns.
Chrome вообще не смог связаться с настроенным DNS-сервером — в отличие от случая, когда пришёл отрицательный ответ. Обычные причины: адрес DNS-сервера, которого больше нет (старый роутер, удалённый VPN), перехват DNS VPN-клиентом или антивирусом, сломанная настройка DNS-over-HTTPS. Проверьте DNS-серверы адаптера, отключите VPN или фильтрующее ПО для теста и выполните ipconfig /flushdns.
DNS-проверка Chrome не прошла, и он вообще не нашёл рабочего подключения к сети. Сначала проверьте связь (Wi-Fi, кабель, страница авторизации в сети, роутер), а не настройки DNS. Если другие приложения работают, файрвол или VPN могут блокировать именно Chrome.
Chrome получил ответ NXDOMAIN: резолвер сообщает, что имени не существует. Сначала проверьте написание. Если домен ваш: зарегистрирован ли он, не истёк ли и нет ли статуса clientHold (см. WHOIS), совпадают ли NS у регистратора с серверами, где лежит зона (DNS Lookup, тип NS), не создана ли запись только что (негативное кэширование, см. NXDOMAIN)? Собственный кэш Chrome очищается в chrome://net-internals/#dns.
В родительской зоне есть DS-запись, но ни один DNSKEY в зоне ей не соответствует, поэтому цепочка доверия рвётся и валидирующие резолверы отвечают SERVFAIL. Классические причины: переезд к другому DNS-провайдеру без удаления старой DS или ротация ключей, при которой новую DS опубликовали раньше нового ключа. Сравните DS у родителя и DNSKEY в зоне через DNSSEC Checker; удалите или обновите DS у регистратора.
Проверка DNSSEC не пройдена: подписи есть, но не сходятся с цепочкой доверия. Валидирующие резолверы (Google, Cloudflare, Quad9, большинство провайдеров) отвечают SERVFAIL, а невалидирующие продолжают отвечать, поэтому домен работает в одних сетях и не работает в других. Ищите более точный EDE (Signature Expired, DNSKEY Missing, RRSIGs Missing) и запустите DNSSEC Checker.
Резолвер не смог определить, безопасен ли ответ, небезопасен или поддельный — например, не смог получить нужный DNSKEY или DS. Часто это следствие недоступного или медленного авторитативного сервера, а не ошибки подписи. Проверьте, что все NS отвечают на запросы DNSKEY, в том числе по TCP для больших ответов.
«DSO-TYPE not implemented»: ответ на запрос DNS Stateful Operations (RFC 8490, используется в долгоживущих сессиях TCP/TLS), тип которого сервер не знает. В обычных запросах не встречается; важен только при разработке ПО на DSO, например DNS push-уведомлений.
Браузер не смог превратить имя хоста в IP-адрес. Это общий вариант ошибок DNS_PROBE_FINISHED_*: имени нет, нет записи A/AAAA или сбой резолвера. Проверьте имя через DNS Lookup; если там оно разрешается, а в браузере нет, сбросьте кэш ОС и chrome://net-internals/#dns и проверьте настройку «Безопасный DNS» в браузере.
Имя отфильтровано, потому что фильтрацию запросил сам клиент: семейный или блокирующий рекламу профиль резолвера, выбранный пользователем или администратором сети (например, семейный фильтр CleanBrowsing, профили NextDNS). Если блокировка ошибочна, смените профиль или резолвер.
Резолвер намеренно вернул ответ, отличный от настоящего, по своей политике: адрес-«заглушку» для вредоносного домена, страницу «огороженного сада» или авторизации в сети. Если это происходит с обычным именем, сравните с другим резолвером и выясните у оператора, почему имя переписывается.
«Ошибка формата»: сервер не смог разобрать запрос. Сегодня это почти всегда сломанная обработка EDNS: старый сервер, балансировщик или файрвол, который не переваривает OPT-запись, неизвестную опцию EDNS или большой размер UDP. После DNS Flag Day 2019 крупные резолверы больше не повторяют запрос без EDNS, и такие домены просто не работают. Проверьте авторитативный сервер: dig +norec example.com @ns1.example.com и то же с +noedns; если падает только запрос с EDNS, обновите или перенастройте сервер или промежуточное устройство.
dns.lookup() в Node (его используют http, fetch и большинство клиентов) обращается к системному резолверу. ENOTFOUND — имя не разрешается: NXDOMAIN или нет записи A/AAAA. EAI_AGAIN — временный сбой: DNS-сервер не ответил вовремя или вернул SERVFAIL; повтор может помочь. В Docker или Kubernetes сначала проверьте /etc/resolv.conf контейнера и DNS кластера, а потом сам домен.
Авторитативный сервер вернул данные, которые резолвер считает некорректными или непригодными: например, испорченную запись или ответ, противоречащий делегированию. Опросите каждый NS напрямую и сравните ответы: обычная причина — один сервер с испорченной копией зоны.
Текст ошибки EAI_NONAME из C-библиотеки Linux, который выводят ping, ssh, wget и другие: у имени нет адреса. Либо NXDOMAIN, либо нет записи A/AAAA, либо имени нет в /etc/hosts и DNS не настроен. Проверьте getent hosts example.com (тот же путь, что у приложений) и dig example.com (только DNS); разница указывает на /etc/nsswitch.conf или /etc/hosts.
Резолвер столкнулся с неустранимой сетевой ошибкой при обращении к другому серверу — например, ICMP unreachable или отказ TCP-соединения. Указывает на маршрутизацию или файрвол перед NS. Проверьте путь до каждого IP NS через Traceroute.
Резолвер не получил пригодного ответа ни от одного авторитативного сервера зоны: все не ответили, отказали или недоступны. Вам он вернёт SERVFAIL. Проверьте, что каждый NS, указанный у родителя, отвечает за зону (lame delegation после смены провайдера — частый случай), что порты 53 UDP и TCP открыты и что серверы не ограничивают запросы резолвера.
У DNSKEY, на который ссылается DS, не установлен флаг Zone Key (у флагов 256 и 257 он есть, у 0 — нет), поэтому ключ не может подтверждать зону. Обычно это ключ, собранный вручную или конвертированный с неверными флагами. Сгенерируйте ключ заново своим DNS-ПО и опубликуйте соответствующую DS.
Отдельного кода нет: статус NOERROR, но секция ответа пуста. Имя существует, просто без записи запрошенного типа — например, у домена есть A, но нет MX. Это сильно отличается от NXDOMAIN (имени нет вовсе). Часто встречается при отладке почты: без MX отправители используют A-запись. Проверьте каждый тип через DNS Lookup.
Запрос выполнен успешно. Это не значит, что запись получена: смотрите секцию ответа — если она пуста, это NODATA. Если NOERROR пришёл с неверными данными, смотрите на кэширование (DNS Propagation) или на то, какой NS ответил.
Формулировка NXDOMAIN в nslookup для Windows: *** dns.server can't find example.com: Non-existent domain. Значение и проверки те же, что у NXDOMAIN. Если сообщение появляется только при запуске, до вашего запроса, см. «Can't find server name for address».
Опрошенный сервер не авторитативен для зоны и не выполняет рекурсию, поэтому ответить не может. Обычно вы спросили чисто авторитативный сервер о чужом домене, либо родитель делегирует зону серверу, который её больше не обслуживает (lame delegation). Направьте клиентов на рекурсивный резолвер или исправьте NS-записи.
Сервер ещё не готов отвечать: запускается, загружает зоны или наполняет кэш. Должно пройти за секунды или минуты. Если не проходит, ищите в логах сервера зону, которая не загружается.
Сервер не поддерживает запрошенную операцию или тип запроса — например, запросы ANY на серверах, которые их ограничивают (RFC 8482), или трансфер/обновление на сервере, где они запрещены. Запрашивайте конкретный тип записи вместо ANY.
Два значения в зависимости от контекста. В динамическом обновлении DNS UPDATE (RFC 2136): сервер не авторитативен для зоны из обновления — отправляйте его на primary. С TSIG (RFC 8945): запрос не авторизован, обычно из-за отсутствующего или неверного ключа TSIG при трансфере или обновлении. Проверьте allow-transfer / allow-update и ключ на обеих сторонах.
«Не реализовано»: сервер не поддерживает такой тип запроса (opcode) — например, NOTIFY, UPDATE или IXFR, отправленные серверу или устройству, которое отвечает только на обычные запросы. Иногда его возвращают сломанные промежуточные устройства на запросы с EDNS. Проверьте тип запроса и должен ли этот сервер его обрабатывать.
В динамическом обновлении UPDATE: имя из обновления не входит в обновляемую зону. Обычно клиент прислал записи для host.other.example в зону example.com. Исправьте имена зоны или записей в обновлении.
Ответ утверждает, что имени или типа нет, но не содержит доказательства NSEC/NSEC3, поэтому валидирующий резолвер не может доверять отрицанию. Обычно это подписывающее ПО или сервер, отбрасывающий NSEC, либо частично подписанная зона. Переподпишите зону и проверьте её в DNSSEC Checker.
«Несуществующий домен»: авторитативный сервер ответил, что имени нет. Для своего домена проверьте: запись действительно опубликована в той зоне, которая обслуживается; имя написано точно (нет двойного www.www); NS у регистратора совпадают с вашим DNS-хостингом; домен не истёк и не заблокирован (WHOIS). Только что созданное имя может оставаться NXDOMAIN в кэшах на время минимального TTL из SOA (негативное кэширование). Подробный разбор: статья про NXDOMAIN, SERVFAIL, REFUSED.
В динамическом обновлении UPDATE: предусловие требовало, чтобы набор записей существовал, а его нет. Обновление отклоняется целиком. Часто встречается у ACME/Let's Encrypt DNS-клиентов или обновлений от DHCP, которые ожидают старую запись. Проверьте текущее содержимое зоны перед обновлением.
Общая категория: у резолвера есть объяснение, не подходящее ни под один определённый код, и он кладёт его в текстовую часть EDE — например, EDE: 0 (Other): (…) в выводе dig. Прочитайте этот текст: обычно в нём названа настоящая проблема.
Резолвер отказывается вас обслуживать: вашего адреса нет в его списке доступа. Типично при использовании резолвера компании или провайдера извне его сети или резолвера, обслуживающего только своих клиентов. Используйте резолвер, который выдаёт ваша сеть, или публичный.
Сервер понял запрос и отказался отвечать по своей политике. Если это рекурсивный резолвер — вас нет в списке разрешённых клиентов. Если авторитативный сервер — он не обслуживает эту зону (часто остаток NS-записи после смены провайдера) или отклоняет тип запроса, например трансфер зоны. Убедитесь, что каждый NS у регистратора действительно обслуживает зону: опросите каждый dig +norec example.com @nsX. Подробнее: статья про NXDOMAIN, SERVFAIL, REFUSED.
Зона подписана (DS у родителя, DNSKEY есть), но ответ пришёл без подписей, поэтому проверка не проходит. Типичные причины: вторичный NS отдаёт неподписанную копию зоны или балансировщик либо DNS-прокси вырезает RRSIG. Опросите каждый NS с dig +dnssec и сравните.
Так nslookup сообщает о неудачном запросе, после двоеточия — причина: ** server can't find example.com: NXDOMAIN (имени нет), : SERVFAIL (сбой резолвера), : REFUSED (сервер отказал), : NXDOMAIN для IP — нет PTR-записи. Смотрите соответствующую запись. В Windows NXDOMAIN звучит как «Non-existent domain».
Резолвер пытался, но не смог получить ответ. Это не утверждение, что имени нет. Обычные причины по частоте: ошибка проверки DNSSEC (в невалидирующих сетях работает, на Google/Cloudflare/Quad9 — нет; проверьте DNSSEC Checker), ни один NS не отвечает, lame delegation или истёкшая зона на вторичном сервере. Ищите рядом код EDE — он часто называет причину. Затем опросите авторитативные серверы напрямую. Подробный разбор: статья про NXDOMAIN, SERVFAIL, REFUSED.
Срок действия RRSIG истёк. Подписи периодически пересоздаются подписывающим ПО; если подпись остановилась (cron, служба или автоматизация провайдера сломались), зона работает ещё несколько дней, а затем перестаёт работать везде, где включена проверка. Переподпишите зону и почините автоматизацию; даты истечения покажет DNSSEC Checker.
Время начала действия RRSIG, с точки зрения резолвера, ещё не наступило. Обычно часы подписывающего сервера спешат или часы резолвера отстают. Проверьте NTP на подписывающем сервере; подписывающее ПО обычно сдвигает начало действия на час назад, чтобы поглотить небольшие расхождения.
Резолвер не смог обновить запись с авторитативных серверов и отдал просроченную копию из кэша (serve-stale, RFC 8767). Ответ вы получили, но у авторитативной стороны проблемы. Проверьте, что NS отвечают, пока окно serve-stale не закончилось — обычно от одного до трёх дней.
Как Stale Answer, но в кэше был отрицательный ответ: резолвер не достучался до авторитативных серверов и повторил просроченный NXDOMAIN. Если вы только что создали имя, исправлять нужно на авторитативной стороне: резолвер не увидит новую запись, пока не сможет связаться с серверами.
Текст ошибки EAI_AGAIN из C-библиотеки Linux: резолвер не дал определённого ответа. DNS-сервер не ответил, вернул SERVFAIL или вообще не настроен. Это не то же, что «Name or service not known» (определённое «нет»). Проверьте /etc/resolv.conf; с systemd-resolved выполните resolvectl status и resolvectl query example.com. На серверах это часто файрвол, закрывающий исходящий порт 53, или неработающий DNS-сервер.
Определена для DNS over QUIC (RFC 9250): сервер не обрабатывает запрос, отправленный в данных 0-RTT, потому что их можно воспроизвести повторно. Клиент должен отправить запрос заново после завершения рукопожатия. Важно только для разработчиков и операторов DoQ.
В UDP-ответе установлен флаг TC (усечено), потому что он не поместился, и dig повторил запрос по TCP. Нормально для больших ответов: ключей DNSSEC, длинных TXT/SPF, множества A-записей. Проблема только если повтор по TCP не удался: порт 53 TCP должен быть открыт на всех авторитативных серверах (RFC 7766). Проверьте dig +tcp example.com @ns1.example.com.
Зона подписана алгоритмом, который резолвер не поддерживает или отключил, поэтому зона считается неподписанной (защиты нет, но ответ отдаётся). Встречается с RSA/MD5, DSA и всё чаще с RSA/SHA-1 (алгоритмы 5 и 7), от которых постепенно отказываются для подписи. Переподпишите зону ECDSA P-256 (13) или Ed25519 (15); NODA отмечает запрещённые алгоритмы.
DS-запись у родителя использует тип дайджеста, который резолвер не поддерживает, — обычно SHA-1 (тип 1) или ГОСТ (тип 3). Если другой пригодной DS нет, зона считается неподписанной. Опубликуйте у регистратора DS с SHA-256 (тип 2) и удалите старую.
В параметрах NSEC3 зоны больше итераций хэширования, чем принимает резолвер (RFC 9276). В зависимости от резолвера зона считается небезопасной или ответы превращаются в SERVFAIL. Установите 0 итераций NSEC3 и пустую соль, как рекомендует RFC 9276; текущее значение покажет dig NSEC3PARAM example.com.
Вы спросили сервер, который не выполняет рекурсию, — обычно авторитативный NS. Безвредно, если вы и хотели спросить его напрямую: ответ для его собственных зон корректен. Если вы ждали полного ответа для любого домена, вы обращаетесь не к тому серверу — используйте рекурсивный резолвер. Чтобы убрать предупреждение, добавьте +norec.
«Имя существует, хотя не должно». В динамическом обновлении UPDATE предусловие требовало отсутствия имени, а оно есть. Также возвращается, когда подстановка DNAME дала бы имя длиннее 255 байт (RFC 6672). Для обновлений проверьте текущее состояние зоны; для DNAME сократите цель.
В динамическом обновлении UPDATE: предусловие требовало, чтобы набора записей не было, а он есть. Обновление отклоняется целиком. Часто бывает, когда два клиента одновременно создают одну и ту же запись. Сначала прочитайте текущую запись, затем обновляйте.
Источники: RFC 1035 (RCODE 0–5), RFC 2136 (6–10), RFC 8490 (11), RFC 6891 и RFC 8945 (16–22), RFC 7873 (23), RFC 8914 (EDE 0–24), RFC 9250 (EDE 26), RFC 9276 (EDE 27), реестр IANA DNS Parameters. Проверить домен целиком можно в NODA.
