Кратко

  • На APNIC 62 ISC отнёс список зон, их фильтрацию и поиск расхождений серий к возможностям Stork, доступным сегодня. В презентации не описано ни производственное внедрение у APNIC, ни реальный инцидент с устаревшей зоной.
  • Расхождение относится к тем строкам сервера, представления и конфигурации зоны, которые Stork обнаружил и получил. Чистый список не становится выводом обо всей инфраструктуре без сведений о неудачных запросах, неподдерживаемых представлениях, исключениях и возрасте кэша.
  • Для эксплуатации нужен чек сравнения: версии Stork и DNS-демона, ожидаемый и наблюдаемый охват, статус сбора, исходные значения SOA, время наблюдения, предел свежести и исход для каждой недоступной строки.

Отсутствующая строка не может показать расхождение

Сигнал о несовпадении серий кажется почти самодостаточным. Одна зона видна на двух серверах, значения SOA различаются, подозрительная строка выделена. В презентации Stork на APNIC 62 Marcin Siodelski поместил список и фильтрацию зон, просмотр содержимого и Serial Mismatch Detection в набор нынешних функций DNS. Обзор сессии APNIC описал тот же сигнал между серверами.

Этим сигналом стоит пользоваться. Но у него должен быть знаменатель.

Stork не наблюдает абстрактную «DNS-инфраструктуру». Он видит демоны, которые смогли найти его агенты, конфигурацию и интерфейсы, которые они смогли прочитать, и сведения о зонах, которые сервер Stork попросил получить. Строка, не прошедшая по этой цепочке, не покажет расхождение. Согласие она тоже не покажет.

Первая граница проходит по обнаружению. В документации DNS для Stork 2.4.1 агент находит работающий процесс BIND 9, а затем конфигурацию, с которой он запущен. Если конфигурацию найти не удаётся, демон не появляется в списке обнаруженных. Для перечня зон BIND необходим statistics channel: через него Stork получает настроенные представления и зоны. В PowerDNS используется другой путь — webserver API и параметр конфигурации.

Само по себе ни одно из этих условий не указывает на неисправность. Демон мог намеренно остаться за пределами мониторинга. Запрет агенту читать конфигурацию может быть обоснованной мерой. Интерфейс мог быть отключён по политике. Вывод уже: охват результата равен охвату, который успешно пересёк эти границы, а не всему парку авторитетных серверов организации.

Вторая граница — время. Перечень зон загружается в базу Stork и хранится там как кэшированный снимок. Согласно документации, изначально список пуст, оператор запускает Fetch Zones, а затем он не обновляется автоматически. Чтобы увидеть актуальный состав, запрос нужно повторить. В Fetch Status доступны ошибки, число конфигураций зон, число уникальных зон и число встроенных зон.

Эти числа не взаимозаменяемы. Если одно имя зоны встречается в трёх представлениях, это одна уникальная зона, но три конфигурации. Чек, в котором осталось лишь число имён, теряет две поверхности сравнения. Число конфигураций без числа имён, напротив, не объясняет, появились ли новые зоны или новые представления прежних зон. Рядом с результатом нужны оба показателя и правило подсчёта.

Представления особенно хорошо показывают проблему идентичности. В BIND 9 Stork может связать одно имя зоны с разными представлениями. Для просмотра записей через AXFR неосновному представлению требуется ключ TSIG: только так BIND различает, к какому представлению относится запрос. Подходящий ключ определяется правилами match-clients и allow-transfer. При этом представления PowerDNS 5.0 в Stork 2.4.1 прямо не поддерживаются. Невидимое представление PowerDNS — документированная граница продукта, а не подтверждение совпадения серий.

Не следует смешивать и два канала данных. Список зон вместе с сериями собирается через интеграции с DNS-серверами и кэшируется после Fetch Zones. Содержимое зоны запрашивается по требованию, когда пользователь выбирает Show Zone: для этого применяется AXFR, а до команды Refresh from DNS интерфейс может показывать сохранённую копию. Неудачный AXFR способен помешать просмотру записей, не удалив уже известную серию из перечня. И наоборот, видимая серия не доказывает, что Stork получил все записи. Объединение этих каналов превратило бы наблюдение одного свойства в утверждение о другом.

Такое же разделение требуется для мониторинга переносов. В докладе Siodelski XFR monitoring назван новой возможностью разрабатываемой версии 2.5.1. Руководство агента 2.5.1 уточняет: отслеживание журналов работает только с BIND, по умолчанию отключено, требует явного включения и не видит переносы, записанные только через syslog. Это не та же функция, что сравнение серий в стабильной 2.4.1. На странице Stork ISC называет 2.4.1 стабильным выпуском, а 2.5.1 — разрабатываемым. Поэтому у вывода с панели должна быть версия продукта; нельзя незаметно приписывать ему возможности соседнего выпуска.

Само серийное число тоже требует аккуратных формулировок. RFC 1912 объясняет, зачем вторичный сервер проверяет SOA-серию первичного до запроса обновлённых данных. RFC 1982 задаёт арифметику 32-битных серий: значения переходят через границу диапазона, поэтому обычного числового сравнения недостаточно. Равенство однозначно, но порядок двух разных значений определяется правилами пространства последовательности; пара на расстоянии ровно в половину этого пространства не упорядочена.

Из рассмотренных материалов следует, что Stork обнаруживает несовпадение. Они не устанавливают, какую именно метку порядка программа присваивает каждой возможной паре. В долговечном журнале поэтому следует хранить обе исходные серии и, если он есть, результат сравнения, созданный реализацией. «Значения разные» следует из неравенства. Для вывода «этот сервер отстаёт» уже нужны правило сравнения, время наблюдения и роли серверов.

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

Чек сравнения может быть коротким. В нём нужны версии сервера и агентов Stork, реализация и версия DNS-демона; идентификаторы машины, демона, зоны, класса и представления без публикации секретов; ожидаемый состав и его владелец; окно сбора и статус каждого демона; Zone Configs Count, Distinct Zones, явные исключения и неподдерживаемые представления; исходные серии, время кэша или наблюдения, лимит свежести и результат; решение по сигналу и последующие исправления.

Такой чек должен допускать четыре исхода вместо одной зелёной лампы: полный для объявленного охвата; частичный, если строки недоступны; устаревший, если снимок старше установленного предела; несопоставимый, если состав изменился. Расхождение остаётся полезным и в частичной выборке. Отсутствие расхождений нельзя распространять дальше доказанного охвата.

Это не возражение против Stork. Это порядок работы, который делает центральное представление ценным. Продукт соединяет сведения, иначе разбросанные по множеству DNS-серверов. Оператор добавляет недостающий организационный факт: какие серверы и представления должны были войти в объединение. Когда ожидаемый и наблюдаемый состав хранятся вместе, выделенная строка становится не только удобным экраном, но и воспроизводимым основанием для решения.

Источники