О документе
Идентификатор и границы: 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-серверов
1. Введение
Ряд проблем в эксплуатации DNS сегодня обусловлен неудачным выбором
вторичных серверов для DNS-зон. Географическое размещение, а также
разнообразие сетевой связности, характерное для набора DNS-серверов
зоны, могут повысить надёжность этой зоны, а также улучшить общую
производительность сети и характеристики доступа. Другие соображения
при выборе серверов могут неожиданно снизить надёжность или создать
дополнительные требования к сети.
В этом документе рассматриваются многие вопросы, которые следует
учитывать при выборе вторичных серверов для зоны. Он содержит указания
о том, как наилучшим образом выбирать серверы для обслуживания данной
зоны.
2. Определения
Для целей этого документа, и только этого документа, применяются
следующие определения:
DNS Система доменных имён (The Domain Name System)
[RFC1034, RFC1035].
Зона Часть дерева DNS, рассматриваемая как единое
целое.
Прямая зона Зона, содержащая данные, сопоставляющие имена
с адресами узлов, целями обмена почтой и т. п.
Обратная зона Зона, содержащая данные, используемые для
сопоставления адресов с именами.
Сервер Реализация протоколов DNS, способная
предоставлять ответы на запросы. Ответы могут
основываться на информации, известной серверу,
или на информации, полученной от другого
сервера.
Авторитетный сервер Сервер, который знает содержимое DNS-зоны
локально и поэтому может отвечать на запросы
об этой зоне без необходимости обращаться к
другим серверам.
Перечисленный сервер Авторитетный сервер, для которого в зоне
имеется ресурсная запись (RR) "NS".
Первичный сервер Авторитетный сервер, для которого информация о
зоне настраивается локально. Иногда называется
сервером Master.
Вторичный сервер Авторитетный сервер, получающий информацию о
зоне от первичного сервера посредством
механизма переноса зоны. Иногда называется
сервером Slave.
Скрытый сервер Авторитетный сервер, обычно вторичный, который
не является перечисленным сервером.
Резолвер Клиент DNS, который с использованием протоколов
DNS ищет информацию, содержащуюся в зоне.
3. Вторичные серверы
Одна из основных причин наличия нескольких серверов для каждой зоны
состоит в том, чтобы информация из зоны была широко и надёжно
доступна клиентам по всему Интернету, то есть по всему миру, даже
когда один сервер недоступен или недостижим.
Несколько серверов также распределяют нагрузку разрешения имён и
повышают общую эффективность системы, размещая серверы ближе к
резолверам. Эти цели далее здесь не рассматриваются.
При наличии нескольких серверов обычно один сервер будет первичным,
а остальные — вторичными. Следует отметить, что хотя в некоторых
необычных конфигурациях используется несколько первичных серверов,
это может привести к несогласованности данных и не рекомендуется.
Различие между первичными и вторичными серверами имеет значение
только для серверов рассматриваемой зоны; для остальной части DNS это
просто несколько серверов. Все они изначально рассматриваются как
равные, в том числе родительским сервером, который делегирует зону.
Резолверы часто измеряют производительность различных серверов,
выбирают «лучший» — в соответствии с некоторым определением лучшего —
и предпочитают его для большинства запросов. Это происходит
автоматически и здесь не рассматривается.
Первичный сервер хранит главную копию файла зоны. То есть это сервер,
на котором данные вводятся в DNS из некоторого источника вне DNS.
Вторичные серверы получают данные зоны, используя механизмы протокола
DNS для получения зоны с первичного сервера.
3.1. Выбор вторичных серверов
При выборе вторичных серверов следует учитывать различные вероятные
режимы отказа. Серверы следует размещать так, чтобы при любом
вероятном отказе хотя бы один сервер, вероятно, был доступен для всех
значимых частей Интернета.
Следовательно, размещение всех серверов на локальной площадке, хотя
его легко организовать и им легко управлять, не является хорошей
политикой. При отказе одного канала либо при отказе площадки, а
возможно, даже здания, помещения или электропитания такая конфигурация
может привести к отключению всех серверов от Интернета.
Вторичные серверы должны быть размещены в географически и
топологически разнесённых местах Интернета, чтобы свести к минимуму
вероятность того, что единичный отказ выведет из строя их все.
То есть вторичные серверы должны находиться в географически удалённых
местах, чтобы было маловероятно, что такие события, как потеря
электропитания и т. п., одновременно нарушат работу всех из них. Они
также должны быть подключены к сети по существенно различающимся
путям. Это означает, что отказ любого одного канала или отказ
маршрутизации внутри некоторого сегмента сети (например, у поставщика
услуг) не сделает все серверы недостижимыми.
3.2. Неподходящие конфигурации
Хотя это, к сожалению, довольно распространено, серверы зоны, конечно
же, не следует размещать все в одном сегменте LAN, в одном помещении
одного здания — или в любом из этих общих мест. Такая конфигурация
почти сводит на нет требование и полезность наличия нескольких
серверов. Обычно единственная избыточность, обеспечиваемая такой
конфигурацией, относится к случаю, когда один сервер не работает,
тогда как следует учитывать множество других возможных режимов
отказа, таких как отказы электропитания, включая длительные.
3.3. Разоблачение мифа
Иногда приводится довод, что нет необходимости в доступности серверов
доменных имён домена, если узлы в домене недостижимы. Этот довод
ошибочен.
+ Клиенты по-разному реагируют на невозможность разрешить имя и на
невозможность подключиться, и реакция на первое не всегда столь
желательна.
+ Если зона разрешима, но конкретное имя — нет, клиент может
отбросить транзакцию вместо повторных попыток, создающих
нежелательную нагрузку на сеть.
+ Хотя положительные результаты DNS обычно кэшируются, отсутствие
результата не кэшируется. Таким образом, ненужная невозможность
разрешения имени создаёт нежелательную нагрузку на сеть.
+ Не все имена в зоне могут разрешаться в адреса внутри отключённой
сети. Со временем это становится более вероятным. Таким образом,
базовое предположение мифа часто становится неверным.
Важно, чтобы для всех прямых зон всегда были доступны серверы имён,
к которым можно обращаться с запросами.
4. Недостижимые серверы
Другой класс проблем вызван указанием серверов, к которым нельзя
обратиться из больших частей сети. Это может быть указание имени
машины, полностью изолированной за межсетевым экраном, или всего лишь
вторичного адреса на двухинтерфейсной машине, недоступного извне. Имена
серверов, указанные в записях NS, должны разрешаться в адреса, которые
достижимы из области, в которую возвращаются записи NS. Включение
адресов, недостижимых для большей части сети, не добавляет надёжности
и вызывает несколько проблем, которые в итоге могут снизить
надёжность зоны.
Во-первых, единственный способ, которым резолверы могут определить,
что эти адреса действительно недостижимы, — попытаться обратиться к
ним. Затем им необходимо дождаться тайм-аута отсутствия ответа (или
иногда сообщения об ошибке ICMP), чтобы узнать, что адрес нельзя
использовать. Более того, даже это в целом неотличимо от простой
потери пакета, поэтому последовательность необходимо повторить
несколько раз, чтобы получить какие-либо реальные свидетельства
недостижимости сервера. Всё это зондирование и ожидание тайм-аута
может занять достаточно много времени, чтобы исходная клиентская
программа или пользователь решили, что ответ недоступен, что приведёт
к кажущемуся отказу зоны. Кроме того, всё это необходимо время от
времени повторять, чтобы отличить постоянно недостижимый сервер от
временно недостижимого.
И наконец, все эти действия потенциально потребуется выполнять
резолверам по всей сети. Это увеличит трафик и, вероятно, нагрузку на
фильтры того межсетевого экрана, который блокирует этот доступ. Вся
эта дополнительная нагрузка фактически лишь снижает надёжность службы.
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-запросы или ответы либо имеет с ними проблемы, их имена или адреса не следует возвращать клиентам вне межсетевого экрана. Аналогично, серверы вне межсетевого экрана не следует делать известными клиентам внутри него, если эти клиенты не смогут выполнять запросы к таким серверам.
Обычно для реализации этого требуются две DNS-конфигурации: одна для внутреннего использования, другая для внешнего. Такая конфигурация часто решает и другие проблемы в подобных средах.
Когда сервер находится на границе межсетевого экрана, доступен с обеих сторон, но использует разные адреса, этому серверу следует присвоить два имени, каждое из которых связано с соответствующими записями A, так чтобы каждое имя выглядело доступным только с надлежащей стороны межсетевого экрана. Затем с этим следует обращаться так же, как с двумя серверами, по одному с каждой стороны межсетевого экрана. Сервер, реализованный в ALG, обычно будет именно таким случаем. Необходимо будет проявить особую тщательность, чтобы позволить такому серверу возвращать правильные ответы клиентам с каждой стороны. То есть возвращать только сведения о хостах, доступных с этой стороны, и правильный(е) IP-адрес(а) хоста при взгляде с этой стороны.
Серверам в такой среде часто требуется специальное обеспечение доступа к корневым серверам. Нередко это достигается посредством конфигураций «fake root». В таком случае серверы следует держать хорошо изолированными от остальной DNS, чтобы их необычная конфигурация не повлияла на других.
5. Сколько вторичных серверов?
Спецификация DNS и правила регистрации доменных имён требуют как минимум двух серверов для каждой зоны. То есть обычно первичный сервер и один вторичный. Хотя двух тщательно размещённых серверов часто достаточно, случаи, когда двух недостаточно, происходят достаточно часто, поэтому мы советуем использовать более двух перечисленных серверов. Различные проблемы могут сделать сервер недоступным на длительные периоды; в такой период зона, имеющая только два перечисленных сервера, фактически работает лишь с одним. Поскольку любой сервер иногда может быть недоступен по самым разным причинам, эта зона, вероятно, временами вообще не будет иметь работоспособных серверов.
С другой стороны, наличие большого числа серверов даёт мало преимуществ, увеличивая при этом затраты. В самом простом случае большее число серверов увеличивает размер пакетов и, следовательно, требует большей пропускной способности. Это может казаться — и в действительности является — несущественным. Однако размер DNS-пакета ограничен, и достижение этого ограничения имеет более серьёзные последствия для производительности. Разумно держаться от него на достаточном расстоянии. Большее число серверов также повышает вероятность того, что один сервер будет неправильно сконфигурирован или неисправен, а это останется незамеченным.
Для большинства зон уровня организации рекомендуется предусматривать три сервера, причём как минимум один из них должен быть хорошо удалён от остальных. Для зон, где требуется ещё более высокая надёжность, могут быть желательны четыре или даже пять серверов. Два или, иногда, три из пяти будут находиться на локальной площадке, а остальные — не географически или топологически близко к площадке либо друг к другу.
Обратные зоны, то есть поддомены .IN-ADDR.ARPA, как правило, менее критичны, и часто будет достаточно меньшего числа менее распределённых серверов. Это объясняется тем, что преобразования адреса в имя обычно требуются только при приёме пакетов от рассматриваемого адреса и только резолверам в месте назначения пакетов или рядом с ним. Это даёт некоторую уверенность, что серверы, расположенные в источнике пакета или рядом с ним, например в той же сети, будут доступны резолверам, которым необходимо выполнять такие поиски. Поэтому некоторые режимы отказа, которые следует учитывать при планировании серверов для прямых зон, могут быть менее существенны при планировании обратных зон.
5.1. Скрытые серверы
Серверы, являющиеся авторитетными для зоны, но не перечисленные в записях NS (также известные как «скрытые» серверы), не включаются в подсчёт серверов.
Часто может быть полезно, чтобы все серверы на площадке были авторитетными (вторичными), но только один или два были перечисленными серверами, а остальные — неперечисленными серверами для всех локальных зон, то есть скрытыми серверами.
Это позволяет таким серверам отвечать на локальные запросы непосредственно, без необходимости обращаться к другому серверу. Если бы требовалось обратиться к другому серверу, обычно пришлось бы обращаться к корневым серверам, чтобы пройти по дереву делегирования: то, что зона локальная, не было бы известно. Это означало бы, что на некоторые локальные запросы нельзя было бы ответить при нарушении внешней связи.
Перечисление всех таких серверов в записях NS, если их больше одного или двух, заставило бы остальную часть Интернета затрачивать ненужные усилия на попытки связаться со всеми серверами на площадке, когда вся площадка недоступна из-за сбоев канала или маршрутизации.
6. Поиск подходящих вторичных серверов
Эксплуатация вторичного сервера обычно является почти автоматической задачей. После настройки сервер в целом работает самостоятельно, основываясь на действиях первичного сервера. Поэтому большое число организаций готовы по запросу предоставить вторичный сервер. Обычно наилучший подход — найти организацию сходного размера и договориться об обмене вторичными зонами: каждая организация соглашается предоставить сервер, который будет действовать как вторичный сервер для зон другой организации. Обратите внимание, что здесь не происходит потери конфиденциальных данных: обмениваемый набор данных был бы общедоступен независимо от серверов.
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).
Когда эта копия файла зоны имеется на всех серверах, серийный номер можно просто установить в 11. В арифметике серийных номеров изменение с 4000000000 на 11 является увеличением. Серийные номера циклически переходят при 2^32 (4294967296), поэтому 11 идентично 4294967307 (4294967296 + 11). 4294967307 всего на 294967307 больше, чем 4000000000, а 294967307 значительно меньше 2^31; следовательно, это увеличение.
При следовании этой процедуре крайне важно проверять, что все относящиеся к делу серверы были обновлены на каждом шаге; никогда ничего не предполагая. Невыполнение этого может привести к худшей неразберихе, чем существовала до попытки исправления. Также помните, что важна взаимосвязь между значениями различных серийных номеров, а не их абсолютные значения. Использованные выше значения правильны только для этого одного примера.
Практически во всех случаях можно исправить серийный номер за два шага, более агрессивно выбирая серийные номера. Однако это делает используемые числа менее «удобными» и требует значительно большей осторожности.
Также обратите внимание, что не все реализации серверов имён правильно реализуют операции с серийными номерами. При наличии таких серверов в качестве вторичных обычно нет способа сделать серийный номер меньшим, кроме как связаться с администратором сервера и попросить удалить все существующие данные зоны. Затем вторичный сервер должен быть снова загружен с первичного, как будто впервые.
Выполнять описанную выше процедуру всё равно безопасно, поскольку неисправные серверы в любом случае потребуют ручного вмешательства. После описанной выше последовательности изменений серийного номера соответствующие требованиям вторичные серверы будут сброшены. Затем, когда первичный сервер будет иметь правильный (желаемый) серийный номер, свяжитесь с оставшимися вторичными серверами и попросите вручную исправить их представление о правильном серийном номере. Возможно, также предложите им обновить программное обеспечение до реализации, соответствующей стандартам.
Сервер, не реализующий этот алгоритм, неисправен; его можно обнаружить следующим образом. На некотором этапе, обычно когда абсолютное целочисленное значение серийного номера становится меньше, сервер с этим конкретным дефектом проигнорирует изменение. Серверы с таким типом дефекта можно обнаружить, выждав по меньшей мере время, указанное в поле SOA refresh, а затем отправив запрос SOA. Серверы с таким дефектом всё ещё будут иметь старый серийный номер. Нам неизвестны другие способы обнаружить этот дефект.
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