NXDOMAIN, SERVFAIL, REFUSED: что на самом деле означает ваша ошибка DNS

Три слова, которые появляются, когда ломается DNS, и их почти никто не читает правильно. К ним относятся как к взаимозаменяемым способам сказать «DNS сломан» — что жаль, потому что каждое из них говорит вам довольно конкретную вещь о том, кто провалился и где. При правильном прочтении код ошибки сам по себе обычно сужает проблему до одной из примерно трёх вещей ещё до того, как вы тронули хоть один конфигурационный файл.

Вот что каждый из них на самом деле означает, и как действовать в ответ.

Сначала: получите настоящую ошибку, а не перевод от вашего провайдера

Большинство людей сталкивается с ошибками DNS через посредника — браузер, говорящий «сервер не найден», ping, говорящий «неизвестный хост», панель мониторинга, говорящая «сбой DNS». Всё это сплющивает три совершенно разных режима отказа в одно сообщение, что и есть причина, по которой отладка DNS имеет репутацию загадочной.

Запросите DNS напрямую, и он скажет вам прямо. Любой инструмент запроса, показывающий сырой ответ — включая DNS-запрос MarinaDNS — покажет статус ответа дословно, что и есть реальная отправная точка любого расследования DNS. То, что вы ищете — поле status: в заголовке ответа. Это единственное слово — вся диагностика.

NXDOMAIN: имя действительно не существует

NXDOMAIN — сокращение от «несуществующий домен». Это означает, что авторитетный сервер для этой зоны — сервер, являющийся реальным источником истины для домена — был спрошен об этом имени и сказал, определённо: «здесь такого имени нет».

Ключевое слово — авторитетный. Это не догадка и не таймаут. Что-то, что реально знает ответ, сказало вам, что имени не существует. Если вы получаете NXDOMAIN для имени, которое, как вы уверены, создали, верно одно из следующего:

Запись на самом деле никогда не была опубликована. Вы добавили её в панели управления, но она не сохранилась, или сохранилась в зону, которая не обслуживается. Удивительно распространено у провайдеров, поддерживающих отдельное состояние «ожидающие изменения».

Вы запрашиваете имя, которое тонко отличается от того, что вы создали. Завершающая точка, случайный дублирующийся поддомен (www.www.yourdomain.com), или запись, созданная как @, когда вы имели в виду www. DNS беспощаден к этому и не будет угадывать, что вы имели в виду.

Делегирование сломано выше вашей зоны. Это интересный случай. Если NS-записи родительской зоны не указывают на серверы, реально обслуживающие вашу зону, резолверы вообще никогда не достигают ваших записей — а ответ, который они получают от того, кого на самом деле спрашивают, — NXDOMAIN. Ваши записи существуют, идеально настроенные, на сервере, который никому не поручено спрашивать.

Она закэширована негативно, и вы видите старый ответ. Это постоянно всех сбивает с толку. Согласно RFC 2308, когда резолвер получает NXDOMAIN, он кэширует этот негативный ответ, и длительность кэширования берётся из SOA-записи зоны — конкретно из поля minimum, или собственного TTL SOA, смотря что меньше. Если ваш SOA minimum установлен на 24 часа (значение по умолчанию у некоторых провайдеров), имя, которого вчера не существовало, будет продолжать возвращать NXDOMAIN из кэша целый день после того, как вы его создадите. Ничего не сломано. Вы просто читаете память.

Последнее стоит усвоить, потому что это самая распространённая причина «я добавил запись, но она не работает». Запись в порядке. Какой-то резолвер где-то помнит, что ему сказали, что имени не существует, и ему ещё не пора об этом забыть. Проверка того же имени через несколько резолверов в разных сетях немедленно это покажет — у одних будет новая запись, другие всё ещё обслуживают закэшированный негативный ответ, и это расхождение говорит вам, что это артефакт кэширования, а не ошибка конфигурации.

NXDOMAIN против NODATA — не одно и то же

Стоит короткого отступления, потому что их путают, а разница имеет значение. NXDOMAIN означает имя вообще не существует. Но если имя существует и просто не имеет записи запрошенного типа, вы получаете NOERROR с пустым разделом ответа — неформально называемым NODATA.

Конкретно: если у yourdomain.com есть A-запись, но нет MX-записи, запрос его MX вернёт NOERROR с ничем в ответе. Запрос nonexistent.yourdomain.com вернёт NXDOMAIN. Первое говорит «это имя реально, просто не для этой цели». Второе говорит «это имя не реально». Инструменты, которые сообщают только «результат не найден», скрывают это различие, и часто это весь ответ — особенно при отладке маршрутизации почты, где отсутствующий MX и несуществующее имя хоста производят очень разное последующее поведение.

SERVFAIL: резолвер сдался

SERVFAIL — самый неправильно понимаемый из трёх, потому что звучит так, будто он говорит вам, что сервер провалился — и это отчасти так, но не так, как люди предполагают. SERVFAIL — не авторитетный ответ. Никто с полномочиями ничего не сказал. Это резолвер, говорящий вам, что он попытался найти ответ и не смог завершить процесс.

Это значимо иное заявление, чем NXDOMAIN. NXDOMAIN — это знание. SERVFAIL — это отсутствие знания, обёрнутое в код ошибки.

Причины, примерно в порядке того, как часто они реальный виновник:

Сбой проверки DNSSEC. Это большая проблема, и она недодиагностируется, потому что ошибка не даёт никакого намёка на то, что задействован DNSSEC. Если зона подписана, а подпись истекла, или DS-запись у родителя не совпадает с DNSKEY в зоне, или цепочка доверия сломана в любом звене, проверяющий резолвер откажется обслуживать ответ — даже если ответ существует и лежит прямо там. Он возвращает SERVFAIL, потому что с точки зрения безопасности непроверяемый ответ — это отсутствие ответа.

Раздражающая часть: резолверы, не проверяющие DNSSEC, с радостью вернут запись. Так что домен работает из одних сетей и возвращает SERVFAIL из других, и разница не коррелирует ни с чем очевидным снаружи. Если вы видите SERVFAIL из одних мест и чистые ответы из других, проверьте цепочку DNSSEC, прежде чем трогать что-либо ещё — истёкшие подписи — самая распространённая причина именно такого паттерна, и они истекают по расписанию, следит за этим кто-то или нет.

Никто не ответил. Резолвер попытался обратиться к авторитетным серверам, перечисленным для зоны, и ни один из них не ответил — недоступны, за файрволом, или зона никогда не была загружена. После истечения повторных попыток это SERVFAIL.

Хромое делегирование (lame delegation). Родительская зона указывает на серверы имён, которые отвечают, но эти серверы на самом деле не настроены обслуживать эту зону — они отвечают, но не авторитетно. Резолвер получает ответ, который не продвигает его к ответу, пробует другие, и в итоге проваливается. Часто встречается после миграции провайдеров и оставления одной старой NS-записи.

Зона истекла на вторичном. Зональные трансферы перестали работать, у вторичного истёк таймер expire, и теперь он правильно отказывается обслуживать устаревшие данные.

Действие для отладки SERVFAIL всегда одно и то же: перестаньте спрашивать свой резолвер и начните спрашивать напрямую авторитетные серверы. Если авторитетный сервер отвечает чисто, а ваш резолвер возвращает SERVFAIL, запись в порядке, а проблема в пути — проверка, делегирование или доступность. Если авторитетный сервер тоже проваливается, вы нашли, где она живёт. Трассировка маршрута к IP сервера имён стоит запустить, если вы подозреваете доступность, а не конфигурацию — она покажет вам, доходят ли пакеты вообще, что отличает проблему сетевого уровня от проблемы уровня DNS.

REFUSED: вы спрашиваете не тот сервер, или вам не разрешено

REFUSED — это ответ политики, и это самый прямолинейный из трёх. Сервер получил ваш запрос, полностью его понял и отклонил. Не «не смог ответить» — не захотел.

Три реалистичные причины:

Вы спрашиваете сервер о зоне, которую он не обслуживает, и он не будет рекурсировать для вас. Авторитетные серверы имён обычно отвечают только за свои собственные зоны. Спросите один о чужом домене, и он правильно откажет. Если вы где-то захардкодили сервер имён, а зона переехала, вот что вы увидите.

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

Ограничение скорости или блокировка. Некоторые резолверы возвращают REFUSED вместо отбрасывания трафика, когда источник запрашивает слишком агрессивно. Стоит знать, если вы запускаете автоматические проверки.

Исправление почти всегда одно и то же: вы указываете не на тот сервер. Укажите на авторитетный сервер для зоны, или на резолвер, который реально будет обслуживать ваш исходный адрес.

Короткая версия

Вывод, который стоит унести с собой: NXDOMAIN и NODATA — это ответы. SERVFAIL и REFUSED — нет. Первые два означают, что система сработала, и вы получили истину, даже если истина нежеланна. Вторые два означают, что вы вообще никогда не достигли истины — и исправление живёт где-то в пути между вами и ней, а не в самих записях.

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