RFC2182 — Выбор и эксплуатация вторичных DNS-серверов

Selection and Operation of Secondary DNS Servers

Выжимка

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

Полный перевод

Идентификатор и границы: RFC2182/part-001, SHA-256=af85693423a97da17b11f8cf10f30ebab367473d0073e197bf43a016256967f0. От начала документа по последний предоставленный абзац раздела 4.3 включительно.

Network Working Group                                             R. Elz
Request for Comments: 2182                       University of Melbourne
BCP: 16                                                          R. Bush
Category: Best Current Practice                              RGnet, Inc.
                                                              S. Bradner
                                                      Harvard University
                                                               M. Patton
                                                              Consultant
                                                               July 1997


            Выбор и эксплуатация вторичных DNS-серверов

Статус данного меморандума

   Этот документ определяет лучшую современную практику Интернета для
   интернет-сообщества и запрашивает обсуждение и предложения по
   улучшению. Распространение данного меморандума не ограничено.

Аннотация

   Система доменных имён требует наличия нескольких серверов для каждого
   делегированного домена (зоны). В этом документе рассматривается выбор
   вторичных серверов для DNS-зон. Как физическое, так и топологическое
   размещение каждого сервера являются существенными факторами при выборе
   вторичных серверов. Также рассматривается число серверов, подходящее
   для зоны, и некоторые общие вопросы сопровождения вторичных серверов.


Elz, et al.              Best Current Practice                  [Page 1]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997


Содержание

       Аннотация  ...................................................   1
    1  Введение  ....................................................   2
    2  Определения  .................................................   2
    3  Вторичные серверы  ...........................................   3
    4  Недостижимые серверы  ........................................   5
    5  Сколько вторичных серверов?  .................................   7
    6  Поиск подходящих вторичных серверов  .........................   8
    7  Сопровождение серийного номера  ..............................   9
       Вопросы безопасности  ........................................  11
       Ссылки  ......................................................  11
       Благодарности  ...............................................  11
       Адреса авторов  ..............................................  11


1. Введение

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

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

2. Определения

   Для целей этого документа, и только этого документа, применяются
   следующие определения:

   DNS                    Система доменных имён (The Domain Name System)
                          [RFC1034, RFC1035].

   Зона                   Часть дерева DNS, рассматриваемая как единое
                          целое.

   Прямая зона            Зона, содержащая данные, сопоставляющие имена
                          с адресами узлов, целями обмена почтой и т. п.


Elz, et al.              Best Current Practice                  [Page 2]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997


   Обратная зона          Зона, содержащая данные, используемые для
                          сопоставления адресов с именами.

   Сервер                 Реализация протоколов DNS, способная
                          предоставлять ответы на запросы. Ответы могут
                          основываться на информации, известной серверу,
                          или на информации, полученной от другого
                          сервера.

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

   Перечисленный сервер   Авторитетный сервер, для которого в зоне
                          имеется ресурсная запись (RR) "NS".

   Первичный сервер       Авторитетный сервер, для которого информация о
                          зоне настраивается локально. Иногда называется
                          сервером Master.

   Вторичный сервер       Авторитетный сервер, получающий информацию о
                          зоне от первичного сервера посредством
                          механизма переноса зоны. Иногда называется
                          сервером Slave.

   Скрытый сервер         Авторитетный сервер, обычно вторичный, который
                          не является перечисленным сервером.

   Резолвер               Клиент DNS, который с использованием протоколов
                          DNS ищет информацию, содержащуюся в зоне.

3. Вторичные серверы

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

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

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


Elz, et al.              Best Current Practice                  [Page 3]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997


   Различие между первичными и вторичными серверами имеет значение
   только для серверов рассматриваемой зоны; для остальной части DNS это
   просто несколько серверов. Все они изначально рассматриваются как
   равные, в том числе родительским сервером, который делегирует зону.
   Резолверы часто измеряют производительность различных серверов,
   выбирают «лучший» — в соответствии с некоторым определением лучшего —
   и предпочитают его для большинства запросов. Это происходит
   автоматически и здесь не рассматривается.

   Первичный сервер хранит главную копию файла зоны. То есть это сервер,
   на котором данные вводятся в DNS из некоторого источника вне DNS.
   Вторичные серверы получают данные зоны, используя механизмы протокола
   DNS для получения зоны с первичного сервера.

3.1. Выбор вторичных серверов

   При выборе вторичных серверов следует учитывать различные вероятные
   режимы отказа. Серверы следует размещать так, чтобы при любом
   вероятном отказе хотя бы один сервер, вероятно, был доступен для всех
   значимых частей Интернета.

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

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

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

3.2. Неподходящие конфигурации

   Хотя это, к сожалению, довольно распространено, серверы зоны, конечно
   же, не следует размещать все в одном сегменте LAN, в одном помещении
   одного здания — или в любом из этих общих мест. Такая конфигурация
   почти сводит на нет требование и полезность наличия нескольких
   серверов. Обычно единственная избыточность, обеспечиваемая такой
   конфигурацией, относится к случаю, когда один сервер не работает,
   тогда как следует учитывать множество других возможных режимов
   отказа, таких как отказы электропитания, включая длительные.


Elz, et al.              Best Current Practice                  [Page 4]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997


3.3. Разоблачение мифа

   Иногда приводится довод, что нет необходимости в доступности серверов
   доменных имён домена, если узлы в домене недостижимы. Этот довод
   ошибочен.

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

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

4. Недостижимые серверы

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

   Во-первых, единственный способ, которым резолверы могут определить,
   что эти адреса действительно недостижимы, — попытаться обратиться к
   ним. Затем им необходимо дождаться тайм-аута отсутствия ответа (или
   иногда сообщения об ошибке ICMP), чтобы узнать, что адрес нельзя
   использовать. Более того, даже это в целом неотличимо от простой
   потери пакета, поэтому последовательность необходимо повторить
   несколько раз, чтобы получить какие-либо реальные свидетельства
   недостижимости сервера. Всё это зондирование и ожидание тайм-аута
   может занять достаточно много времени, чтобы исходная клиентская
   программа или пользователь решили, что ответ недоступен, что приведёт
   к кажущемуся отказу зоны. Кроме того, всё это необходимо время от
   времени повторять, чтобы отличить постоянно недостижимый сервер от
   временно недостижимого.


Elz, et al.              Best Current Practice                  [Page 5]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997


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

4.1. Серверы за непостоянными соединениями

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

4.2. Другие проблемные случаи

   Сходные проблемы возникают, когда между резолвером и сервером
   существует транслятор сетевых адресов (NAT) [RFC1631]. Вопреки тому,
   что предполагает [RFC1631], NAT на практике не транслируют адреса,
   встроенные в пакеты, а транслируют только адреса в заголовках. Как
   предполагает [RFC1631], это представляет некоторую проблему для DNS.
   Иногда её можно преодолеть, если NAT сопровождается шлюзом прикладного
   уровня (ALG) или заменён им. Такое устройство понимало бы протокол DNS
   и транслировало бы все адреса соответствующим образом при прохождении
   пакетов через него. Даже при наличии такого устройства в любом из этих
   случаев, вероятно, лучше принять решение, описанное в следующем
   разделе.

4.3. Решение

   Чтобы избежать этих проблем, записи NS зоны, возвращаемые в любом
   ответе, должны содержать только серверы, до которых резолвер,
   запрашивающий информацию, вероятно, сможет достичь. Некоторые
   резолверы одновременно являются серверами, выполняющими поиск от имени
   других резолверов. Возвращаемые записи NS должны быть достижимы не
   только для резолвера, запросившего информацию, но и для любого другого
   резолвера, которому информация может быть перенаправлена. Все адреса
   всех возвращаемых серверов ДОЛЖНЫ (MUST) быть достижимы. Поскольку
   адреса каждого сервера образуют набор ресурсных записей (Resource
   Record Set) [RFC2181], должны возвращаться все они (либо ни одного);
   поэтому недопустимо исключать адреса недостижимых серверов или
   возвращать их с низким TTL (возвращая другие с более высоким TTL).
В частности, когда некоторые серверы находятся за межсетевым экраном, при нестабильном соединении или за NAT, который не допускает DNS-запросы или ответы либо имеет с ними проблемы, их имена или адреса не следует возвращать клиентам вне межсетевого экрана. Аналогично, серверы вне межсетевого экрана не следует делать известными клиентам внутри него, если эти клиенты не смогут выполнять запросы к таким серверам.

Elz, et al.              Best Current Practice                  [Page 6]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997

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

Когда сервер находится на границе межсетевого экрана, доступен с обеих сторон, но использует разные адреса, этому серверу следует присвоить два имени, каждое из которых связано с соответствующими записями A, так чтобы каждое имя выглядело доступным только с надлежащей стороны межсетевого экрана. Затем с этим следует обращаться так же, как с двумя серверами, по одному с каждой стороны межсетевого экрана. Сервер, реализованный в ALG, обычно будет именно таким случаем. Необходимо будет проявить особую тщательность, чтобы позволить такому серверу возвращать правильные ответы клиентам с каждой стороны. То есть возвращать только сведения о хостах, доступных с этой стороны, и правильный(е) IP-адрес(а) хоста при взгляде с этой стороны.

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

5. Сколько вторичных серверов?

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

С другой стороны, наличие большого числа серверов даёт мало преимуществ, увеличивая при этом затраты. В самом простом случае большее число серверов увеличивает размер пакетов и, следовательно, требует большей пропускной способности. Это может казаться — и в действительности является — несущественным. Однако размер DNS-пакета ограничен, и достижение этого ограничения имеет более серьёзные последствия для производительности. Разумно держаться от него на достаточном расстоянии. Большее число серверов также повышает вероятность того, что один сервер будет неправильно сконфигурирован или неисправен, а это останется незамеченным.

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

Elz, et al.              Best Current Practice                  [Page 7]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997

Обратные зоны, то есть поддомены .IN-ADDR.ARPA, как правило, менее критичны, и часто будет достаточно меньшего числа менее распределённых серверов. Это объясняется тем, что преобразования адреса в имя обычно требуются только при приёме пакетов от рассматриваемого адреса и только резолверам в месте назначения пакетов или рядом с ним. Это даёт некоторую уверенность, что серверы, расположенные в источнике пакета или рядом с ним, например в той же сети, будут доступны резолверам, которым необходимо выполнять такие поиски. Поэтому некоторые режимы отказа, которые следует учитывать при планировании серверов для прямых зон, могут быть менее существенны при планировании обратных зон.

5.1. Скрытые серверы

Серверы, являющиеся авторитетными для зоны, но не перечисленные в записях NS (также известные как «скрытые» серверы), не включаются в подсчёт серверов.

Часто может быть полезно, чтобы все серверы на площадке были авторитетными (вторичными), но только один или два были перечисленными серверами, а остальные — неперечисленными серверами для всех локальных зон, то есть скрытыми серверами.

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

Перечисление всех таких серверов в записях NS, если их больше одного или двух, заставило бы остальную часть Интернета затрачивать ненужные усилия на попытки связаться со всеми серверами на площадке, когда вся площадка недоступна из-за сбоев канала или маршрутизации.

6. Поиск подходящих вторичных серверов

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

Elz, et al.              Best Current Practice                  [Page 8]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997

7. Ведение серийного номера

Вторичные серверы используют серийный номер в записи SOA зоны, чтобы определить, когда необходимо обновить их локальную копию зоны. Серийные номера в основном являются 32-битными беззнаковыми целыми числами, которые циклически переходят от наибольшего возможного значения обратно к нулю. Более строгое определение серийного номера приведено в [RFC1982].

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

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

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

Например, предположим, что серийный номер зоны был равен 10, но случайно установлен в 1000, и желательно вернуть его к 11. Не меняйте значение просто с 1000 на 11. Вторичный сервер, увидевший значение 1000 (а на практике всегда есть хотя бы один такой сервер), проигнорирует это изменение и продолжит использовать версию зоны с серийным номером 1000, пока серийный номер первичного сервера не превысит это значение. Это может занять долгое время; фактически вторичный сервер часто прекращает обслуживать свою копию зоны до того, как зона вообще будет обновлена снова.

Вместо этого в данном примере установите серийный номер первичного сервера в 2000000000 и дождитесь, пока вторичные серверы обновятся до этой зоны. Значение 2000000000 выбрано как значение, значительно большее текущего, но меньшее чем на 2^31 (2^31 равно 2147483648). Следовательно, это является увеличением серийного номера [RFC1982].

Затем, после того как все серверы, нуждающиеся в обновлении, получат зону с таким серийным номером, серийный номер можно установить в 4000000000. 4000000000 на 2000000000 больше, чем 2000000000 (что вполне очевидно), и, следовательно, это ещё одно увеличение (добавляемое значение меньше 2^31).

Elz, et al.              Best Current Practice                  [Page 9]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997

Когда эта копия файла зоны имеется на всех серверах, серийный номер можно просто установить в 11. В арифметике серийных номеров изменение с 4000000000 на 11 является увеличением. Серийные номера циклически переходят при 2^32 (4294967296), поэтому 11 идентично 4294967307 (4294967296 + 11). 4294967307 всего на 294967307 больше, чем 4000000000, а 294967307 значительно меньше 2^31; следовательно, это увеличение.

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

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

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

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

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

Elz, et al.              Best Current Practice                 [Page 10]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997

Соображения безопасности

Не считается, что что-либо в этом документе добавляет к проблемам безопасности, которые могут существовать в DNS, или каким-либо образом уменьшает их.

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

Ссылки

[RFC1034]   Mockapetris, P., "Domain Names - Concepts and Facilities",
            STD 13, RFC 1034, November 1987.

[RFC1035]   Mockapetris, P., "Domain Names - Implementation and
            Specification", STD 13, RFC 1035, November 1987

[RFC1631]   Egevang, K., Francis, P., "The IP Network Address Translator
            (NAT)", RFC 1631, May 1994

[RFC1982]   Elz, R., Bush, R., "Serial Number Arithmetic",
            RFC 1982, August 1996.

[RFC2181]   Elz, R., Bush, R., "Clarifications to the DNS specification",
            RFC 2181, July 1997.

Благодарности

Brian Carpenter и Yakov Rekhter предложили упомянуть NAT и ALG как дополнение к тексту о межсетевых экранах. Dave Crocker предложил явно развеять миф.

Адреса авторов

Robert Elz
Computer Science
University of Melbourne
Parkville, Vic,  3052
Australia.

EMail: kre@munnari.OZ.AU

Elz, et al.              Best Current Practice                 [Page 11]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997

Randy Bush
RGnet, Inc.
5147 Crystal Springs Drive NE
Bainbridge Island, Washington,  98110
United States.

EMail: randy@psg.com

Scott Bradner
Harvard University
1350 Mass Ave
Cambridge, MA,  02138
United States.

EMail: sob@harvard.edu

Michael A. Patton
33 Blanchard Road
Cambridge, MA,  02138
United States.

EMail: MAP@POBOX.COM

Elz, et al.              Best Current Practice                 [Page 12]
Оригинал для сопоставления (EN)





Network Working Group                                             R. Elz
Request for Comments: 2182                       University of Melbourne
BCP: 16                                                          R. Bush
Category: Best Current Practice                              RGnet, Inc.
                                                              S. Bradner
                                                      Harvard University
                                                               M. Patton
                                                              Consultant
                                                               July 1997


            Selection and Operation of Secondary DNS Servers

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Abstract

   The Domain Name System requires that multiple servers exist for every
   delegated domain (zone).  This document discusses the selection of
   secondary servers for DNS zones.  Both the physical and topological
   location of each server are material considerations when selecting
   secondary servers.  The number of servers appropriate for a zone is
   also discussed, and some general secondary server maintenance issues
   considered.























Elz, et al.              Best Current Practice                  [Page 1]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997




Contents

       Abstract  ...................................................   1
    1  Introduction  ...............................................   2
    2  Definitions  ................................................   2
    3  Secondary Servers  ..........................................   3
    4  Unreachable servers  ........................................   5
    5  How many secondaries?  ......................................   7
    6  Finding Suitable Secondary Servers  .........................   8
    7  Serial Number Maintenance  ..................................   9
       Security Considerations  ....................................  11
       References  .................................................  11
       Acknowledgements  ...........................................  11
       Authors' Addresses  .........................................  11




1. Introduction

   A number of problems in DNS operations today are attributable to poor
   choices of secondary servers for DNS zones.  The geographic placement
   as well as the diversity of network connectivity exhibited by the set
   of DNS servers for a zone can increase the reliability of that zone
   as well as improve overall network performance and access
   characteristics.  Other considerations in server choice can
   unexpectedly lower reliability or impose extra demands on the
   network.

   This document discusses many of the issues that should be considered
   when selecting secondary servers for a zone.  It offers guidance in
   how to best choose servers to serve a given zone.

2. Definitions

   For the purposes of this document, and only this document, the
   following definitions apply:

   DNS                    The Domain Name System [RFC1034, RFC1035].

   Zone                   A part of the DNS tree, that is treated as a
                          unit.

   Forward Zone           A zone containing data mapping names to host
                          addresses, mail exchange targets, etc.




Elz, et al.              Best Current Practice                  [Page 2]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997


   Reverse Zone           A zone containing data used to map addresses
                          to names.

   Server                 An implementation of the DNS protocols able to
                          provide answers to queries.  Answers may be
                          from information known by the server, or
                          information obtained from another server.

   Authoritative Server   A server that knows the content of a DNS zone
                          from local knowledge, and thus can answer
                          queries about that zone without needing to
                          query other servers.

   Listed Server          An Authoritative Server for which there is an
                          "NS" resource record (RR) in the zone.

   Primary Server         An authoritative server for which the zone
                          information is locally configured.  Sometimes
                          known as a Master server.

   Secondary Server       An authoritative server that obtains
                          information about a zone from a Primary Server
                          via a zone transfer mechanism.  Sometimes
                          known as a Slave Server.

   Stealth Server         An authoritative server, usually secondary,
                          which is not a Listed Server.

   Resolver               A client of the DNS which seeks information
                          contained in a zone using the DNS protocols.

3. Secondary Servers

   A major reason for having multiple servers for each zone is to allow
   information from the zone to be available widely and reliably to
   clients throughout the Internet, that is, throughout the world, even
   when one server is unavailable or unreachable.

   Multiple servers also spread the name resolution load, and improve
   the overall efficiency of the system by placing servers nearer to the
   resolvers.  Those purposes are not treated further here.

   With multiple servers, usually one server will be the primary server,
   and others will be secondary servers.  Note that while some unusual
   configurations use multiple primary servers, that can result in data
   inconsistencies, and is not advisable.





Elz, et al.              Best Current Practice                  [Page 3]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997


   The distinction between primary and secondary servers is relevant
   only to the servers for the zone concerned, to the rest of the DNS
   there are simply multiple servers.  All are treated equally at first
   instance, even by the parent server that delegates the zone.
   Resolvers often measure the performance of the various servers,
   choose the "best", for some definition of best, and prefer that one
   for most queries.  That is automatic, and not considered here.

   The primary server holds the master copy of the zone file.  That is,
   the server where the data is entered into the DNS from some source
   outside the DNS.  Secondary servers obtain data for the zone using
   DNS protocol mechanisms to obtain the zone from the primary server.

3.1. Selecting Secondary Servers

   When selecting secondary servers, attention should be given to the
   various likely failure modes.  Servers should be placed so that it is
   likely that at least one server will be available to all significant
   parts of the Internet, for any likely failure.

   Consequently, placing all servers at the local site, while easy to
   arrange, and easy to manage, is not a good policy.  Should a single
   link fail, or there be a site, or perhaps even building, or room,
   power failure, such a configuration can lead to all servers being
   disconnected from the Internet.

   Secondary servers must be placed at both topologically and
   geographically dispersed locations on the Internet, to minimise the
   likelihood of a single failure disabling all of them.

   That is, secondary servers should be at geographically distant
   locations, so it is unlikely that events like power loss, etc, will
   disrupt all of them simultaneously.  They should also be connected to
   the net via quite diverse paths.  This means that the failure of any
   one link, or of routing within some segment of the network (such as a
   service provider) will not make all of the servers unreachable.

3.2. Unsuitable Configurations

   While it is unfortunately quite common, servers for a zone should
   certainly not all be placed on the same LAN segment in the same room
   of the same building - or any of those.  Such a configuration almost
   defeats the requirement, and utility, of having multiple servers.
   The only redundancy usually provided in that configuration is for the
   case when one server is down, whereas there are many other possible
   failure modes, such as power failures, including lengthy ones, to
   consider.




Elz, et al.              Best Current Practice                  [Page 4]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997


3.3. A Myth Exploded

   An argument is occasionally made that there is no need for the domain
   name servers for a domain to be accessible if the hosts in the domain
   are unreachable.  This argument is fallacious.

     + Clients react differently to inability to resolve than inability
       to connect, and reactions to the former are not always as
       desirable.
     + If the zone is resolvable yet the particular name is not, then a
       client can discard the transaction rather than retrying and
       creating undesirable load on the network.
     + While positive DNS results are usually cached, the lack of a
       result is not cached.  Thus, unnecessary inability to resolve
       creates an undesirable load on the net.
     + All names in the zone may not resolve to addresses within the
       detached network.  This becomes more likely over time.  Thus a
       basic assumption of the myth often becomes untrue.

   It is important that there be nameservers able to be queried,
   available always, for all forward zones.

4. Unreachable servers

   Another class of problems is caused by listing servers that cannot be
   reached from large parts of the network.  This could be listing the
   name of a machine that is completely isolated behind a firewall, or
   just a secondary address on a dual homed machine which is not
   accessible from outside.  The names of servers listed in NS records
   should resolve to addresses which are reachable from the region to
   which the NS records are being returned.  Including addresses which
   most of the network cannot reach does not add any reliability, and
   causes several problems, which may, in the end, lower the reliability
   of the zone.

   First, the only way the resolvers can determine that these addresses
   are, in fact, unreachable, is to try them.  They then need to wait on
   a lack of response timeout (or occasionally an ICMP error response)
   to know that the address cannot be used.  Further, even that is
   generally indistinguishable from a simple packet loss, so the
   sequence must be repeated, several times, to give any real evidence
   of an unreachable server.  All of this probing and timeout may take
   sufficiently long that the original client program or user will
   decide that no answer is available, leading to an apparent failure of
   the zone.  Additionally, the whole thing needs to be repeated from
   time to time to distinguish a permanently unreachable server from a
   temporarily unreachable one.




Elz, et al.              Best Current Practice                  [Page 5]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997


   And finally, all these steps will potentially need to be done by
   resolvers all over the network.  This will increase the traffic, and
   probably the load on the filters at whatever firewall is blocking
   this access.  All of this additional load does no more than
   effectively lower the reliability of the service.

4.1. Servers behind intermittent connections

   A similar problem occurs with DNS servers located in parts of the net
   that are often disconnected from the Internet as a whole.  For
   example, those which connect via an intermittent connection that is
   often down.  Such servers should usually be treated as if they were
   behind a firewall, and unreachable to the network at any time.

4.2. Other problem cases

   Similar problems occur when a Network Address Translator (NAT)
   [RFC1631] exists between a resolver and server.  Despite what
   [RFC1631] suggests, NATs in practice do not translate addresses
   embedded in packets, only those in the headers.  As [RFC1631]
   suggests, this is somewhat of a problem for the DNS.  This can
   sometimes be overcome if the NAT is accompanied by, or replaced with,
   an Application Layer Gateway (ALG).  Such a device would understand
   the DNS protocol and translate all the addresses as appropriate as
   packets pass through.  Even with such a device, it is likely to be
   better in any of these cases to adopt the solution described in the
   following section.

4.3. A Solution

   To avoid these problems, NS records for a zone returned in any
   response should list only servers that the resolver requesting the
   information, is likely to be able to reach.  Some resolvers are
   simultaneously servers performing lookups on behalf of other
   resolvers.  The NS records returned should be reachable not only by
   the resolver that requested the information, but any other resolver
   that may be forwarded the information.  All the addresses of all the
   servers returned must be reachable.  As the addresses of each server
   form a Resource Record Set [RFC2181], all must be returned (or none),
   thus it is not acceptable to elide addresses of servers that are
   unreachable, or to return them with a low TTL (while returning others
   with a higher TTL).

   In particular, when some servers are behind a firewall, intermittent
   connection, or NAT, which disallows, or has problems with, DNS
   queries or responses, their names, or addresses, should not be
   returned to clients outside the firewall.  Similarly, servers outside
   the firewall should not be made known to clients inside it, if the



Elz, et al.              Best Current Practice                  [Page 6]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997


   clients would be unable to query those servers.  Implementing this
   usually requires dual DNS setups, one for internal use, the other for
   external use.  Such a setup often solves other problems with
   environments like this.

   When a server is at a firewall boundary, reachable from both sides,
   but using different addresses, that server should be given two names,
   each name associated with appropriate A records, such that each
   appears to be reachable only on the appropriate side of the firewall.
   This should then be treated just like two servers, one on each side
   of the firewall.  A server implemented in an ALG will usually be such
   a case.  Special care will need to be taken to allow such a server to
   return the correct responses to clients on each side.  That is,
   return only information about hosts reachable from that side and the
   correct IP address(es) for the host when viewed from that side.

   Servers in this environment often need special provision to give them
   access to the root servers.  Often this is accomplished via "fake
   root" configurations.  In such a case the servers should be kept well
   isolated from the rest of the DNS, lest their unusual configuration
   pollute others.

5. How many secondaries?

   The DNS specification and domain name registration rules require at
   least two servers for every zone.  That is, usually, the primary and
   one secondary.  While two, carefully placed, are often sufficient,
   occasions where two are insufficient are frequent enough that we
   advise the use of more than two listed servers.  Various problems can
   cause a server to be unavailable for extended periods - during such a
   period, a zone with only two listed servers is actually running with
   just one.  Since any server may occasionally be unavailable, for all
   kinds of reasons, this zone is likely, at times, to have no
   functional servers at all.

   On the other hand, having large numbers of servers adds little
   benefit, while adding costs.  At the simplest, more servers cause
   packets to be larger, so requiring more bandwidth.  This may seem,
   and realistically is, trivial.  However there is a limit to the size
   of a DNS packet, and causing that limit to be reached has more
   serious performance implications.  It is wise to stay well clear of
   it.  More servers also increase the likelihood that one server will
   be misconfigured, or malfunction, without being detected.

   It is recommended that three servers be provided for most
   organisation level zones, with at least one which must be well
   removed from the others.  For zones where even higher reliability is
   required, four, or even five, servers may be desirable.  Two, or



Elz, et al.              Best Current Practice                  [Page 7]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997


   occasionally three of five, would be at the local site, with the
   others not geographically or topologically close to the site, or each
   other.

   Reverse zones, that is, sub-domains of .IN-ADDR.ARPA, tend to be less
   crucial, and less servers, less distributed, will often suffice.
   This is because address to name translations are typically needed
   only when packets are being received from the address in question,
   and only by resolvers at or near the destination of the packets.
   This gives some assurances that servers located at or near the packet
   source, for example, on the the same network, will be reachable from
   the resolvers that need to perform the lookups.  Thus some of the
   failure modes that need to be considered when planning servers for
   forward zones may be less relevant when reverse zones are being
   planned.

5.1. Stealth Servers

   Servers which are authoritative for the zone, but not listed in NS
   records (also known as "stealth" servers) are not included in the
   count of servers.

   It can often be useful for all servers at a site to be authoritative
   (secondary), but only one or two be listed servers, the rest being
   unlisted servers for all local zones, that is, to be stealth servers.

   This allows those servers to provide answers to local queries
   directly, without needing to consult another server.  If it were
   necessary to consult another server, it would usually be necessary
   for the root servers to be consulted, in order to follow the
   delegation tree - that the zone is local would not be known.  This
   would mean that some local queries may not be able to be answered if
   external communications were disrupted.

   Listing all such servers in NS records, if more than one or two,
   would cause the rest of the Internet to spend unnecessary effort
   attempting to contact all servers at the site when the whole site is
   inaccessible due to link or routing failures.

6. Finding Suitable Secondary Servers

   Operating a secondary server is usually an almost automatic task.
   Once established, the server generally runs itself, based upon the
   actions of the primary server.  Because of this, large numbers of
   organisations are willing to provide a secondary server, if
   requested.  The best approach is usually to find an organisation of
   similar size, and agree to swap secondary zones - each organisation
   agrees to provide a server to act as a secondary server for the other



Elz, et al.              Best Current Practice                  [Page 8]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997


   organisation's zones.  Note that there is no loss of confidential
   data here, the data set exchanged would be available publically
   whatever the servers are.

7. Serial Number Maintenance

   Secondary servers use the serial number in the SOA record of the zone
   to determine when it is necessary to update their local copy of the
   zone.  Serial numbers are basically just 32 bit unsigned integers
   that wrap around from the biggest possible value to zero again.  See
   [RFC1982] for a more rigorous definition of the serial number.

   The serial number must be incremented every time a change, or group
   of changes, is made to the zone on the primary server.  This informs
   secondary servers they need update their copies of the zone.  Note
   that it is not possible to decrement a serial number, increments are
   the only defined modification.

   Occasionally due to editing errors, or other factors, it may be
   necessary to cause a serial number to become smaller.  Never simply
   decrease the serial number.  Secondary servers will ignore that
   change, and further, will ignore any later increments until the
   earlier large value is exceeded.

   Instead, given that serial numbers wrap from large to small, in
   absolute terms, increment the serial number, several times, until it
   has reached the value desired.  At each step, wait until all
   secondary servers have updated to the new value before proceeding.

   For example, assume that the serial number of a zone was 10, but has
   accidentally been set to 1000, and it is desired to set it back to
   11.  Do not simply change the value from 1000 to 11.  A secondary
   server that has seen the 1000 value (and in practice, there is always
   at least one) will ignore this change, and continue to use the
   version of the zone with serial number 1000, until the primary
   server's serial number exceeds that value.  This may be a long time -
   in fact, the secondary often expires its copy of the zone before the
   zone is ever updated again.

   Instead, for this example, set the primary's serial number to
   2000000000, and wait for the secondary servers to update to that
   zone.  The value 2000000000 is chosen as a value a lot bigger than
   the current value, but less that 2^31 bigger (2^31 is 2147483648).
   This is then an increment of the serial number [RFC1982].

   Next, after all servers needing updating have the zone with that
   serial number, the serial number can be set to 4000000000.
   4000000000 is 2000000000 more than 2000000000 (fairly clearly), and



Elz, et al.              Best Current Practice                  [Page 9]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997


   is thus another increment (the value added is less than 2^31).

   Once this copy of the zone file exists at all servers, the serial
   number can simply be set to 11.  In serial number arithmetic, a
   change from 4000000000 to 11 is an increment.  Serial numbers wrap at
   2^32 (4294967296), so 11 is identical to 4294967307 (4294967296 +
    11).  4294967307 is just 294967307 greater than 4000000000, and
   294967307 is well under 2^31, this is therefore an increment.

   When following this procedure, it is essential to verify that all
   relevant servers have been updated at each step, never assume
   anything.  Failing to do this can result in a worse mess than existed
   before the attempted correction.  Also beware that it is the
   relationship between the values of the various serial numbers that is
   important, not the absolute values.  The values used above are
   correct for that one example only.

   It is possible in essentially all cases to correct the serial number
   in two steps by being more aggressive in the choices of the serial
   numbers.  This however causes the numbers used to be less "nice", and
   requires considerably more care.

   Also, note that not all nameserver implementations correctly
   implement serial number operations.  With such servers as secondaries
   there is typically no way to cause the serial number to become
   smaller, other than contacting the administrator of the server and
   requesting that all existing data for the zone be purged.  Then that
   the secondary be loaded again from the primary, as if for the first
   time.

   It remains safe to carry out the above procedure, as the
   malfunctioning servers will need manual attention in any case.  After
   the sequence of serial number changes described above, conforming
   secondary servers will have been reset.  Then when the primary server
   has the correct (desired) serial number, contact the remaining
   secondary servers and request their understanding of the correct
   serial number be manually corrected.  Perhaps also suggest that they
   upgrade their software to a standards conforming implementation.

   A server which does not implement this algorithm is defective, and
   may be detected as follows.  At some stage, usually when the absolute
   integral value of the serial number becomes smaller, a server with
   this particular defect will ignore the change.  Servers with this
   type of defect can be detected by waiting for at least the time
   specified in the SOA refresh field and then sending a query for the
   SOA.  Servers with this defect will still have the old serial number.
   We are not aware of other means to detect this defect.




Elz, et al.              Best Current Practice                 [Page 10]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997


Security Considerations

   It is not believed that anything in this document adds to any
   security issues that may exist with the DNS, nor does it do anything
   to lessen them.

   Administrators should be aware, however, that compromise of a server
   for a domain can, in some situations, compromise the security of
   hosts in the domain.  Care should be taken in choosing secondary
   servers so that this threat is minimised.

References

   [RFC1034]   Mockapetris, P., "Domain Names - Concepts and Facilities",
               STD 13, RFC 1034, November 1987.

   [RFC1035]   Mockapetris, P., "Domain Names - Implementation and
               Specification", STD 13, RFC 1035, November 1987

   [RFC1631]   Egevang, K., Francis, P., "The IP Network Address Translator
               (NAT)", RFC 1631, May 1994

   [RFC1982]   Elz, R., Bush, R., "Serial Number Arithmetic",
               RFC 1982, August 1996.

   [RFC2181]   Elz, R., Bush, R., "Clarifications to the DNS specification",
               RFC 2181, July 1997.

Acknowledgements

   Brian Carpenter and Yakov Rekhter suggested mentioning NATs and ALGs
   as a companion to the firewall text.  Dave Crocker suggested
   explicitly exploding the myth.

Authors' Addresses

   Robert Elz
   Computer Science
   University of Melbourne
   Parkville, Vic,  3052
   Australia.

   EMail: kre@munnari.OZ.AU








Elz, et al.              Best Current Practice                 [Page 11]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997


   Randy Bush
   RGnet, Inc.
   5147 Crystal Springs Drive NE
   Bainbridge Island, Washington,  98110
   United States.

   EMail: randy@psg.com

   Scott Bradner
   Harvard University
   1350 Mass Ave
   Cambridge, MA,  02138
   United States.

   EMail: sob@harvard.edu

   Michael A. Patton
   33 Blanchard Road
   Cambridge, MA,  02138
   United States.

   EMail: MAP@POBOX.COM





























Elz, et al.              Best Current Practice                 [Page 12]