(заменяет устаревшее RFC 2010)

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

Category: Best Current Practice

Июнь 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.