NXDOMAIN через VPN не означает сбой туннеля

Соблазнительно прочитать один неудачный запрос как доказательство того, что туннель рухнул, особенно если имя работало десять минут назад. Ответ говорит об ином. NXDOMAIN — завершённая транзакция DNS, в которой резолвер заявил, что запрошенное имя не существует; сломанный туннель обычно даёт тишину, тайм-аут или попытку разрешения через неверный сервер. Версия аргумента без wireshark — это один запрос, один ответчик и один код ответа, и эту тройку стоит зафиксировать до любых изменений конфигурации.

Что на самом деле доказывает ответ

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

Эта разница решает, где надлежит исправление. Отсутствующая запись AAAA на хосте, у которого есть запись A, не означает отсутствующего хоста, а перевыпуск сертификата или перестройка туннеля в погоне за этим тратит единственную доступную подсказку. Различие также задаёт форму дальнейших действий: проблема имени исправляется в зоне, а проблема типа исправляется запросом правильной записи или признанием того, что семейство адресов просто отсутствует.

Миф: отсутствующее приватное имя означает, что туннель не сработал

Миф живёт потому, что эти два события так часто приходят вместе. Клиент подключается к VPN, операционная система сохраняет резолвер, которому уже доверяла, и внутреннее имя, которое теперь нужно, запрашивается у сервера, никогда не слышавшего о приватной зоне. Этот сервер отвечает честно и отрицательно. Туннель несёт пакет; ответ просто о пространстве имён, которое ответчик не обслуживает.

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

Результат определяют две детали конфигурации. Туннель должен протолкнуть или выбрать внутренний резолвер, и клиент должен применить этот выбор к искомому имени. Правило для отдельного домена, которое называет суффикс, немного отличающийся от введённой записи, отправит запрос по публичному пути, и ответ будет верным и бесполезным.

Спрашивайте правильный резолвер с правильным именем

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

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

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

Отрицательное кэширование объясняет задержку после исправления

Отрицательные ответы кэшируются по замыслу, и RFC 2308 описывает, как время жизни отрицательного кэша выводится из записи полномочий зоны. Поэтому исправление записи или правила резолвера не гарантирует немедленного изменения на клиенте, а повтор запроса, который по-прежнему возвращает кэшированный ответ, ничего нового не доказывает. Только другой ответчик, другое имя или очищенный кэш дают свежие доказательства.

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

Отделите имя от пути

Как только имя разрешается в ожидаемый приватный адрес, DNS как тема закончен, и следующим вопросом становится путь приложения. Хост, который отвечает на запросы, но отказывает в соединении, имеет другую проблему, и продолжать настраивать резолверы после правильного ответа — это способ, которым инцидент обзаводится тремя несвязанными изменениями. Сравните разрешённый адрес с тем, на котором служба действительно слушает, прежде чем считать, что они совпадают.

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