Эксплуатационные Требования
(заменяет устаревшее RFC 2010)
Категория: лучшая практика
R. Bush, Verio
D. Karrenberg, RIPE NCC
M. Kosters, Network Solutions
R. Plzak, SAIC |
Category: Best Current Practice
R. Bush, Verio
D. Karrenberg, RIPE NCC
M. Kosters, Network Solutions
R. Plzak, SAIC |
Июнь 2000 |
June 2000 |
|
|
Статус документа |
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 |
|
|
Поскольку Интернет оказывает все большее влияние на мировую
социальную и экономическую инфраструктуру, особое внимание должно быть обращено
на правильную, безопасную, надежную и гарантированную работу собственно самой
инфраструктуры Интернет. Корневые серверы доменных имен
рассматриваются как критическая часть этой технической
инфраструктуры. Основная задача этого документа - определение
руководящих принципов работы корневых серверов доменных имен. Операторы других
больших зон (gTLD, ccTLD, большие зоны) могут также найти его полезным. Эти
руководящие принципы предназначены для удовлетворения отмеченных социальных
потребностей без чрезмерно описания технических деталей |
As the Internet becomes increasingly critical to the world's
social and economic infrastructure, attention has rightly focused on the
correct, safe, reliable, and secure operation of the Internet infrastructure
itself. The root domain name servers are seen as a crucial part of that
technical infrastructure. The primary focus of this document is to provide
guidelines for operation of the root name servers. Other major zone server
operators (gTLDs, ccTLDs, major zones) may also find it useful. These guidelines
are intended to meet the perceived societal needs without overly prescribing
technical details. |
|
|
1. История |
1. Background |
|
|
Способность различать имена доменов в Интернет существенно
зависит от надлежащей, точной и безопасной работы корневого сервера доменных
имен. В настоящее время эта дюжина (или около того) серверов обслуживается очень
компетентной и доверенной группой добровольцев. Этот документ не предлагает
изменить существующий порядок, но создан для того, чтобы определить формальные
руководящие принципы таким образом, чтобы сообщество поняло как и почему это
сделано. |
The resolution of domain names on the internet is critically
dependent on the proper, safe, and secure operation of the root domain name
servers. Currently, these dozen or so servers are provided and operated by a
very competent and trusted group of volunteers. This document does not propose
to change that, but merely to provide formal guidelines so that the community
understands how and why this is done. |
|
|
|
1.1. Обеспечение работоспособности корневых серверов возложено
на Интернет корпорацию для назначения имен и номеров (The
Интернет Corporation for Assigned Names and Numbers - ICANN ).
ICANN в свою очередь создал Консультативный Комитет Системы
Корневых Серверов (Root Server System Advisory Committee -
RSSAC) для предоставления технической и организационной помощи членам
ICANN.
ICANN и RSSAC обращаются к IETF (Internet
Engineering Task Force) за разработкой технических (инженерных)
стандартов. |
1.1.The Internet Corporation for Assigned Names and Numbers
(ICANN) has become
responsible for the operation of the root servers.
The ICANN has appointed
a Root Server System Advisory Committee (RSSAC) to give technical and operational advice to
the ICANN board.
The ICANN and the
RSSAC look to the IETF to provide engineering
standards. |
|
|
1.2. Корневые серверы обслуживают корневую зону (зону
"точка" - "."). Впрочем, сегодня некоторые из корневых
серверов также обслуживают и отдельные домены верхнего уровня (TLD - top
level domains), такие как gTLD (.com, .net, .org), инфраструктурные
домены верхнего уровня (int и in-addr.arpa) и некоторые географические домены
верхнего уровня (ccTLD - country code TLDs),например
SE -Швеция). Подобная ситуация требует изменений (см.
2.5). |
1.2 The root servers serve the root, aka ".", zone. Although today some of the
root servers also serve some TLDs (top level domains) such as gTLDs (COM, NET, ORG, etc.), infrastructural TLDs such as INT and IN-ADDR.ARPA, and some ccTLDs (country code TLDs, e.g. SE for Sweden), this is likely to change (see
2.5). |
|
|
1.3. Корневые серверы (их содержание) не связаны и не
основываются на данных службы 'whois'. |
1.3 The root servers are neither involved with nor dependent upon the
'whois'
data. |
|
|
1.4 Система доменных имен, как доказывает практика, является
настолько надежной, что мы уверены в том, что отключение (по крайней мере
временное) большинства корневых серверов не должно заметно сказаться на работе
Интернет. |
1.4 The domain name system has proven to be sufficiently robust that we are
confident that the, presumably temporary, loss of most of the root servers
should not significantly affect operation of the internet. |
|
|
1.5. Опыт работы показывает, что Интернет обладает повышенной
чувствительностью к некорректности данных в корневой зоне или зонах доменов
высшего уровня (TLD). Поэтому аутентификация, целостность и безопасность данных
требуют особого внимания. |
1.5 Experience has shown that the Internet is quite vulnerable to incorrect
data in the root zone or TLDs. Hence authentication, validation, and security of
these data are of great concern. |
|
|
2. Серверы |
2. The Servers Themselves |
|
|
Следующие пункты являются требованиями к техническим деталям
корневых серверов. |
The following are requirements for the technical details of the root servers
themselves: |
|
|
2.1. Было бы неразумно в данном документе определять конкретное
аппаратное обеспечение, операционные системы или программное обеспечение,
обслуживающие систему имен. Отличия в этих областях должны прежде всего
увеличивать надежность и устойчивость. |
2.1 It would be short-sighted of this document to specify particular
hardware, operating systems, or name serving software. Variations in these areas
would actually add overall robustness. |
|
|
2.2. Каждый сервер обязан работать под управлением
программного обеспечения, которое корректно выполняет требования стандартов IETF
для DNS (на сегодня это RFC 1035, 2181). Хотя не существует формальных тестов на
соответствие этим стандартам, пользователи и разработчики программного
обеспечения, используемого для корневых серверов, предпринимают все необходимые
меры, чтобы согласовать его с текущими документированными рекомендациями
IETF. |
2.2 Each server MUST run software which correctly implements the IETF
standards for the DNS, currently [RFC1035] [RFC2181]. While there are no formal
test suites for standards compliance, the maintainers of software used on root
servers are expected to take all reasonable actions to conform to the IETF's
then current documented expectations. |
|
|
2.3. В любой момент каждый сервер обязан быть способен
обработать поток запросов на данные из корневой зоны, который втрое превышает
зафиксированный пиковый поток таких запросов на наиболее загруженном сервере при
текущих нормальных условиях. Обычно эта величина выражается в запросах в
секунду. Это требование обеспечивает непрерывную работу службы корневых имен
даже в случае, когда две трети всех серверов будут отключены намеренно, или в
результате несчастного случая либо по злому умыслу. |
2.3 At any time, each server MUST be able to handle a load of
requests for root data which is three times the measured peak of such requests
on the most loaded server in then current normal conditions. This is usually
expressed in requests per second. This is intended to ensure continued operation
of root services should two thirds of the servers be taken out of operation,
whether by intent, accident, or malice. |
|
|
2.4. Каждый корневой сервер должен иметь соответствующую связь
с Интернет для поддержания ограниченных требований, изложенных выше. Связь с
Интернет должна быть настолько разнообразной, насколько это возможно.
Корневые сервера должны иметь механизм для IP-подключения к корневому серверу
любого Интернет провайдера, обеспечивающего связь за свой счет. |
2.4 Each root server should have sufficient connectivity to the Internet to
support the bandwidth needs of the above requirement. Connectivity to the
Internet SHOULD be as diverse as possible. Root servers SHOULD have mechanisms
in place to accept IP connectivity to the root server from any Internet provider
delivering connectivity at their own cost. |
|
|
2.5. Серверы обязаны давать авторизованные ответы только
из зон, которые они обслуживают. Серверы обязаны отключить рекурсивные
поиск (lookup), перенаправление (forwarding) и любые другие функции, которые
могли бы позволить ему использовать заранее подготовленные ответы (cached
answers). Они также обязаны не предоставлять иной сервис
(secondary) для любых зон, отличающихся от корневой зоны (root) и зоны
root-servers.net. Эти ограничения помогают предотвратить чрезмерную нагрузку на
корневые серверы и уменьшают риск накопления в кеш-памяти недостоверных
(устаревших)данных. |
2.5 Servers MUST provide authoritative responses only from the zones they
serve. The servers MUST disable recursive lookup, forwarding, or any other
function that may allow them to provide cached answers. They also MUST NOT
provide secondary service for any zones other than the root and root-servers.net
zones. These restrictions help prevent undue load on the root servers and reduce
the chance of their caching incorrect data. |
|
|
2.6. Корневые серверы обязаны отвечать на запросы от
любого Интернет узла (host), т.е. не могут блокировать запросы о
корневых именах ни с какого правильного ip-адреса, за исключением запросов,
которые приводят к проблемам в функционировании сервера. В этом случае
блокировка должна длиться только то время, пока существует проблема и
быть настолько избирательной, насколько это возможно. |
2.6 Root servers MUST answer queries from any Internet host, i.e. may not
block root name resolution from any valid IP address, except in the case of
queries causing operational problems, in which case the blocking SHOULD last
only as long as the problem, and be as specific as reasonably
possible. |
|
|
2.7. Корневые сервера не должны отвечать на
AXFR запросы или другие запросы на передачу зоны, поступающие от любых
клиентов кроме других корневых серверов. Это ограничение, кроме всего прочего,
призвано предотвратить излишнюю нагрузку на корневые сервера, к которой приводит
следование совету "чтобы избежать проблем с кешированием сделай свой сервер
скрытыи вторичным сервером корневой зоны". Корневые сервера могут
располагать файл корневой зоны для доступа через ftp или другие средства доступа
на одном или нескольких менее критичных серверах. |
2.7 Root servers SHOULD NOT answer AXFR, or other zone transfer, queries from
clients other than other root servers. This restriction is intended to, among
other things, prevent unnecessary load on the root servers as advice has been
heard such as "To avoid having a corruptible cache, make your server a
stealth secondary for the root zone." The root servers MAY put the root
zone up for ftp or other access on one or more less critical
servers. |
|
|
2.8. Серверы обязаны генерировать контрольные суммы при
посылке UDP датаграмм и обязаны проверять контрольные суммы при получении
UDP датаграмм, содержащих ненулевую контрольную сумму. |
2.8 Servers MUST generate checksums when sending UDP datagrams and MUST
verify checksums when receiving UDP datagrams containing a non-zero
checksum. |
|
|
3. Соглашения о безопасности |
3. Security Considerations |
|
|
Серверам необходимо обеспечить как физическую, так и
алгоритмическую (протокольную) безопасность, также как и однозначную
аутентификацию своих ответов. |
The servers need both physical and protocol security as well as unambiguous
authentication of their responses. |
|
|
3.1. Физическая безопасность обязательно должна быть
обеспечена на уровне, принятом для центров обработки критических данных больших
корпораций. |
3.1 Physical security MUST be ensured in a manner expected of data centers
critical to a major enterprise. |
|
|
3.1.1. Независимо от того, имеется ли вообще контроль доступа в
зону, в которой находится корневой сервер, обязательно должен быть
обеспечен действенный контроль доступа к месту расположения сервера, т.е. число
лиц, имеющих доступ в зону, обязательно должен быть ограничен,
контролироваться и фиксироваться. Как минимум, в качестве мер контроля
должны использоваться либо механические, либо электронные замки.
Физическая безопасность может быть повышена использованием детекторов
вторжения, сенсоров движения, множества последовательных точек контроля,
охранников и др. |
3.1.1 Whether or not the overall site in which a root server is located has
access control, the specific area in which the root server is located MUST have
positive access control, i.e. the number of individuals permitted access to the
area MUST be limited, controlled, and recorded. At a minimum, control measures
SHOULD be either mechanical or electronic locks. Physical security MAY be
enhanced by the use of intrusion detection and motion sensors, multiple serial
access points, security personnel, etc. |
|
|
3.1.2. Если только нет документальных свидетельств о том, что
локальная электросеть более надежна, чем среднее время безотказной работы (MTBF)
устройства бесперебойного питания UPC (т.е. от 5 до 10 лет), необходимо
обеспечить бесперебойное электропитание как минимум в течение 48 часов,
используя либо автономные батареи, либо электрогенератор или их комбинацию.
Резервная система электропитания обязана обеспечивать электроэнергией как
собственно сервер, так и инфраструктуру, необходимую для связи сервера с
Internet. Обязательно должны выполняться процедуры по
проверке механизмов перехода на запасную схему электропитания и проверка
электрооборудования должна производиться не реже, чем указано и рекомендовано
производителями оборудования. |
3.1.2 Unless there is documentable experience that the local power grid is
more reliable than the MTBF of a UPS (i.e. five to ten years), power continuity
for at least 48 hours MUST be assured, whether through on-site batteries, on-
site power generation, or some combination thereof. This MUST supply the server
itself, as well as the infrastructure necessary to connect the server to the
internet. There MUST be procedures which ensure that power fallback mechanisms
and supplies are tested no less frequently than the specifications and
recommendations of the manufacturer. |
|
|
3.1.3. Необходимо иметь детектор огня и / или
возгорания. |
3.1.3 Fire detection and/or retardation MUST be
provided. |
|
|
3.1.4. Необходимо обеспечить быстрый возврат к
работе после сбоя системы. Это должно включать резервное копирование системного
программного обеспечения и конфигурационных файлов. Кроме того, должно быть
предусмотрено резервирование (дублирование) аппаратных средств, которые должны
быть заранее сконфигурированы и готовы к работе вместо основного оборудования,
что может потребовать использования ручных операций . |
3.1.4 Provision MUST be made for rapid return to operation after a system
outage. This SHOULD involve backup of systems software and configuration. But
SHOULD also involve backup hardware which is pre-configured and ready to take
over operation, which MAY require manual procedures. |
|
|
3.2. Сетевая безопасность должна соответствовать уровню
безопасности, принятому для критической инфраструктуры больших коммерческих
корпораций. |
3.2 Network security should be of the level provided for critical
infrastructure of a major commercial enterprise. |
|
|
3.2.1. Собственно корневые серверы кроме сервиса корневых имен
обязаны не предоставлять иные сетевые услуги, например, Интернет
протоколы удаленного доступа, такие как http, telnet, rlogin, ftp и т.д.
Единственные разрешенные логические входы (logins) в систему должны быть для
администратора (ов) сервера. Непосредственный вход "root" или
"привилегированный пользователь" обязательно должен быть
разрешен не иначе, как только через промежуточный пользовательский вход.
Серверы обязаны иметь механизм защиты для удаленного
доступа администраторов системы и технического обслуживания. Поломки неизбежны;
даже требование поддержки 24x7 (пункт 4.5) не дает гарантии, что не произойдет
что-нибудь непредвиденное и не потребуется удаленное вмешательство
высококвалифицированного специалиста. Удаленные входы в
систему(logins) обязательно должны быть защищены
шифрованием и строгой аутентификацией, а узлы (машины), с которых разрешен
удаленный вход, обязательно должны быть защищены и
укреплены. |
3.2.1 The root servers themselves MUST NOT provide services other than root
name service e.g. remote Internet protocols such as http, telnet, rlogin, ftp,
etc. The only login accounts permitted should be for the server
administrator(s). "Root" or "privileged user" access MUST
NOT be permitted except through an intermediate user account.
Servers MUST have a secure mechanism for remote administrative access and
maintenance. Failures happen; given the 24x7 support requirement (per 4.5),
there will be times when something breaks badly enough that senior wizards will
have to connect remotely. Remote logins MUST be protected by a secure means that
is strongly authenticated and encrypted, and sites from which remote login is
allowed MUST be protected and hardened. |
|
|
3.2.2. Корневые сервера имен не должны доверять другим
узлам (кроме вторичных серверов, которые доверяют первичному серверу) в сфере
аутентификации, ключей шифрования или иного доступа, а также информации защиты.
Если оператор Корневого сервера имен применяет аутентификацию с использованием
Центра сертификации ключей, то соответствующий сервер Центра обязан быть
защищеным с той же тщательностью, что и сервер корневых имен. Это относится ко
всем соответствующим сервисам, которым корневой сервер доверяет в той или иной
мере. |
3.2.2 Root name servers SHOULD NOT trust other hosts, except secondary
servers trusting the primary server, for matters of authentication, encryption
keys, or other access or security information. If a root operator uses kerberos
authentication to manage access to the root server, then the associated kerberos
key server MUST be protected with the same prudence as the root server itself.
This applies to all related services which are trusted in any
manner. |
|
|
3.2.3. Сегмент(ы) локальной сети, в которой расположен корневой
сервер, обязан не содержать узлы (хосты), система защиты которых
потенциально может быть преодолена, т.е. сегменты сети должны коммутироваться
или маршрутизироваться таким образом, чтобы исключить подмену. Некоторые сетевые
коммутаторы не соответствуют требованиям безопасности, т.к. были опубликованы
успешные попытки атак на их системы фильтрации. Хотя в большинстве случаев этот
недостаток можно устранить аккуратной настройкой коммутатора, благоразумнее их
вообще не использовать. Лучше всего, если сегмент локальной сети вообще не
содержит других хост-систем. |
3.2.3 The LAN segment(s) on which a root server is homed MUST NOT also home
crackable hosts. I.e. the LAN segments should be switched or routed so there is
no possibility of masquerading. Some LAN switches aren't suitable for security
purposes, there have been published attacks on their filtering. While these can
often be prevented by careful configuration, extreme prudence is recommended. It
is best if the LAN segment simply does not have any other hosts on
it. |
|
|
3.2.4. Сетевой сегмент(ы), в котором расположен корневой
сервер, должен быть отдельно защищен с помощью межсетевого экрана
(firewall) или пакетной фильтрации, чтобы исключить сетевой доступ на любые
порты, кроме тех, которые нужны для службы имен. |
3.2.4 The LAN segment(s) on which a root server is homed SHOULD be separately
firewalled or packet filtered to discourage network access to any port other
than those needed for name service. |
|
|
3.2.5. Корневые серверы должны иметь свою временную
синхронизацию в соответствии с NTP (Временное согласование в сети -
Network Time Protocol) (RFC1305, RFC2030) или аналогичному механизму,
надежную настолько, насколько это возможно. Для этих целей серверы и связанные с
ними межсетевые экраны должны позволять корневым серверам быть клиентами NTP.
Корневые серверы обязаны не работать как NTP партнер
или NTP-сервер. |
3.2.5 The root servers SHOULD have their clocks synchronized via NTP
[RFC1305] [RFC2030] or similar mechanisms, in as secure manner as possible. For
this purpose, servers and their associated firewalls SHOULD allow the root
servers to be NTP clients. Root servers MUST NOT act as NTP peers or
servers. |
|
|
3.2.6. Все попытки вторжения или других несанкционированных
действий должны протоколироваться, и все такие протоколы со всех корневых
серверов должны анализироваться общей группой безопасности,
контактирующей с операторами всех серверов для выявления моделей вторжения,
серьезных попыток и др. Серверы должны вести протоколы в GMT (глобальное
время), чтобы обеспечить возможность сравнения протокольных
записей. |
3.2.6 All attempts at intrusion or other compromise SHOULD be logged, and all
such logs from all root servers SHOULD be analyzed by a cooperative security
team communicating with all server operators to look for patterns, serious
attempts, etc. Servers SHOULD log in GMT to facilitate log
comparison. |
|
|
3.2.7. Сервер протоколирования должен быть отдельным
хостом, который должен быть защищен точно также, как и корневой
сервер. |
3.2.7 Server logging SHOULD be to separate hosts which SHOULD be protected
similarly to the root servers themselves. |
|
|
3.2.8. Сервер должен быть защищен от атак, базирующихся
на источнике данных маршрутизации. Сервер обязан не полагаться на
аутентификацию, основанною на адресе или имени. |
3.2.8 The server SHOULD be protected from attacks based on source routing.
The server MUST NOT rely on address- or name-based
authentication. |
|
|
3.2.9. Сеть, в которой расположен сервер, должна иметь
службу in-addr.arpa. |
3.2.9 The network on which the server is homed SHOULD have in-addr.arpa
service. |
|
|
3.3. Протокольное подтверждение подлинности и безопасности
требуются для подтверждения того, что данные, предоставленные корневыми
серверами, поступили именно с серверов, авторизованных для хранения данных
корневой зоны. |
3.3 Protocol authentication and security are required to ensure that data
presented by the root servers are those created by those authorized to maintain
the root zone data. |
|
|
3.3.1. Корневая зона обязательно должна быть подписана
IANA (Интернет Assigned Numbers Authority) в соответствии с протоколами DNSSEC
(RFC 2535) или протоколами следующего поколения. Известно, что DNSSEC еще не
поддерживается некоторыми общими платформами, однако он должен использоваться
когда поддержка будет обеспечена. |
3.3.1 The root zone MUST be signed by the Internet Assigned Numbers Authority
(IANA) in accordance with DNSSEC, see [RFC2535] or its replacements. It is
understood that DNSSEC is not yet deployable on some common platforms, but will
be deployed when supported. |
|
|
3.3.2. Корневые сервера обязательно должны быть
DNSSEC-совместимыми, таким образом, чтобы запросы могли быть аутентифицированы
клиентами с целью обеспечения безопасности и идентификации. Известно, что DNSSEC
еще не поддерживается некоторыми общими платформами, однако он должен
использоваться, когда поддержка будет обеспечена. |
3.3.2 Root servers MUST be DNSSEC-capable so that queries may be
authenticated by clients with security and authentication concerns. It is
understood that DNSSEC is not yet deployable on some common platforms, but will
be deployed when supported. |
|
|
3.3.3. Передача корневой зоны между корневыми серверами
обязательно должна осуществляться с аутентификацией и быть насколько
возможно безопасной. Вне зоны безопасности достоверность обновлений
обязательно должна обеспечиваться. Сервер обязан использовать
DNSSEC для аутентификации корневой зоны, полученной с других серверов. Известно,
что DNSSEC еще не поддерживается некоторыми общими платформами, однако он должен
использоваться когда поддержка будет обеспечена. |
3.3.3 Transfer of the root zone between root servers MUST be authenticated
and be as secure as reasonably possible. Out of band security validation of
updates MUST be supported. Servers MUST use DNSSEC to authenticate root zones
received from other servers. It is understood that DNSSEC is not yet deployable
on some common platforms, but will be deployed when
supported. |
|
|
3.3.4. Можно использовать "скрытый"
первичный сервер (hidden primary), который разрешает доступ только с
авторизованных вторичных корневых серверов. |
3.3.4 A 'hidden primary' server, which only allows access by the authorized
secondary root servers, MAY be used. |
|
|
3.3.5. Внесение изменений в корневую зону должно
происходить только после успешного завершения ряда эвристических проверок,
разработанных для обнаружения ошибочных изменений. Если изменения не прошли
тесты, необходимо вмешательство человека-администратора. |
3.3.5 Root zone updates SHOULD only progress after a number of heuristic
checks designed to detect erroneous updates have been passed. In case the update
fails the tests, human intervention MUST be requested. |
|
|
3.3.6. Изменения в корневую зону должны быть внесены не
позднее, чем через 6 часов от момента уведомления оператора корневого
сервера. |
3.3.6 Root zone updates SHOULD normally be effective no later than 6 hours
from notification of the root server operator. |
|
|
3.3.7. Должна быть определена специальная
процедура внесения изменений в аварийном режиме. Изменения, происходящие по этой
процедуре, должны быть сделаны не позднее, чем через 12 часов после
уведомления. |
3.3.7 A special procedure for emergency updates SHOULD be defined. Updates
initiated by the emergency procedure SHOULD be made no later than 12 hours after
notification. |
|
|
3.3.8. В случае возникновения сетевой аварии каждый корневой
сервер обязан иметь метод обновления данных в корневой зоне с
использованием средства, которое поставляется по альтернативному несетевому
пути. |
3.3.8 In the advent of a critical network failure, each root server MUST have
a method to update the root zone data via a medium which is delivered through an
alternative, non- network, path. |
|
|
3.3.9. Каждый корневой сервер обязан ежедневно
накапливать полные статистические данные по количеству и типам запросов,
полученных и обработанных сервером. Эти статистический данные должны быть
доступными Консультативному Комитету Системы Корневых Серверов (RSSSAC) и
спонсируемым им исследователям, чтобы помочь им установить, как эффективнее
использовать ресурсы этих машин через Internet. Каждый корневой сервер
может накапливать данные за кванты времени, чтобы обнаруживать всплески
DNS запросов (штормы), существенные ошибки работы и пр. |
3.3.9 Each root MUST keep global statistics on the amount and types of
queries received/answered on a daily basis. These statistics must be made
available to RSSAC and RSSAC sponsored researchers to help determine how to
better deploy these machines more efficiently across the internet. Each root MAY
collect data snapshots to help determine data points such as DNS query storms,
significant implementation bugs, etc. |
|
|
4. Связь |
4. Communications |
|
|
Взаимодействие и координация между операторами корневых
серверов и между операторами и IANA и ICANN являются
необходимыми. |
Communications and coordination between root server operators and between the
operators and the IANA and ICANN are necessary. |
|
|
4.1. Плановые выключения и другие перерывы в работе
должны заранее согласовываться между операторами корневых серверов, чтобы
быть уваренным в том, что количество одновременно выключенных корневых серверов
не превышает допустимого. Заблаговременное предупреждение о планируемом простое
сервера также избавит других операторов от беспокойства по поводу аномалий в
работе их серверов. |
4.1 Planned outages and other down times SHOULD be coordinated between root
server operators to ensure that a significant number of the root servers are not
all down at the same time. Preannouncement of planned outages also keeps other
operators from wasting time wondering about any anomalies. |
|
|
4.2. Операторы корневого сервера должны согласовывать
время резервного копирования, чтобы количество серверов, одновременно занятых
копированием (и не отвечающих на DNS запросы) не превышало допустимого.
Резервные копии должны быть быстро переданы за пределы узла. |
4.2 Root server operators SHOULD coordinate backup timing so that many
servers are not off-line being backed up at the same time. Backups SHOULD be
frequently transferred off site. |
|
|
4.3. Операторы корневого сервера должны обмениваться
файлами протоколов (log files), особенно если они касаются безопасности,
загрузки и других существенных событий. Обмен может происходить через
центральный пункт координации или может быть неформальным. |
4.3 Root server operators SHOULD exchange log files, particularly as they
relate to security, loading, and other significant events. This MAY be through a
central log coordination point, or MAY be informal. |
|
|
4.4. Операторы должны обмениваться статистическими
данными, относящимися к использованию скоростей, загрузке и степени
использования ресурсов, и обязаны передавать эти данные в IANA для целей
планирования и отчетности. |
4.4 Statistics as they concern usage rates, loading, and resource utilization
SHOULD be exchanged between operators, and MUST be reported to the IANA for
planning and reporting purposes. |
|
|
4.5. Административный персонал корневого сервера имен обязан
быть способным предоставлять сервис 24 часа в день 7 дней в неделю.
Специалисты-совместители могут привлекаться к обеспечению этих услуг в нерабочее
время. |
4.5 Root name server administrative personnel MUST be available to provide
service 24 hours a day, 7 days per week. On call personnel MAY be used to
provide this service outside of normal working hours. |
|
|
5. Благодарности. |
5. Acknowledgements |
|
|
Авторы благодарят Scott Bradner, Robert Elz, Chris Fletcher,
John Klensin, Steve Bellovin, и Vern Paxson за их конструктивные
комментарии. |
The authors would like to thank Scott Bradner, Robert Elz, Chris Fletcher,
John Klensin, Steve Bellovin, and Vern Paxson for their constructive
comments. |
|
|
6. Ссылки |
6. References |
[RFC1035] Mockapetris, P., "Доменные имена - применение и
определение", STD 13, RFC 1035, ноябрь 1987.
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation", RFC 1305, March 1992.
[RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for
IPv4, IPv6 and OSI", RFC 2030, October 1996.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2535] Eastlake, D. and C. Kaufman, "Система
доменных имен - расширение требований безопасности", RFC 2535, март
1999. |
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation", RFC 1305, March 1992.
[RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for
IPv4, IPv6 and OSI", RFC 2030, October 1996.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2535] Eastlake, D. and C. Kaufman, "Domain Name System Security
Extensions", RFC 2535, March 1999. |
|
|
|
8. Specification of Requirements |
Ключевые слова 'обязан', 'обязан не' 'требует', 'должен',
'должен не',: в этом документе необходимо интерпретировать так, как это
описано в RFC 2119. |
The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC
2119.
Литература по Internet
|