Резервный DNS тоже зависит от основного: как проверить независимость разрешения имён

Что именно мы называем резервом

В учебном обсуждении проекта: два адреса DNS ещё не означают два независимых пути к ответу.

В архитектурном предложении указаны основной и резервный DNS. Проверка показывает, что оба адреса отвечают. Кажется, вопрос закрыт: серверов два, запрос проходит, резерв предусмотрен. Но для ИТ-директора это только начало разговора. Нужно понять, какую именно потерю переживёт корпоративный сервис: остановку одного процесса, обрыв сетевого канала, недоступность поставщика или невозможность изменить запись.

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

Поэтому полезнее поставить проверяемый вопрос: «При отказе какого звена, из какого приложения и за какое время должен получиться правильный ответ?» В таком виде резерв становится свойством конкретного маршрута. В виде «у нас два DNS» он остаётся перечнем адресов. Статья помогает подготовить первый вариант: различить уровни, объяснить наблюдения и собрать основания для решения по архитектуре.

Мы не исследуем рабочую сеть НТА и не утверждаем, что в компании читателя уже есть общий отказ. Ниже — собственный изолированный опыт на учебной зоне и метод обследования. Опыт показывает механизм зависимости, но не измеряет доступность коммерческих поставщиков. Где заканчиваются наблюдения и начинаются вопросы к рабочей схеме, это обозначено отдельно.

Два уровня DNS решают разные задачи

Для начала разделим два понятия. Рекурсивный резолвер получает вопрос клиента и организует поиск ответа. Авторитетный сервер хранит сведения обслуживаемой зоны и отвечает за них. Клиент может обратиться к резолверу, тот — к вышестоящему резолверу либо пройти нужную цепочку сам. Роли и различие рекурсивного и нерекурсивного ответа описаны в RFC 1034.

Представим учебное имя service.dns-lab.test. Приложению нужен адрес, и оно задаёт вопрос настроенному резолверу. Если подходящий ответ уже есть в его кэше, обращаться дальше прямо сейчас не требуется. Если ответа нет или срок его использования истёк, резолвер должен получить сведения по доступному ему пути. Именно на этом втором шаге обнаруживаются зависимости, которые не видны при повторении одного привычного запроса.

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

В российской практике это различие видно и в документации Yandex Cloud DNS: для публичной зоны требуется делегация на серверы имён у регистратора, а внутренние зоны обслуживаются облачным резолвером в соответствующих сетях. Это пример устройства продукта, а не рекомендация выбрать определённого поставщика. Особенно важно различать эти роли, когда у сервиса есть одновременно публичные и внутренние имена.

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

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

Почему два адреса могут вести к одному отказу

Рассмотрим схему с двумя резолверами R1 и R2. У каждого отдельный входной адрес, но оба настроены пересылать запросы только серверу U. Сервер U, в свою очередь, получает сведения у авторитетного A1. Пока U работает, оба входа успешно отвечают. При остановке R1 второй действительно способен помочь. При остановке U оба пути теряют одно и то же звено.

Это не особенность названий серверов. Зависимость возникает из настройки маршрута. В BIND поведение перенаправления определяют forwarders и режим forward only; описание есть в руководстве BIND 9.20.30. Если разрешён только один следующий сервер, два предыдущих процесса не делают этот следующий сервер резервированным. Проверять нужно фактическую конфигурацию, а не схожесть или различие адресов.

Для проверки мы запустили отдельные процессы BIND 9.20.30 в одном временном контейнере без внешней сети и без опубликованных наружу портов. В нём были два авторитетных экземпляра A1 и A2 с отдельными файлами учебной зоны, общий U, два зависимых резолвера R1/R2 и отдельный R3, обращавшийся к A2. Имена и адреса полностью синтетические. Это не снимок корпоративной инфраструктуры.

Сначала R1, R2 и R3 вернули адрес 192.0.2.10. Затем мы остановили U. Сразу после остановки R1 и R2 продолжили возвращать адрес: действовал их кэш. После ожидания, превышающего установленный TTL, оба вернули SERVFAIL без адреса. R3 через A2 продолжил отвечать. Так мы получили наблюдаемое различие между двумя входами в общую зависимость и отдельным путём относительно отказа U.

×

Изолированный опыт НТА, 26 октября 2026 года: BIND 9.20.30, U остановлен, прошло больше TTL 4 секунды. Сравниваются процессы, а не независимые физические площадки.

У результата есть строгая граница. Все процессы размещались на одном вычислительном узле. Они не пережили бы его потерю. Поэтому нельзя называть R3 «полностью независимым DNS». Он оказался независим от остановленного U в этом опыте. Такое уточнение и нужно переносить в рабочий протокол: какое событие проверено, какие общие ресурсы сохранены и какие выводы из результата делать нельзя.

Кэш меняет смысл успешного запроса

TTL — срок, в течение которого полученные DNS-данные могут использоваться из кэша. Поля записей и ответов описаны в RFC 1035. Для нашего опыта положительный TTL был намеренно коротким — четыре секунды. Это учебный параметр, позволяющий наблюдать смену состояний, а не рекомендуемая настройка для рабочей зоны.

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

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

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

Кроме того, существуют реализации и настройки выдачи устаревших данных. RFC 8767 описывает возможность отвечать ранее сохранёнными сведениями при недоступности авторитетных серверов после обычного TTL. Это может поддержать часть обращений, но не означает, что источник снова доступен или что ответ отражает последнее изменение. В нашем опыте такой режим был явно отключён.

Поэтому корректное ожидание формулируют через состояние кэша и настройки реализации. Вместо «после TTL DNS обязан перестать отвечать» — «в этой конфигурации, без выдачи устаревшего кэша, после ожидания пяти секунд R1/R2 вернули SERVFAIL». Второе утверждение проверяемо. Первое слишком широко и способно привести к ошибочной диагностике там, где устаревший ответ выдаётся намеренно.

У прикладного сервиса могут быть и собственные механизмы хранения адреса или длительное соединение. В нашем опыте измерялся непосредственный DNS-запрос через dig, а не поведение браузера, среды выполнения или пула соединений. Поэтому после DNS-проверки нужен отдельный прикладной сценарий: новое обращение из того места, откуда работает сервис. Успех команды администратора не заменяет успех этой операции.

Отрицательный кэш переживает создание записи

Кэш хранит не только найденный адрес. Он может сохранить и отрицательный ответ. NXDOMAIN означает отсутствие имени; отсутствие записи запрошенного типа при существующем имени — другой случай. Правила их кэширования и роль SOA раскрыты в RFC 2308. Эти состояния нельзя объединять общим словом «DNS не работает».

Мы проверили это отдельно. Сначала спросили у R3 адрес ещё не созданного new.dns-lab.test и получили NXDOMAIN. Затем добавили запись в A2 и перечитали его файл зоны. Прямой запрос к A2 уже вернул 192.0.2.20, а R3 спустя примерно четыре десятых секунды всё ещё вернул NXDOMAIN. После дополнительного ожидания пяти секунд R3 получил адрес.

Причина наблюдения не в том, что новая запись «не дошла до всего интернета». В этом опыте существовали один конкретный авторитетный процесс и один конкретный отрицательный кэш. SOA TTL и MINIMUM были равны четырём секундам. Резолвер имел ещё пригодное сообщение об отсутствии и использовал его до истечения срока. Источник и сохранённый ответ находились в разных состояниях.

×

Изолированный опыт НТА, 26 октября 2026 года: отрицательный TTL 4 секунды; после добавления имени проверка через 0,4 секунды, затем после ожидания ещё 5 секунд. Это последовательность отдельных наблюдений, не измерение точного времени распространения.

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

Но отрицательный кэш не объясняет любую ошибку. Опечатка, другая внутренняя зона или иной маршрут могут дать похожий внешний результат. Прежде чем объявлять задержку ожидаемой, нужно сопоставить точное имя, тип запроса, выбранный резолвер, ответ авторитетного источника и состояние кэша. Само наличие в статье примера NXDOMAIN не служит разрешением игнорировать реальное отсутствие записи.

Резерв авторитетной зоны проверяют отдельно

После опыта с U мы восстановили его процесс и остановили A1. Затем дождались истечения учебного TTL и спросили U. Он вернул SERVFAIL, а R3 через A2 продолжил отвечать. Это отдельное наблюдение: теперь потеряно авторитетное звено первого пути. Предыдущая проверка остановленного U не могла подтвердить поведение при этом событии, потому что A1 тогда оставался доступен.

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

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

Отдельно проверяется согласованность данных. Второй доступный авторитетный сервер со старым или неверным адресом не удовлетворяет требованию правильного ответа. В нашем опыте A1 и A2 были двумя первичными экземплярами с вручную подготовленными файлами. Автоматический перенос зоны, срок действия вторичной копии и работа делегации в публичной иерархии не испытывались. Поэтому опыт не является готовой проверкой вторичного DNS.

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

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

Доступность ответов и доступность управления

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

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

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

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

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

Где заканчиваются доказательства

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

Общий вычислительный узел, питание, сетевая среда и контейнер оставались едиными. DNSSEC был отключён только для синтетической зоны; его ошибки и восстановление не исследовались. Также не проверялись переключение конкретного клиента между резолверами, нагрузка, транспорт UDP/TCP, цепочки псевдонимов и публичная делегация. У каждого из этих факторов может быть собственная проверка в проекте, но здесь нет оснований объявить её состоявшейся.

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

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

Карта двух путей для архитектурного решения

После объяснения механики можно собрать практический артефакт. Для одного разрешённого сервиса нарисуйте путь от реального клиента до авторитетного источника. Сделайте то же для резерва и отмечайте совпадения. Пустая ячейка означает отсутствие сведений, а не независимость. Разные имена узлов без подтверждения их роли тоже не являются доказательством.

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

Затем сопоставьте карту с исходным требованием. Если требуется пережить отказ общего U, схема R1/R2 через этот U не соответствует ему, сколько бы адресов ни было у входа. Если требуется пережить остановку R1, наличие работоспособного R2 может быть частью подходящего решения, но ещё нужно подтвердить выбор R2 реальным клиентом. Карта превращает спор о количестве серверов в обсуждение конкретного условия приёмки.

Для сравнения предложений удобно рассмотреть три ограниченных варианта. Первый — оставить общий U и резервировать только входные резолверы. Он имеет смысл, когда согласован именно отказ входного процесса, а доступность U обеспечивается в другой явно принятой границе. Такой вариант нельзя продавать под обещанием независимости от U: его достоинство и ограничение должны быть названы одновременно.

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

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

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

Разделяйте также отсутствие доказательства и наблюдаемый отрицательный результат. Неизвестная топология поставщика означает, что независимость в этой части не подтверждена имеющимися материалами. Два SERVFAIL после остановки U в нашем опыте означают, что названное условие фактически не выполнено. Для первого случая нужны сведения или испытание; для второго — пересмотр схемы либо согласование другого требования владельцем результата. Смешение этих случаев делает заключение менее точным.

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

Протокол испытания без ложного успеха

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

Последовательность удобнее построить по одному изменяемому звену. Сначала зафиксировать исходную работоспособность обоих путей. Затем остановить одно выбранное звено и проверить два состояния: действующий кэш и необходимость нового разрешения. После восстановления исходного состояния повторить сценарий для авторитетного звена. Одновременное выключение нескольких частей не позволяет уверенно связать результат с одной причиной.

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

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

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

Тест понедельником

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

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

Связь с НТА здесь относится к обследованию архитектуры и интеграционных зависимостей, а не к продаже DNS. В описании команды НТА можно сверить направления работы. Например, модуль NTA Kafka встраивается в интеграционную среду; доступность сетевых зависимостей такого обмена требует отдельного рассмотрения и не возникает из самого наличия модуля.

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

Важное уведомление

Материал носит информационный характер и не является индивидуальной консультацией, проектной документацией, инструкцией по внедрению или гарантией результата. Применимость описанных подходов зависит от процессов, систем, данных, требований безопасности и иных условий конкретной организации. Перед внедрением или изменением ИТ‑систем необходимо самостоятельно оценить риски и привлечь профильных специалистов.