Request for Comments: 2182

Copyright (C) The Internet Society (2000). All Rights Reserved.

Перевод на русский язык - С.Ткаченко
Замечания, комментарии - sveta@net.ua

Июль 1997

Категория: лучшая практика

Category: Best Current Practice
July 1997

                 R. Elz
University of Melbourne
                R. Bush
            RGnet, Inc.
             S. Bradner
     Harvard University
              M. Patton
             Consultant
Выбор и эксплуатация вторичного сервера доменных имен (DNS)
Selection and Operation of Secondary DNS Servers
Статус: В этом документе обобщена наилучшая на сегодня практика для Internet сообщества. Документ приглашает к обсуждению и дополнениям. Распространение этого RFC неограничено. 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.

Резюме

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

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.

Содержание

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

   Abstract
1  Introduction
2  Definitions
3  Secondary Servers
4  Unreachable servers
5  How many secondaries?
6  Finding Suitable Secondary Servers 
7  Serial Number Maintenance
   Security Considerations 
   References
   Acknowledgements
   Authors' Addresses
1. Ведение 1. Introduction
На сегодняшний день целый ряд проблем в управлении DNS является следствием неудачного выбора вторичных серверов для DNS зон. Географическое расположение, а также разнообразие сетевых связей, предусмотренное при выборе DNS серверов для зоны, могут не только увеличить надежность этой зоны, но и улучшить эффективность работы и характеристики доступа для всей сети в целом. Другие подходы в выборе сервера могут неожиданно уменьшить надежность или предъявить дополнительные требования к сети. 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.Определения 2. Definitions
В рамках данного документа и только его примем следующие опрделения: For the purposes of this document, and only this document, the following definitions apply:
DNS - Система Доменных Имен [RFC1034, RFC1035]. DNS The Domain Name System [RFC1034, RFC1035].
Зона - часть дерева DNS, которая рассматривается как единица. 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.
Обратная Зона - зона, содержащая данные, используемые для отображения адреса в имя. Reverse Zone A zone containing data used to map addresses to names.
Сервер - машина или программа, работающая в соответствии с DNS протоколами, способное давать ответы на запросы. Ответы могут содержать информацию, известную данному серверу, или информацию, полученную от другого сервера. 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.
Авторитетный Сервер - сервер, которому известно содержимое DNS зоны из локального источника, и таким образом, он может отвечать на запросы по этой зоне без необходимости обращаться к другим серверам. 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.
Списочный Сервер - авторитетный сервер, для которого в зоне имеется запись "NS". 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.
Вторичный Сервер - авторитетный сервер, который получает информацию о зоне от Первичного Сервера через механизм пересылки зоны (zone transfer). Иногда его называют Подчиненный Сервер. 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.
Резолвер (разрешитель) - клиент системы DNS, который с помощью DNS протоколов ищет информацию, содержащуюся в зоне. Resolver A client of the DNS which seeks information contained in a zone using the DNS protocols.
3. Вторичные Сервера 3. Secondary Servers
Основная причина для наличия множественных серверов для каждой зоны - сделать информацию о зоне более доступной и достоверной для клиентов по всему Internet, а следовательно и по всему миру, даже в случае отсутствия или недоступности одного из серверов. 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.
Различие между первичным и вторичным серверами уместно только для тех серверов, которые имеют оношение к данной зоне; для остальной части системы DNS все они - обычные множественные сервера. Даже со стороны родительского (parent) сервера, который делегировал данную зону, все они равны и рассматриваются как первичная инстанция. Резолверы часто измеряют эффективность различных серверов, выбирая "лучший" по тем или иным параметрам, и предпочтительно к нему направляют запросы. Это механизм работает автоматически и не рассматривается в данном документе. 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.
Первичный сервер хранит мастер-копию (оригинал) файла зоны. Таким образом, это сервер, через который данные входят в систему DNS из некоторого источника вне DNS. Вторичный сервер получает данные из зоны, используя механизмы протокола DNS для получения зоны от первичного сервера. 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. Подбор вторичных серверов 3.1. Selecting Secondary Servers
При подборе вторичного сервера особое внимание нужно обратить на различные модели вероятных отказов и повреждений. Сервера должны располагаться так, чтобы при любых возможных повреждениях по меньшей мере один сервер был доступен для всех существенных частей Internet. 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. Неподходящая конфигурация 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.
3.3. Развенчание мифа 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.
+ DNS клиенты по-разному реагируют на невозможность разрешить имя и на невозможность связаться с сервером; в последнем случае реакция клиента не всегда подходящая. + 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.
+ Тогда как положительные результаты на DNS запросы обычно сохраняются в кеш-памяти, отсутствие результата не фиксируетя в кеш-пямяти. Таким образом, неудачные попытки разрешить имя создают дополнительную нежелательную нагрузку на сеть. + 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. Недоступные сервера 4. Unreachable servers
Еще один класс проблем возникает, если в списке серверов указаны сервера, к которым невозможно обратиться из большей части сети. Такое происходит, если машина полностью изолированна от сети за сетевым экраном, или просто если второй адрес машины, имеющие подключение сразу к двум сетям, недоступен извне. Имена серверов, перечисленные в NS записях, должны разрешаться в адреса, доступные из того региона, для которого предназначен ответ, содержащий эти записи. Включение адресов, которые находятся вне пределов досягаемости большей части сети, совсем не увеличивает надежность, и может привести к ряду проблем, которые в конце концов уменьшат общую надежность зоны. 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.
Во-первых, единственный способ, которым резолвер может определить, доступен данный адрес или нет, это попробовать обратиться к нему. Затем он должен выдержать время ожидания (timeout) ответа (или иногда сообщения об ICMP ошибке), чтобы убедиться, что данный адрес нельзя использовать. Более того, в общем случае даже это нельзя отличить от простой потери пакета, поэтому всю последовательность действий надо повторить несколько раз, что даст реальные основания судить о недоступности сервера. Все эти попытки и ожидания могут занять достаточно много времени и привести к тому, что клиентская программа или пользователь решат, что отсутствие ответа означает отсутствие данной зоны. Кроме того, всю процедуру нужно время от времени повторять, чтобы отличить временную недоступность сервера от постоянной. 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.
Наконец, потенциально все резолверы по всей сети должны будут проделать все эти действия. Это увеличит трафик и по-видимому нагрузку на фильтры, если какой-либо сетевой экран (firewall) блокирует доступ (к серверу). Такая дополнительная нагрузка не даст ничего, кроме действительного снижения надежности сервиса. 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. Сервера, использующие непостоянное соединение. 4.1. Servers behind intermittent connections
Аналогичная проблема возникает с DNS серверами, расположенных на участках сети, обычно целиком отключенных от Интернет. Например, сервер использует непостоянное соединение, которое большую часть времени отсутствует. Такие сервера нужно трактовать так же, как будто они находятся за сетевым экраном и постоянно недоступны для остальной сети. 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. Другие трудные случаи. 4.2. Other problem cases
Подобные проблемы возникают, если между резолвером и сервером существует Транслятор Сетевых Адресов (NAT) [RFC1631]. Несмотря на рекомендации [RFC1631], практически NAT не преобразует адреса, встроенные в пакеты, а только адреса, указанные в заголовке пакета. Как указывает [RFC1631], это отчасти является проблемой для DNS. Ее можно преодолеть, если дополнить или заменить NAT на шлюз прикладного уровня (ALG). Такое устройство понимало бы DNS протокол и надлежащим образом преобразовывало все адреса в проходящих через него пакетах. Но даже с таким устройством во всех подобных случаях лучше применять решение, описанное в следующей секции. 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. Решение. 4.3. A Solution
Чтобы избежать подобных проблем, любой ответ о NS записях для зоны должен перечислять только те сервера, которые вероятно будут в пределах досягаемости резолвера, запросившего информацию. Некоторые резолверы одновременно выполняют поиск в интересах других резолверов. В таких случаях возвращаемые NS записи должны быть доступны не только для резолвера, запросившего информацию, но и другого резолвера, которому эта информация может передаваться (forward). Все адреса всех серверов, содержащихся в ответе, должны быть доступны. Для каждого сервера необходимо возращать все (или ни одного) адреса из Набора Записей Ресурса [RFC2181]; таким образом неприемлемо опускать адреса серверов, к которым нельзя обратиться, или возвращать их с меньшим TTL (тогда как для других серверов возвращать больший TTL). 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).
В частности, если сервера находятся за сетевым экраном, непостоянным соединением или NAT, которые препятствуют или создают проблемы для DNS запросов или ответов, то их имена или адреса не должны возвращаться клиентам, находящихся снаружи сетевого экрана. Аналогично, о серверах, расположенных снаружи сетевого экрана, не нужно знать клиентам, находящихся внутри, если клиенты не смогут послать запрос к такому серверу. В этих случаях обычно требуется "двойная" настройка DNS (из двух частей), одна для внутренного использования, другая для внешнего. Такая схема часто помогает решить и другие проблемы с подобным окружением. 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 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.
Если сервер находится на границе сетевого экрана, доступный с обоих сторон, но использующий различные адреса, такому серверу нужно давать два имени, каждому из которых приписаны соответствующие A записи, видимые только для той стороны сетевого экрана, с которой они доступны. Они должны рассматриваться просто как два (отдельных) сервера, по одному с каждой стороны сетевого экрана. Именно такому случаю соответствует сервер, поддерживающий ALG. Требуется обратить особое внимание, чтобы такой сервер возвращал правильные ответы клиентам с каждой стороны. То есть, возвращал только информацию об узлах (хостах), доступных с данной стороны, и правильный адрес(а) узла с точки зрения соответствующей стороны. 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.
Для серверов в такой среде часто требуется предпринимать меры, чтобы обеспечить им доступ к корневым серверам. Это можно достичь использованием конфигурации "фальшивый корень" - "fake root". В таком случае нужно тщательно изолировать такие сервера от остальной части DNS, чтобы не дать их необычной конфигурации повлиять на других. 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. Сколько необходимо вторичных серверов? 5. How many secondaries?
Спецификация DNS и правила регистрации доменных имен требуют по меньшей мере двух серверов для каждой зоны. Обычно это первичный сервер и один вторичный сервер. Хотя часто бывает достаточно двух серверов, расположение которых тщательно продумано, нередки случаи, когда требуется больше серверов, и поэтому мы рекомендуем использвать более двух списочных серверов. Если сервер недоступен достаточно продолжительное время, могут возникнуть ряд проблем - фактически все это время зона с двумя списочными серверами будет работать только на одном сервере. Поскольку любой сервер может оказаться временно недоступным по какой-либо причине, то получится, что для данной зоны нет ни одного работающего сервера. 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.
С другой стороны, наличие большого количества серверов приносит небольшие выгоды, хотя и увеличивает расходы. Самое простое: чем больше серверов, тем больше размер пакета, что потребует большей пропуской способности. Это может показаться и на самом деле есть не очень существенным. Однако, существует ограничение на размер DNS пакета, и превышение этого ограничения более серьезно влияет на производительность. Важно хорошо это понимать. Кроме того, чем больше серверов, тем больше вероятность, что один из них будет неправильно настроен или неверно функционировать и это не будет обнаружено. 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 occasionally three of five, would be at the local site, with the others not geographically or topologically close to the site, or each other.
Обратная зона, т.е. поддомен in-addr.arpa, является менее критичной и для нее достаточно меньше серверов и менее распределенных. Это объясняется тем, что преобразование адреса в имя обычно нужно только, когда пакеты приходят с адреса, указанного в запросе, и только резолверами в пункте назначения пакетов или около него. Это дает некоторую уверенность, что сервера, расположенные около источника пакета, например, в той же сети, будут также доступны для резолвера, выполняющего поиск. Таким образом, некоторые модели неисправностей, которые нужно учитывать при планировании серверов для прямой зоны, можно не принимать во внимание при планировании обратной зоны. 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. Скрытые сервера. 5.1. Stealth Servers
Сервера, которые являются авторитетными для данной зоны, но не указаны в списке NS записей (также известные как "скрытые" сервера), не включаются в число серверов. 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.
Перечисление всех таких серверов в NS записях, если их более одного или двух, привело бы к тому, что остальной Интернет тратил бы напрасные усилия связаться со всеми серверами на этом узле, когда весь узел целиком был недоступен из-за нарушения связи или маршрутизации. 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. Нахождение подходящего вторичного сервера 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 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. Обслуживание серийного номера зоны 7. Serial Number Maintenance
Вторичный сервер использует серийный номер в SOA записи зоны для определения, когда необходимо обновить свою локальную копию данной зоны. Серийный номер является по существу просто 32 битовым беззнаковым целым числом, которое циклически переходит от наибольшей возможной величины снова к нулю. Более строгое определение серийного номера дано в [RFC1982]. 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.
Например, предположим, что серийный номер зоны был 10, но случайно был установлен 1000, и желательно вернуть его к 11. Не делайте простой замены величины 1000 на 11. Вторичный сервер, который уже обнаружил значение 1000 (а на практике, всегда есть по меньшей мере один такой сервер) проигнорирует эти изменения и будет продолжать использовать версию зоны с серийным номером 1000 до тех пор, пока серийный номер первичного сервера не превысит это значение. Это может продолжаться довольно долго - фактически на вторичном сервере очень часто успевает истечь срок актуальности зоны (expire) еще до того, как она снова будет обновлена. 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.
Вместо этого, для данного примера установите серийный номер первичного сервера 2000000000, и подождите, пока все вторичные сервера обновят у себя эту зону. Значение 2000000000 выбрано как величина, которая намного больше текущего значения, но меньше, чем 2^31 (2^31 равно 2147483648). Таким образом, это означает увеличение серийного номера [RFC1982]. 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].
Далее, после того, как все сервера, которым нужно обновить зону, получат зону с этим серийным номером, можно установить номер 4000000000. 4000000000 в 2000000000 раз больше, чем 2000000000 (что очевидно), и, таким образом, является еще одним увеличением (добавили величину, которая меньше 2^31). 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 is thus another increment (the value added is less than 2^31).
Как только эта копия файла зоны появится на всех серверах, серийный номер можно просто установить 11. По арифметике серийных номеров замена 4000000000 на 11 - это увеличение (инкремент). Серийный номер циклически переходит значение 2^32 (4294967296), таким образом, 11 идентично 4294967307 (4294967296 + 11). 4294967307 - это просто на 294967307 больше, чем 4000000000, а 294967307 точно меньше 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.
Сервер, не выполняющий данный алгоритм, является неисправным, и его можно выявить таким способом. На некотором шаге, обычно когда абсолютная интегральная величина серийного номера станет меньше, сервер именно с таким дефектом будет игнорировать изменения. Сервера с таким типом дефекта можно выявить, подождав по меньшей мере время, указанное в SOA в поле refresh, и затем послав запрос на SOA запись. Сервера с такой неисправностью будут по-прежнему выдавать старый серийный номер. Мы не осведомлены о других способах выявления этого дефекта. 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.
Вопросы безопасности Security Considerations
Маловероятно, чтобы что-либо в данном документе прибавило сведений по любым вопросам безопасности, которые могут касаться DNS, или сделало что-либо для уменьшения их. 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 и Yakov Rekhter посоветовали упомянуть NAT и ALG в тексте о сетвом экране. Dave Crocker посоветовал явно развенчать миф 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

		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