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

Симптом меняется вместе с резолвером

Рекурсивный резолвер возвращает то, что ему сказал авторитетный источник, а затем хранит этот ответ в течение TTL. Если туннель навязывает другой резолвер или меняет путь так, что старый больше недоступен, клиент спрашивает другой авторитетный источник и получает другой ответ. Домен в этот момент не изменился; изменилось ваше представление о нём.

Поэтому одно и то же имя может работать в одном офисе и не работать из отеля, и поэтому очистка локального кэша помогает только иногда. Очистка кэша снова отправляет вопрос тому же авторитетному источнику.

Различающий тест — прямой запрос к каждому опубликованному серверу.

Спрашивайте каждый авторитетный источник напрямую

Начинайте с делегирования, а не со списка, который помните. Спросите у родителя набор NS, затем запросите каждое имя из этого набора на нужную вам запись. Два запроса об одном имени к разным авторитетным источникам сразу показывают, согласована ли зона.

dig +short NS example.com
dig @ns1.dns.example app.example.com A
dig @ns2.dns.example app.example.com A

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

Выполняйте эти запросы из сети, которая не работает, а не только со своего рабочего стола.

Отделите намеренные представления от сломанных

Некоторые домены намеренно отвечают по-разному в зависимости от региона или группы резолверов, и конфигурации с разделённым горизонтом обычны в корпоративных сетях.

Вопрос в том, задокументировано ли различие и стабильно ли оно. Непреднамеренное представление выглядит иначе: у одного авторитетного источника есть запись, которую остальные никогда не получали, или отсутствует та, которую разделяют все. Руководство RFC 2182 по выбору и развёртыванию рассматривает авторитетную доступность как общую ответственность, и это правильная рамка здесь. Резервирование существует только если каждый опубликованный сервер может ответить намеченными данными, а не просто принять соединение на порту 53.

Сервер, отвечающий SERVFAIL, диагностировать легче, чем тот, который отвечает уверенно и неправильно.

Миграция раскрывает то, что скрывал кэш

При смене провайдера меняются два авторитетных места: делегирование родителя и собственные записи NS зоны. Оба нужно обновить, и оба кэшируются на время своих TTL. Если старый сервер остаётся включённым и продолжает обслуживать прежнюю зону, клиенты, чьи резолверы спрашивают его, будут получать старый ответ ещё долго после того, как переключение выглядело завершённым.

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

Смена резолвера на ноутбуке исправляет этот ноутбук и ничего больше.

Исправьте зону, а не резолвер

Определите, какие серверы должны быть авторитетными для зоны, исправьте управляемую зону или делегирование так, чтобы каждый из них отдавал намеченные данные, и сохраните запланированное резервирование. Удаление сервера имён из-за того, что один выход VPN получил странный ответ, снижает доступность и оставляет несогласованность на месте.

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

Убедитесь, что ответ стабилен от каждого авторитетного источника, и запишите намеченное представление в документацию зоны, чтобы следующее различие было легко классифицировать.

Похожие статьи