Кратко

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

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

Именно эту эксплуатационную проблему рассмотрели Роберт Элз, Рэнди Буш, Скотт Брэднер и Майкл Паттон в RFC 2182 «Selection and Operation of Secondary DNS Servers». В июле 1997 года IETF опубликовала документ как Best Current Practice 16. Это был не новый протокол DNS. Авторы стремились сделать предусмотренное системой резервирование реальным за пределами файла зоны — в работающей сети.

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

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

RFC 2182 рекомендовал три сервера для большинства организационных зон, причём хотя бы один должен находиться «достаточно далеко» от остальных. Для зон с более высокими требованиями к надёжности могли подойти четыре или пять. Бесконечно наращивать число серверов было не всегда полезно: большие наборы NS увеличивали DNS-пакеты и создавали больше возможностей пропустить незамеченную ошибку конфигурации. Три — ориентир в решении о размещении, а не универсальный порог соответствия.

Рекомендация выявляла и практическую зависимость: кто будет размещать удалённую копию? RFC описывал обмен услугами вторичного сервера между организациями сопоставимого размера. Поскольку передаваемые данные зоны и так были общедоступны, такое сотрудничество не раскрывает конфиденциальную информацию. Резервирование распределяется между операторами, но им приходится поддерживать передачи, серийные номера и доступность.

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

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

Главный вывод RFC 2182 конкретнее магического числа: резервирование зависит от зависимостей. Третий сервер важен лишь тогда, когда меняет то, что может отказать одновременно.

Источники

  • RFC 2182 / BCP 16 — «Selection and Operation of Secondary DNS Servers».

  • RFC 1034 — «Domain Names—Concepts and Facilities».

  • RFC 1035 — «Domain Names—Implementation and Specification».

  • RFC 2308 — «Negative Caching of DNS Queries».

  • Erratum 4631 редакторов RFC — Позднейшее исправление общего утверждения RFC 2182 об отрицательном кэшировании.

  • Материалы IETF 40 — Обсуждение DNS в декабре 1997 года.

  • ISC, история BIND — Хронология выхода BIND 8.

  • RFC 1982 — Арифметика серийных номеров, используемая при обслуживании зоны.

  • Черновик DNSIND -06 — Версия мая 1997 года в истории RFC 2182.

  • Heng Lu, Note 70 — Только редакционная оптика, не свидетельство об истории DNS.