Request for Comments: 2870 June 2000

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" ХКХ "ОПХБХКЕЦХПНБЮММШИ ОНКЭГНБЮРЕКЭ" НАЪГЮРЕКЭМН ДНКФЕМ АШРЭ ПЮГПЕЬЕМ МЕ ХМЮВЕ, ЙЮЙ РНКЭЙН ВЕПЕГ ОПНЛЕФСРНВМШИ ОНКЭГНБЮРЕКЭЯЙХИ БУНД.

яЕПБЕПШ НАЪГЮМШ ХЛЕРЭ ЛЕУЮМХГЛ ГЮЫХРШ ДКЪ СДЮКЕММНЦН ДНЯРСОЮ ЮДЛХМХЯРПЮРНПНБ ЯХЯРЕЛШ Х РЕУМХВЕЯЙНЦН НАЯКСФХБЮМХЪ. оНКНЛЙХ МЕХГАЕФМШ; ДЮФЕ РПЕАНБЮМХЕ ОНДДЕПФЙХ 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.

   

7. юДПЕЯЮ ЮБРНПНБ

7. Authors' Addresses

		Randy Bush
		Verio, Inc.
		5147 Crystal Springs
		Bainbridge Island, WA US-98110

		Phone: +1 206 780 0431
		EMail: randy@psg.com

		Daniel Karrenberg
		RIPE Network Coordination Centre (NCC)
		Singel 258
		NL-1016 AB  Amsterdam
		Netherlands

		Phone: +31 20 535 4444
		EMail: daniel.karrenberg@ripe.net

		Mark Kosters
		Network Solutions
		505 Huntmar Park Drive
		Herndon, VA 22070-5100

		Phone: +1 703 742 0400
		EMail: markk@netsol.com


		Raymond Plzak
		SAIC
		1710 Goodridge Drive
		McLean, Virginia 22102
		+1 703 821 6535

		EMail: plzakr@saic.com
 

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.

9. Full Copyright Statement

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

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.