Request for Comments: 2870, Сервери, Інтернет-технології, статті

Copyright (C) The Internet Society (2000). All Rights Reserved
Переклад на російську мову – С.Ткаченко, А.А. Балакін
Зауваження, коментарі – sveta@net.ua
















































































































































































































































































































































































Кореневий Сервер імен.

Експлуатаційні Вимоги


(Замінює застаріле RFC 2010)


Категорія: краща практика


R. Bush, Verio


D. Karrenberg, RIPE NCC


M. Kosters, Network Solutions

R. Plzak, SAIC


Root Name Server Operational Requirements



 


 


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” або “привілейований користувач” обов’язково повинен бути дозволений не інакше, як тільки через проміжний користувальницький вхід.

Сервери зобов’язані мати механізм захисту для віддаленого доступу адміністраторів системи та технічного обслуговування. Поломки неминучі; навіть вимога підтримки 24×7 (пункт 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 24×7 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.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*