Как я проверяю DNS‑цепочку сервиса и не путаю ответ резолвера с доступностью приложения

От жалобы к карте DNS-пути

В одном из внедрений IT Fresh я разбирал ситуацию, когда имя сервиса у части точек разрешалось ожидаемо, а наблюдение из другого сегмента давало иной результат. Идентификаторы заказчика, зоны, узлов и адреса здесь обезличены, но порядок действий сохранён. Я начал не с редактирования записи, а с карты пути: клиент, назначенный ему recursive-резолвер, возможный forwarder, корневое делегирование, authoritative-серверы зоны и точка, где реально выполнялся item. Для каждой точки записал, какой вопрос был задан, какой сервер ответил, были ли recursion available и authoritative answer, какой TTL остался. Эта карта сразу отделила три разных утверждения: зона публикует данные, резолвер возвращает данные, приложение принимает соединение. Ответ A или AAAA доказывает только первое или второе в конкретном контексте. Поэтому исходным свидетельством стали не снимки одного nslookup, а сопоставимые ответы с рабочих мест, Windows DNS и Zabbix proxy. Имена в журнале работ я маскировал, сохраняя тип записи, код ответа и направление запроса. Дополнительно отмечал семейство адреса и фактический сервер, выбранный клиентом: наличие корректного A не исключает сбой пути к AAAA, а список настроенных DNS-серверов не показывает, кто ответил на конкретный запрос. Эта детализация пригодилась при сравнении повторов и не требовала вмешательства в клиентские настройки.

Делегирование до содержимого зоны

Публичную ветвь я прошёл от родительской зоны к NS delegation, а затем запросил каждый authoritative-сервер напрямую без рекурсии. Проверил, что перечисленные NS отвечают за нужную зону, а glue-записи присутствуют и согласованы, когда имена серверов требуют их для разрыва циклической зависимости. После этого сравнил SOA: primary name server, ответственный контакт, timers и особенно serial на всех авторитетных узлах. Разный serial объясняет, почему два формально правильных NS отдают неодинаковые данные, но сам по себе одинаковый serial ещё не проверяет каждую запись. Я отдельно раскрыл CNAME до конечных A и AAAA, следя за отсутствием петли и неожиданного перехода в чужую зону. Там, где зона подписана, проверил цепочку DNSSEC и различал корректный unsigned-ответ, validated-ответ и SERVFAIL при ошибке валидации. Такой проход не зависит от кеша корпоративного резолвера и показывает опубликованное состояние. Он также обнаруживает ошибку делегирования, которую бессмысленно лечить очисткой локального cache. Любую внутреннюю split-horizon-зону я из этого публичного вывода исключаю: у неё другая область видимости и свои authoritative-серверы.

Кеш как часть наблюдаемого состояния

Затем я повторил запрос через те recursive-резолверы, которыми действительно пользуются проверяемые сегменты. Для положительного ответа фиксировал исходный TTL зоны и оставшийся TTL в cache; для NXDOMAIN учитывал negative caching по SOA, а не ожидал мгновенного исчезновения ошибки после исправления записи. Negative cache важен и в обратную сторону: прежний NXDOMAIN способен жить у одного резолвера, пока другой уже получает существующее имя. Я не очищал кеш всей службы как диагностический первый шаг, потому что это меняет состояние для посторонних клиентов и уничтожает полезное свидетельство. Вместо этого сравнивал обычный запрос с запросом непосредственно к authoritative-серверу, а при разрешённом тесте использовал отдельное новое имя. Проверил также conditional forwarders и порядок пересылки во внутреннем контуре. При split-horizon одинаковое имя закономерно получает разные ответы внутри и снаружи; ошибкой становится не различие само по себе, а ответ не из той зоны или не для той аудитории. Интервалы наблюдения выбирал по TTL, отрицательному кешированию и критичности конкретной проверки. Фиксированное расписание для всех зон здесь исказило бы и скорость реакции, и нагрузку.

Windows DNS без вмешательства в службу

На стороне Windows DNS я сначала подтвердил, что запрос пришёл именно на ожидаемый сервер и попал в нужную зону либо правило пересылки. В Event Viewer просмотрел доступные события журнала Microsoft-Windows-DNS-Server-Service за ограниченное окно: запуск и остановку службы, загрузку зон, ошибки передачи и признаки проблем с обновлением. Журнал событий не заменял пакетный путь, поэтому доступность порта проверялась с разрешённых точек отдельно для UDP 53 и TCP 53. Обычный короткий ответ часто проходит по UDP, тогда как крупный, усечённый или связанный с DNSSEC ответ требует повторения по TCP; успешный UDP 53 не доказывает работоспособность TCP 53. Для чтения применял Resolve-DnsName с явным сервером и типом записи, а также nslookup для воспроизведения привычного клиентского запроса. Вывод команд сохранял без внутренних имён и адресов. Конфигурацию службы, aging, scavenging, зоны и forwarders на этом этапе не менял. Если запись поддерживалась динамически в AD-integrated зоне, проверял secure dynamic update и права конкретной учётной записи или компьютера, придерживаясь least privilege, а не выдавая управление зоной целиком.

Точка наблюдения Zabbix не равна центру

Ключевым различием оказался источник DNS-запроса. Проверка, назначенная на Zabbix proxy в удалённом сегменте, разрешает имя через настройки операционной системы proxy и доступный ему recursive-резолвер. Ручной запрос на Zabbix server в центре проходит другой resolver path, может видеть другую split-horizon-зону и другой cache. Поэтому я выполнил read-only dig на узле proxy с явными типами A, AAAA, CNAME, NS и SOA, затем сопоставил его с Resolve-DnsName на Windows-клиенте и прямым запросом к authoritative-серверу. Использовал опции, не вносящие изменений: явный server, отключение рекурсии для авторитетной проверки, TCP-режим для контрольного запроса и вывод DNSSEC-флагов там, где подпись применялась. В конфигурации item зафиксировал, кем выполняется проверка, какое имя запрошено, какой тип ожидается и как обрабатываются NXDOMAIN, timeout и SERVFAIL. Секреты, полную конфигурацию proxy и лишние данные зон не экспортировал. Это позволило связать наблюдаемый ответ с фактическим источником, не подменяя его удобной проверкой с административного компьютера.

DNS завершён, проверка сервиса продолжается

После подтверждения DNS-цепочки я отдельно проверил прикладной слой. Синтетический HTTP-запрос выполнялся из той же сетевой перспективы, что и рабочая проверка, с ожидаемым Host, контролем кода ответа и содержимого, которое не раскрывает пользовательские данные. TLS-проверка отдельно сопоставляла имя сертификата, цепочку доверия и срок действия; соединение по одному IP для этого недостаточно, потому что меняет SNI и обходится без обычного разрешения имени. Так я не смешивал успешный DNS-ответ с доступностью приложения. Возможна и обратная картина: HTTP/TLS работает из-за прежнего cache или закреплённого адреса, хотя новое делегирование уже ошибочно. В Zabbix DNS-сигнал и web scenario оставались разными элементами и давали раздельные причины отказа. Частоту синтетических обращений согласовывал с владельцем сервиса и ограничениями конечной точки, не назначая общий интервал всем системам. Для доказательства сохранял код DNS-ответа, выбранный адрес, факт TCP-соединения, результат TLS и ожидаемый HTTP-признак в одной временной линии. Это показывает границу каждого свидетельства, но не превращает единичный успешный запрос в утверждение о постоянной доступности.

Одна управляемая правка зоны

Когда сравнение подтвердило расхождение записи в управляемой зоне, я подготовил одну контролируемую правку. До неё сохранил текущие значения записи, TTL, SOA serial, область репликации зоны, владельца объекта и набор разрешений; отдельно записал ожидаемый ответ внутри и снаружи. Из вариантов я отверг массовую очистку cache, одновременную замену NS и адресов, а также временное отключение DNSSEC: каждый из них затрагивал больше причин, чем проверяемая гипотеза. Для AD-integrated зоны изменение выполнялось штатной учётной записью с минимально достаточными правами, а secure dynamic update оставался включён. После правки проверил увеличение serial, согласованность authoritative-ответов, прохождение репликации в заданном контуре и поведение рекурсивных серверов с учётом TTL. Тест включал UDP 53, контрольный TCP 53, запрос из сегмента Zabbix proxy и отдельные HTTP/TLS-проверки. Критерий остановки был задан заранее: неожиданный ответ другой зоны, ошибка подписи, исчезновение смежной записи или недоступность приложения. Я не ускорял вывод принудительной очисткой всех кешей, поскольку пользователи продолжали бы видеть состояние согласно действующим срокам хранения.

Откат, доказательства и пределы вывода

План возврата был зеркальным и узким: восстановить прежнее значение записи и TTL тем же каналом управления, убедиться в новом SOA serial, дождаться штатного распространения и повторить запросы из тех же точек. Если менялись права объекта, возвращался исходный ACL; отключение secure dynamic update в откат не входило. Для внешней зоны я заранее учитывал, что прежний и новый ответы могут сосуществовать в recursive cache до истечения TTL, а NXDOMAIN — до срока negative cache. В рабочую запись вошли обезличенные выводы dig, nslookup и Resolve-DnsName, события Microsoft-Windows-DNS-Server-Service, ответы каждого NS, результат с proxy и отдельные признаки HTTP/TLS. Этого достаточно, чтобы подтвердить конкретную DNS-причину и эффект одной правки, но недостаточно для вывода о постоянной исправности сети, центра сертификации или кода приложения. Ограничения DNSSEC зависят от реальной схемы подписания и доверия, а split-horizon требует проверки каждой предусмотренной перспективы. Я оставил владельцу зоны короткую последовательность чтения и критерии эскалации, но не зафиксировал универсальные интервалы: их определяют TTL, характер обновления и допустимая задержка обнаружения именно этого сервиса.

Отвергнутые альтернативы

• Проверять имя только через корпоративный recursive-резолверЕго cache способен временно скрыть рассогласование делегирования или уже исправленный ответ, поэтому авторитетную ветвь нужно опрашивать отдельно.
• Считать полученный A или AAAA доказательством доступности сервисаDNS подтверждает разрешение имени, но не устанавливает HTTP-соединение, не проверяет TLS-сертификат и не оценивает ответ приложения.
• Исправить запись сразу после первого NXDOMAINNXDOMAIN может сохраняться в negative cache согласно параметрам зоны; сначала важно определить источник ответа и оставшееся время кеширования.
• Проверять DNS только с Zabbix serverЕсли item выполняется на Zabbix proxy, центральный server использует другой resolver path и не воспроизводит взгляд площадки.
• Разрешить неограниченные динамические обновления ради быстрого исправленияНебезопасные обновления расширяют возможность менять зону; для AD-integrated DNS я сохраняю secure dynamic update и минимальные права.

Конфигурация и сбор

Read-only запросы к разрешённым DNS-серверам и чтение согласованных журналов Windows DNS; просмотр конфигурации item и точки выполнения на Zabbix server/proxy. Изменение зоны допускается только в отдельном контролируемом шаге учётной записью с минимальными правами.

• Зафиксировать resolver path для клиента и Zabbix proxy, включая forwarders и границу split-horizon.
• Собрать dig, nslookup и Resolve-DnsName для NS, SOA, A, AAAA и CNAME; при использовании DNSSEC сохранить признаки валидации без изменения зоны.
• Сравнить authoritative-ответы и recursive cache, записав SOA serial, TTL, NXDOMAIN и параметры negative caching.
• Просмотреть Event Viewer и Microsoft-Windows-DNS-Server-Service за ограниченное окно, затем раздельно проверить UDP 53 и TCP 53.
• Запустить синтетические HTTP/TLS-проверки из нужной точки отдельно от DNS и сохранить различимые результаты.

Контролируемая проверка и свидетельство

В согласованной зоне меняется одна запись с заранее сохранёнными значением, TTL, serial и ACL. После изменения проверяются authoritative-узлы, recursive-резолверы, Windows-клиент, Zabbix proxy, UDP 53, TCP 53 и отдельные HTTP/TLS-сигналы. Тест останавливается при неожиданном ответе другой зоны, DNSSEC-ошибке, повреждении смежной записи или ухудшении доступности приложения.

Фрагмент рабочего регламента

• Определить фактический recursive-резолвер клиента и resolver path Zabbix proxy; не использовать ответ центрального server как замену.
• Пройти NS delegation и glue, запросить каждый authoritative-сервер, сравнить SOA serial и цепочки CNAME, A, AAAA.
• Сопоставить TTL и negative cache для обычного ответа, NXDOMAIN и SERVFAIL; не очищать общий cache до фиксации свидетельств.
• На Windows прочитать Microsoft-Windows-DNS-Server-Service и проверить UDP 53/TCP 53, не меняя службу.
• После DNS отдельно выполнить синтетические TLS и HTTP проверки из той же сетевой перспективы.

Откат

Вернуть сохранённое значение записи и TTL штатным каналом, восстановить исходный ACL, подтвердить новый SOA serial и согласованность authoritative-серверов. Затем повторить запросы из клиентского сегмента и с Zabbix proxy с учётом существующего cache, а HTTP/TLS проверить отдельно. Если исходное состояние не восстанавливается либо затронута смежная запись, дальнейшие изменения прекращаются и вопрос передаётся владельцу зоны.

Ограничения вывода

DNS-ответ не доказывает доступность приложения, а результат одного recursive-резолвера не описывает все точки. На вывод влияют TTL, negative caching, split-horizon, forwarders, репликация, доступность UDP 53 и TCP 53, DNSSEC и локальный resolver path. Без знания владельца зоны и разрешённого окна нельзя безопасно менять записи; универсального интервала DNS- и HTTP-проверок нет.