分享
 
 
 

RFC2010 - Operational Criteria for Root Name Servers

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

Network Working Group B. Manning

Request for Comments: 2010 ISI

Category: Informational P. Vixie

ISC

October 1996

Operational Criteria for Root Name Servers

Status of this Memo

This memo provides information for the Internet community. This memo

does not specify an Internet standard of any kind. Distribution of

this memo is unlimited.

Abstract

This document specifies the operational requirements of root name

servers, including host hardware capacities, name server software

revisions, network connectivity, and physical environment.

1 - Rationale and Scope

1.1. Historically, the name servers responsible for the root (".")

zone have also been responsible for all international top-level

domains (iTLD's, for example: COM, EDU, INT, ARPA). These name

servers have been operated by a cadre of highly capable volunteers,

and their administration has been loosely coordinated by the NIC

(first SRI-NIC and now InterNIC). Ultimate responsibility for the

correct operation of these servers and for the content of the DNS

zones they served has always rested with the IANA.

1.2. As described in [Postel96], many new TLD's may be created

shortly. Servers for all new and existing iTLD's will be subject to

the operational requirements given in [Postel96]. The set of servers

for the root (".") zone is likely to become disjoint from the set of

servers for any TLD or group of TLD's, including those maintained by

the InterNIC.

1.3. In spite of the similarities in operational requirements between

the servers for the iTLD's and the servers for the root (".") zone,

they are in fact different server sets with different administrators

and slightly different operational requirements. It is likely that

many contry code tld servers will have even more divergent

operational requirements. That said, the requirements set down in

this document could be sUCcessfully applied to any name server

(whether root, top level, or any other level), but may be more

draconian than necessary for servers other than those of the root

(".") zone.

Disclaimer: The selection of name server locations and

administrators, and the procedures for addressing

noncompliance with these stated operational

requirements, are outside the scope of this document.

Definition: For the purpose of this document, the term "zone master"

shall be used to designate the administrative owner of

the content of a zone. This person is eXPected to have

final responsibility for the selection and correct

operation of all of the zone's servers. For the root

(".") zone, this is the IANA.

2 - Operational Requirements

2.1. Name server software. The zone master shall initially and

periodically choose a name server package to run on all of the zone's

servers. It is expected that the BIND server will be used, at least

initially, and that new versions or other servers will be specified

from time to time.

Rationale: This requirement is based on the wide and free

availability of BIND's source code, and the active

analysis and development it constantly receives from

several members of the IETF.

Name server software upgrades will be specified and scheduled by the

zone master, and must occur on all of a zone's servers within a

specified 96 hour window.

Rationale: In some cases it has proven necessary to "cold start" a

zone's servers in order to clear out oscillating bad

data. By forcing all software upgrades to happen at

about the same time, it will be possible to coordinate

a software change with a zone content change.

2.2. UDP checksums. UDP checksums must be generated when sending

datagrams, and verified when receiving them.

Rationale: Some vendors turn off UDP checksums for performance

reasons, citing the presence of MAC-level frame checks

(CRC, for example) as "strong enough." This has been

a disaster in actual practice.

2.3. Dedicated host. A name server host should have no other

function, and no login accounts other than for system or network

administrators. No other network protocols should be served by a

name server host (e.g., SMTP, NNTP, FTP, et al). If login is

permitted from other than the system console, then the login service

must be by encrypted channel (e.g., Kerberized and encrypted

rlogin/telnet, the secure shell (SSH), or an equivilent).

Rationale: Each additional service performed by a host makes it

less reliable and potentially less secure, as well as

complicating fault isolation procedures. While name

service does not consume very much in the way of system

resources, it is thought best that a host do a few

things well rather than many things poorly.

2.4. Clock synchronization. A name server host should synchronize

its clock using the NTP protocol (currnet version) with

authentication. At least two NTP servers should be used. As an

exception to section 2.3 above, a name server host can be an NTP

server as well.

Rationale: For distributed fault isolation reasons, synchronized

time stamps in system event logs are quite helpful.

NTP is easily spoofed by UDP blast attacks, thus the

requirement for authentication between the name server

host and its NTP servers. A name server host is

allowed to be an NTP server because it has been

observed that a single host running both name service

and stratum 1 NTP is still quite reliable and secure.

2.5. Network interfaces. Name servers must send UDP responses with

an IP source address (and UDP source port number) equal to the IP

destination address (and UDP destination port number) of the request.

Also, a name server might have multiple real interfaces, but only one

will be advertised in the zone's NS RRset and associated glue A RRs.

The advertised address should be that of the "best" interface on the

host, in terms of network performance and reliability to the largest

number of destinations.

Rationale: While not required by [RFC1035], many extant DNS

implementations require the source address and port of

a reply to match the destination address and port to

which the request was sent. The number of advertised

addresses is limited to one (1) so that DNS delegation

responses containing this name server can be as short

as possible.

2.6. Physical environment. A name server host must be located in a

secure space such as a locked computer room or a data center with

restricted Access. The power supply should be redundant, using

batteries, generators or some other means to protect against utility

power failures. Network connectivity should be redundant, so that a

single wide area line failure cannot completely isolate the name

server host from the rest of the network.

2.7. Network security. The system and network administrators should

educate themselves about potential threats, and stay current on CERT

bulletins regarding network breakins. The system staff should

periodically audit the name server host's activity logs and be able

to detect breakins during or after the fact.

2.8. Host performance. As of the time of this writing, a name server

must be able to answer 1,200 UDP transactions per second with less

than 5 milliseconds of average latency. Because the network is still

growing at a high rate, the ability to grow to 2,000 transactions per

second and still support a 5 millisecond latency is highly desirable.

Note that this requirement affects both the host and the network

infrastructure to which that host is attached.

2.9. Response time. The administrators responsible for a name server

will respond to e-mail trouble reports within 24 hours. Personnel

issues such as vacations and illness will cause responsibilities to

be delegated and/or reassigned rather than ignored. After hours

telephone numbers must be made available to the zone master for

nonpublished use in emergencies. An escalation contact name, e-mail

address, and telephone number will also be made available to the zone

master in the event of nonresponse through the normal channel.

2.10. Zone transfer access control. The name server shall be

configured so that outbound zone transfers are permitted only to

destinations on the server's local networks, and to whichever

networks the zone master designates for remote debugging purposes.

Rationale: Zone transfers can present a significant load on a name

server, especially if several transfers are started

simultaneously against the same server. There is no

operational reason to allow anyone outside the name

server's and zone's administrators to transfer the

entire zone.

2.11. Zone transfer protocol. DNS AXFR shall be used in preference

to FTP or any other non-DNS transfer protocol. DNS NOTIFY (see

[NOTIFY]) and DNS IXFR (see [IXFR]) shall be supported and enabled

when available.

Rationale: Historically, the common implementations of DNS

(a.k.a., BIND) did not support zone transfer of the

root (".") zone due to programming errors. Thus, FTP

was used. In the future, DNS implementations which do

not support zone transfer of all zones will not be

considered suitable for use as root name servers. The

benefits of [IXFR] and [NOTIFY] should be obvious.

2.12. Recursion shall be disabled for queries.

Rationale: Recursion is a major source of cache pollution, and can

be a major drain on name server performance. An

organization's recursive DNS needs should be served by

some other host than its root name server(s). An

exception is made for missing glue since it's possible

that glue needed for some delegations will not be

within or beneath any zone for which the server is

authoritative. Such glue must be fetched via

recursive lookups to other servers.

2.13. Outages shall be reported. All outages, scheduled or not,

shall be reported to the zone master via e-mail. If an outage is

unscheduled or if an outage is scheduled less than 24 hours in

advance, then an additional notification of the zone master shall be

made via telephone. Extended or repeated outages may beget special

handling by the zone master.

2.14. Inverse name lookups. The PTR RR associated with a server's

primary interface address (that is, the address shown in in the

zone's delegation) shall have its target specified by the zone

master.

Rationale: Since each organization has local control of their

network's PTR RRs, and since it is necessary for the

correct operation of some software that the forward and

reverse lookups have symmetrical results, it is left

up to the zone master to select the name for each

authority server's primary address.

3 - Possible Selection Criteria

3.1. Host population. A server's location on the network should be

such that it has a low IP hop count to a high number of end hosts.

Duplication of service should be avoided, such that any given set of

end hosts needs to have a low IP hop count to at most one authority

server for any given zone.

3.2. Infrastructure diversity. A server's location on the network

should be such that most failures capable of isolating it from a

large number of end hosts are diverse from the failures capable of

similarly isolating other authority servers for the same zone(s).

4 - Security Considerations

See section 2.7.

5 - References

[RFC1035]

Mockapetris, P., "Domain Names - Implementation and Specification",

STD 13, RFC1035, USC/Information Sciences Institute, November

1987.

[Postel96]

Postel, J., "New Registries and the Delegation of International Top

Level Domains", Work in Progress.

[IXFR]

Ohta, M., "Incremental Zone Transfer", RFC1995, August 1996.

[NOTIFY]

Vixie, P., "A Mechanism for Prompt Notification of Zone Changes",

RFC1996, August 1996.

6 - Acknowledgements

Constructive comments have been received from: Jon Postel, Michael

Patton, Andrew Partan, Michael Dillon, Don Mitchell Steven Doyle,

Owen DeLong and other members of the internet community.

7 - Authors' Addresses

Bill Manning

USC/ISI

4676 Admiralty Way

Marina del Rey, CA 90292

Phone: +1 310 822 1511

EMail: bmanning@isi.edu

Paul Vixie

Internet Software Consortium

Star Route Box 159A

Woodside, CA 94062

Phone: +1 415 747 0204

EMail: paul@vix.com

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有