Кратко

  • Рекомендация иметь три перечисленных сервера предполагала, что хотя бы один из них существенно отделён от остальных географически и топологически.
  • Объявленный, но недостижимый адрес заставляет распределённые резолверы пробовать, ждать и повторять запросы, снижая воспринимаемую надёжность зоны.
  • NS-запись, авторитетный ответ, номер SOA и завершённый перенос зоны подтверждают разные стадии; ни одна из них не гарантирует свежесть всех копий или доступность приложения.

Множественное число в зоне, единичный отказ в сети

RFC 2182 был опубликован в июле 1997 года как BCP 16. Несколько серверов нужны были не для красивого списка, а чтобы информация зоны оставалась доступной, когда один сервер не работает или недостижим. Машины в одной комнате защищали от поломки одного компьютера, но не от потери комнаты, здания, электропитания или общего канала.

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

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

Недостижимый адрес раздаёт ожидание всем

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

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

В исходном тексте было сказано, что отсутствие результата не кэшируется. Редакционная errata 4631, оставленная до обновления документа, учитывает RFC 2308: отрицательный ответ может кэшироваться в зависимости от реализации и настройки. Поправка уточняет историю, но не делает недостижимую авторитетную точку полезной.

Referral может передаваться дальше, поэтому достижимость только из первой сети недостаточна. Адресный RRset должен рассматриваться целиком; нельзя скрыть один плохой адрес или дать только ему особый TTL. Разная внутренняя и внешняя видимость требует согласованных представлений DNS для каждой стороны.

Чем больше копий, тем больше поверхность расхождения

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

RFC отделил перечисленные серверы от stealth servers. Локальные авторитетные копии могут обслуживать внутренние запросы при обрыве внешней связи, не будучи объявлены всему Интернету. Если перечислить их все, внешние резолверы будут по очереди проверять машины за одним и тем же упавшим каналом. Локальная полезность не равна публичному обещанию.

Копия должна сохранять правильную версию

Secondary решает об обновлении по serial в SOA. Primary увеличивает его после каждого изменения. Если значение ошибочно завысили, простое уменьшение может выглядеть старым: серверы, видевшие большое число, проигнорируют исправление.

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

NS подтверждает объявление имени. Ответ подтверждает работу одного процесса. SOA показывает номер, увиденный из одной точки. Завершение переноса подтверждает транспортную сессию. Отдельно остаются загрузка, фактически обслуживаемые данные, их идентичность, независимость инфраструктуры и результат приложения.

Раздел безопасности тоже не расширял вывод. RFC не обещал решить проблемы безопасности DNS и предупреждал, что компрометация secondary способна затронуть узлы домена. Независимость полезна лишь при сохранении доверия к новой авторитетной точке.

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

Источники

  1. RFC 2182 — Selection and Operation of Secondary DNS Servers
  2. Информационная страница RFC 2182
  3. RFC 1982 — Serial Number Arithmetic
  4. RFC 2181 — Clarifications to the DNS Specification
  5. RFC 2308 — Negative Caching of DNS Queries
  6. Errata RFC 2182