ICANN participation

Draft of 21 January 2002

The following is a model memorandum of understanding for the operation of root nameservers, prepared through the work of the Root Server System Advisory Committee.

[MODEL] MEMORANDUM OF UNDERSTANDING CONCERNING

ROOT NAMESERVER OPERATION

This Memorandum of Understanding ("MOU") is entered between the Internet Corporation for Assigned Names and Numbers ("ICANN") and [name of operator's organization] ("Operator") as of [date].

A. Recitals.

1. For many years, Operator has provided valuable service to the Internet community by operating Root Nameserver [letter of root nameserver] on a volunteer basis. The arrangements for that service have been informal and have not been documented in a memorandum of understanding or agreement.

2. ICANN has become responsible for performing the functions traditionally provided by the Internet Assigned Numbers Authority ("IANA"), including coordinating the operation of the Internet's root-nameserver system.

3. ICANN is also responsible for overseeing changes to the root-zone file of the Internet domain-name system ("DNS"). This function is currently performed with the technical assistance of VeriSign Registrar (which performs edits to the database from which the root-zone file is generated) and VeriSign Global Registry Services (which generates the root-zone file and makes it available, by diverse methods, to the root-nameserver operators).

4. To assist it in carrying out these responsibilities,ICANN has established a Root Server System Advisory Committee ("RSSAC"), including a representative of Operator. The role of the RSSAC is to give technical and operational advice to the ICANN Board about the operation of the root nameservers, including advice about operational requirements (including host hardware capacities, operating systems and nameserver software versions, network connectivity, and physical environment), security aspects, and the number, location, and distribution of root nameservers considering the total system performance, robustness, and reliability.

5. The mutual objective of the parties through this MOU is to provide a more definitive statement of the roles and responsibilities of ICANN and Operator in operating the root-nameserver system for the DNS (including the Root Nameserver operated by Operator), in order to enhance the security and stability of the legal framework under which the system operates.

6. By this MOU, ICANN seeks to secure Operator's continued assistance to the Internet community through operating a root nameserver for the root zone, with certain environmental, operational, and performance requirements being met.

7. By this MOU, Operator reaffirms its continuing willingness to operate a root nameserver to respond to DNS queries about the root zone, and to provide appropriate operational support, network connectivity, physical environment, and network infrastructure for the root nameserver.

B. Definition.

As used in this MOU, "Root Nameserver" means the DNS nameserver provided by Operator, known by the host name [letter of root nameserver].root-servers.net, under the terms of this MOU for the root domain including hardware, software, data, algorithms, and processes for DNS naming and address resolution.

C. ICANN's Obligations. During the term of this MOU:

1. Provision of Root-Zone File. In its performance of the IANA functions, ICANN will provide Operator with access to root-zone files, and any ancillary zone files, at the source(s) and on the schedule specified in Section D.2 and D.3 of this MOU. The zone files provided will be in a format compliant with RFC 1035 and RFC 2181.

2. 7/24 Coordination of Root-Server System. ICANN will be responsible, in consultation with the RSSAC, for coordinating the operation of the root-nameserver system. ICANN will designate two or more liaisons who will serve as points of contact for personnel of Operator on a 7/24 basis.

3. RSSAC. ICANN will maintain the RSSAC and Operator will be entitled to designate one representative to be a member of the RSSAC.

4. Financial Support. This MOU does not, in and of itself, entitle Operator to any monetary compensation or financial support for the operation of the Root Nameserver. The RSSAC
may recommend to the ICANN Board that financial support be provided to defray the cost of implementing changes to specifications (see Section E) or for other reasons.

D. Operator's Obligations. During the term of this MOU:

1. Maintaining and Operating the Root Nameserver. Operator will, at Operator's sole expense, maintain and operate the Root Nameserver in a secure space and provide operational
support, network connectivity, physical environment, and network infrastructure for the Root Nameserver pursuant to the requirements established by the process set forth in Section E of this MOU.

2. Publication of Designated Root-Zone File. Operator will cause the Root Nameserver to load a root-zone file from a source, in a manner, and on a schedule designated by ICANN, to publish the contents of that root-zone file in response to client queries received, and otherwise to meet the specifications established by the process set forth in Section E of this MOU with regard to updates to the root zone.

3. Publication of Other Zone Files. Operator will cause the Root Nameserver to load, and to publish the contents of, zone files other than the root-zone file described in Section D.2 of this MOU to the extent, and only to the extent, set forth in the requirements established by the process set forth in Section E of this MOU.

4. Operating Personnel. Operator will provide qualified personnel with the proper skill, training and experience to perform Root Nameserver operation and monitoring functions in a competent and professional manner and in accordance with the requirements established by the process set forth in Section E of this MOU. Among the qualified personnel will be [name of Principal Operator] (designated as "Principal Operator"), who will be in overall charge of operation of the Root Nameserver. Operator will give ICANN fifteen days notice of any change in the identity of the Principal Operator, except that in the event the Principal Operator's employment with Operator terminates the Operator will give ICANN notice of the change no later than five days after the termination. During vacations and other times during which the Principal Operator is temporarily unavailable, Operator will designate to ICANN an acting Principal Operator.

5. Coordination. Operator will take reasonable steps to coordinate with other Operators and with ICANN concerning the operation of the root-nameserver system and the implementation of revisions to that system.

6. 7/24 Contact Personnel. Operator will provide ICANN (or another party ICANN designates from time to time) with a 24-hour, 7-day-a-week point of contact to initiate emergency
maintenance of the Root Nameserver, in the manner established by the process set forth in Section E of this MOU. The point of contact need not have personal expertise in emergency maintenance procedures, but must be able to contact personnel with such expertise.

7. Outages. Operator will attempt to report all unscheduled outages affecting the operation of the Root Nameserver (including phone lines, e-mail, etc.) to ICANN (or another party ICANN designates from time to time) within thirty minutes via email and telephone at an e-mail address and a telephone number specified by ICANN to Operator from time to time. If an outage is scheduled, Operator will notify ICANN (or ICANN's designee) not less than 24 hours in advance. Operator will comply with any disaster recovery plan established according to Section E of this MOU.

8. Access Control. Access to the Root Nameserver will be controlled in such a manner so as not to compromise the safe operation of the service and will be defined within the guidelines established by the process set forth in Section E of this MOU.

9. Performance Measurements. Operator will take reasonable steps to participate in performance measurement programs developed by ICANN through the RSSAC process set forth in Section E of this MOU.

E. Establishment of Operating Requirements.

The operational, environmental, connectivity, access control, and other requirements for the Root Nameserver as called for in Section D of this MOU will be established by the following process. In general, it is the goal of ICANN and Operator that the Root Nameserver eventually meet the requirements of RFC 2870, but the parties recognize that compliance with all aspects of RFC 2870 is not feasible
given current implementation capabilities. Accordingly, while RFC
2870 serves as the basis for specifications for the Root Nameserver, as an implementation matter that goal is intended to be achieved according to the following provisions:

1. Initial Requirements. At time this MOU is signed, the Root Nameserver will comply with the requirements stated in Exhibit A to this MOU.

2. Ongoing RSSAC Evaluation and Recommendations for Revision. The RSSAC will be responsible on an ongoing basis for advising the ICANN Board generally about the operation of the Root Nameservers of the domain name system, and in particular about the appropriateness of establishment or deletion of, or revisions to, specifications for the maintenance, performance, manner of operation, access control and security, support, connectivity, environment, infrastructure, personnel, zone-file loading and publication, and all other aspects pertinent to the operation of the root-nameserver system and the Root Nameservers that comprise that system. The RSSAC will also be responsible for reviewing and providing advice to the ICANN Board on the number, location, and distribution of Root Nameservers considering the total system performance, robustness, and reliability.

3. Changes to Requirements. ICANN, after considering any recommendations or advice of the Root Server System Advisory Committee, may from time to time adopt revised specifications for Root Nameservers, along with plans and schedules for implementation of those revised specifications as appropriate. The decisionmaking process for specification revisions should include due consideration of any technical constraints of the Operators, as well as the

availability of financial support to any Operator in need of financial assistance, as provided for in Section C.4. above. The plans will ordinarily provide Operator at least one-hundred twenty days in which to implement revised specifications, unless the Operator agrees to a faster schedule or ICANN's Board finds that the change is urgent and a shorter period is necessary. In the event Operator does
not wish to implement a revised specification as adopted, Operator may exercise its right to resign before implementing the changes as provided in Section G.4 of this MOU.

F. Ownership of Root Nameserver and Root-Zone File.

Operator will retain all right, title, and interest it has in and to the hardware and software of the Root Nameserver, including any and all modifications to it. Operator will not claim any right, title, or
interest in or to any root-zone file loaded onto the Root Nameserver or to the status of that system as a Root Nameserver.

G. Duration, Review, and Termination of MOU.

1. Term. [OPTION 1: The initial term of this MOU will begin as of the Effective Date and will continue for a period of three years or until terminated as provided in this Section G of this MOU. The MOU will automatically renew without interruption for successive three-year terms unless either party provides written notice to the other party at least sixty days before the end of the then-current term that it does not desire to renew.] [OPTION 2: The term of this MOU will begin as of the Effective Date and will continue for a period of three years or until terminated as provided in this
Section G of this MOU. As provided by Section G.2 of this MOU, the parties will mutually review this MOU at least ninety days before the end of its term with a view to determining whether a renewal MOU should be entered.]

2. Mutual Review of MOU. [OPTION 1: At least ninety days before the end of the initial or any renewal term of this MOU, and within sixty days after a specific request by either party, the parties will mutually review the results and consequences of their cooperation under this MOU and will consider the need for improvements in the MOU and make suitable proposals for modifying and updating the arrangements described in this MOU.] [OPTION 2: At least ninety days before the end of the term of this MOU, the parties will mutually review the results and consequences of their cooperation under this MOU and will consider the desirability of entering a renewal MOU under appropriate terms upon termination of this MOU. In addition, within sixty days after a specific request by either party the parties will mutually review
the results and consequences of their cooperation under this MOU and will consider the need for improvements in the MOU and make suitable proposals for modifying and updating the arrangements described in this MOU.]

3. Termination by ICANN. ICANN may terminate this MOU without cause at any time by delivering a written notice of termination to Operator at least ninety days before the date on which the termination is to be effective.

4. Termination by Operator's Resignation.
Operator may resign from ongoing responsibilities as an Operator and terminate this MOU without cause at any time by delivering a written notice of resignation to ICANN at least ninety days before the date on which the resignation is to be effective. However, in the event a specification is revised with less than 120 days notice as a matter of urgency (see Section E.3 above), the Operator is entitled to a resign before the day of the implementing. Operator will give as much notice as is reasonably feasible.

5. Consequences of Termination or Non-Renewal.
In the event of termination or non-renewal of this MOU for any reason, Sections F, G.5, H, and I of this MOU will survive. The parties will use
commercially reasonable efforts to facilitate a smooth transition to provision of root nameservice by another operator. In this regard, Operator will either (a) give appropriate authorizations for the transfer of the following IP address block to ICANN or the subsequent operator it designates: [IP block]/24 or (b) ensure that no nameservice or other service on port 53 is provided at IP address [IP address] for at least five years after the termination or non-renewal. Neither party will be liable to the other for damages of any sort resulting from termination or non-renewal of this MOU.

H. Consequences of Breach.

[OPTION 3: The remedy contemplated for breaches of this MOU is termination under Section G.3 or G.4 of this MOU. There will be no monetary damages for breach of this MOU by either party.] [OPTION 4: Although the obligations stated in this MOU are intended to be binding commitments during its term, the sole remedy for breach of this MOU is termination under Section G.3 or G.4 of this MOU, except that: (a) the Operator's obligations under Section G.5 of this MOU concerning transfer or non-use of IP address(es) may be specifically enforced and (b) Operator may obtain appropriate remedies for a failure by ICANN to indemnify as required by Section I.4 of this MOU. Except as provided in part (b) of the immediately
preceding sentence, monetary damages shall not be available to either party for breach of this MOU.]

I. Miscellaneous Provisions.

1. Notices. All notices under this MOU concerning operation of the Root Nameserver will be given by e-mail as follows:

To ICANN:

[e-mail address of ICANN for operational matters]

To Operator:

[e-mail address of Operator for operational matters]

All other notices and requests in connection with this MOU will be deemed given as of the day they are received either by messenger, delivery service, or in the United States of America mails, postage prepaid,
certified or registered, return receipt requested, and addressed as follows:

To ICANN:

Internet Corporation for Assigned Names and Numbers

4676 Admiralty Way, Suite 330

Marina del Rey, California 90292 USA

Attn: Chief Executive Officer

To Operator:

[postal address of Operator]

2. Relationship of the Parties. Nothing in this MOU will be construed as creating an employer-employee relationship, a partnership, a joint venture, or an agency relationship between the parties or between or among participants in the RSSAC.

3. Assignment. Neither party may assign this MOU without the prior written approval of the other party. This MOU will be binding upon and inure to the benefit of each party's respective successors and lawful assigns.

[Included in OPTION 5: 4. Indemnification by ICANN. In view of Operator's commitment to operate the Root Nameserver at its expense under Section D.1 of this MOU, ICANN shall indemnify, defend, and hold harmless Operator (including its directors, officers, employees, and agents) from and against any and all claims, suits, actions, or other proceedings, including reasonable legal fees and expenses, arising solely from Operator's compliance, in operating the Root Nameserver, with the requirements of Sections D.1, D.2, and D.3 of this MOU (except that Operator shall not be indemnified, defended, or held harmless to the extent that the claims, damages, liabilities, costs, and expenses arise from the particular manner in which Operator has chosen to comply with those requirements, where it was possible for Operator to comply in a manner by which the claims, damages, or liabilities would not arise), provided that in any such case: (a) Operator provides ICANN with prompt written notice of any such claim, suit, action, or other proceeding; (b) upon ICANN's request Operator gives ICANN full rights to conduct the defense (including settlement) of any indemnifiable claim, suit, action, or other proceeding; and (c) upon ICANN's written request Operator provides to ICANN all available information and assistance reasonably necessary for ICANN to defend such indemnifiable claim, suit, action, or other proceeding.]

5. No Third-Party Beneficiaries. This MOU shall not be construed to create any obligation by either ICANN or Operator to any non-party to this MOU.

6. Right to Request Board Consideration.
In the event of any dispute between the parties concerning this MOU, Operator will be entitled to present the matter to the ICANN Board of Directors, in a manner prescribed by the Board, for its consideration.

7. Effective Date and Changes to this MOU.
This MOU will not be effective until signed by both parties. This MOU will not be modified except by written memorandum dated subsequent to the date of this MOU and signed on behalf of ICANN and Operator by their respective duly authorized representatives.

8. Other Agreements and Understandings.
Although this MOU is intended to provide a complete statement of the roles and responsibilities of ICANN and Operator in operating the root-nameserver system (including the Root Nameserver operated by Operator), this MOU is intended to coexist with any other written memoranda of understanding or agreements signed by both parties, including without limitation any confidentiality and disclosure agreement signed by both parties. The parties are also participating in a joint research project under a Cooperative Research and Development Agreement (CRADA), as amended, between ICANN, the United States Department of Commerce (Commerce), as represented by the National Institute of Standards and Technology (NIST) and the National Telecommunications and Information Administration (NTIA). Except as otherwise expressly provided in this MOU (see, for example, Section E), no prior, contemporary, or subsequent agreement, understanding, or communication shall vary or supplement the terms of this MOU unless in writing and signed by both parties.

IN WITNESS WHEREOF, the parties have entered into this MOU.

Exhibit A

Initial Requirements

The following describes the initial requirements for the Root Nameserver as described in Section E.1 of this MOU. Indented material is from RFC 2870, which has been tailored to reflect implementation considerations in the manner described below:

1. Software. Section 2.2 of RFC 2870 is an initial requirement. It provides:

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. Server Throughput. Section 2.3 of RFC 2870 provides:

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.

The initial requirement is adjusted from the above so that the Root Nameserver shall be capable of handling a load of 20,000 requests for root data per second. This figure will be periodically reviewed and, as appropriate, revised under Section E.3 of this MOU.

3. Connectivity. The first sentence of Section 2.4 of RFC 2870 is an initial requirement. It provides:

2.4 Each root server should have sufficient connectivity to the internet to support the bandwidth needs of the above requirement.

In connection with this requirement, the "connectivity to the internet" to be provided by Operator is understood as meaning connectivity to a major connectivity provider. In addition, Operator's Internet connectivity for the Root Nameserver shall be redundant to different major connectivity providers, with each link having sufficient capacity to meet 150% of the DNS query and response demand described in item 2 above.

4. Zones Served. Section 2.5 of RFC 2870 provides:

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.

The first two sentences of this Section are initial requirements. With respect to the third sentence, initially the Root Nameserver shall serve the following zone(s):

[root]

root-servers.net

[this list varies somewhat depending on which root nameserver is involved]

The Root Server shall load each of these zones (by a AXFR or, at the option of the Operator, by ftp) from an IP address and on a schedule ICANN prescribes.

Initially, the Root Nameserver may also (but is not required by this MOU to) serve the following zones:

arpa

edu

gov

in-addr.arpa

int

mil

[this list varies somewhat depending on which root nameserver is involved]

No other zones shall be served. The above designations of zones will be periodically reviewed and, as appropriate, revised under Section E of this MOU.

5. Queries Served. Section 2.6 of RFC 2870 is an initial requirement. It provides:



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.

In connection with this requirement, "valid IP address" is understood to exclude RFC 1918 addresses and other addresses not intended to be routable on the Internet.

6. Zone Transfers. Section 2.7 of RFC 2870 is an initial requirement. It provides:

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.

7. Checksums. Section 2.8 of RFC 2870 is an initial requirement. It provides:

2.8 Servers MUST generate checksums when sending UDP datagrams and
MUST verify checksums when receiving UDP datagrams containing a non-zero
checksum.

8. Physical Security. Section 3.1.1 of RFC 2870 is an initial
requirement. It provides:

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.

9. Power. Section 3.1.2 of RFC 2870 provides:

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.

The initial requirement is adjusted from the above so that power continuity
for at least 48 hours shall be provided. This figure will be periodically
reviewed and, as appropriate, revised under Section E
of this MOU. In connection with this requirement, "the infrastructure
necessary to connect the server to the internet" is understood to
refer to equipment necessary for connection to the demarcation block of
the Operator's connectivity providers.

10. Fire Protection. Section 3.1.3 of RFC 2870 is an initial requirement.
It provides:

3.1.3 Fire detection and/or retardation MUST be provided.

11. Backup Systems. Section 3.1.4 of RFC 2870 provides:

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.

The first sentence of Section 3.1.4 is an initial requirement, with the
understanding that ICANN will coordinate providing backup for the Root
Nameserver on a systemwide basis.

10. Other Services on Root Nameserver. Section 3.2.1 of RFC 2870
is an initial requirement. It provides:

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.

In connection with the requirement in the first sentence, is understood
that the Root Nameserver may provide ancillary services (e.g., SSH) in
support of providing nameservice.

11. Authentication. Sections 3.2.2 and 3.2.8 of RFC 2870 are initial
requirements. They provide:

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.8 The server SHOULD be protected from attacks based on source routing.
The server MUST NOT rely on address- or name-based authentication.

The requirement of Section 3.2.8, as initially applicable, shall not
prohibit address-based authentication in connection with the Root Nameserver
obtaining zone files from sources designated by ICANN under item 4 of
this Exhibit.

12. LAN Segments. Sections 3.2.3 of RFC 2870 provides:

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.

In place of this requirement, the Root Nameserver shall be homed on one
or more LAN segments that home only hosts associated with providing root
nameservice (including logging hosts and associated performance measurement
boxes).

Section 3.2.4 of RFC 2870 provides:

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.

It is replaced with the following initial requirement:

3.2.4 The LAN segment(s) on which a root server is homed MUST be separately
firewalled or packet filtered to discourage network access to any port
other than those needed for name service (including SSH for maintenance
and monitoring; see also 3.2.5).

13. Clock Synchronization. Section 3.2.5 of RFC 2870 provides:

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.

It is an initial requirement, except the first "SHOULD" is
replaced with "MUST".

14. Logging. Sections 3.2.6 and 3.2.7 of RFC 2870 provide:

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 Server logging SHOULD be to separate hosts which SHOULD be protected
similarly to the root servers themselves.

These are initial requirements, except all occurrences of "SHOULD"
are replaced with "MUST". More comprehensive logging requirements
will be developed according to Section E of this MOU.

15. Reverse-Lookup for Addresses. Section 3.2.9 of RFC 2870 provides:

3.2.9 The network on which the server is homed SHOULD have in-addr.arpa
service.

By use of the term "SHOULD", this Section does not establish
any requirements.

16. Signing and Authentication of Zones. Sections 3.3.1, 3.3.2,
and 3.3.3 of RFC 2870 relate to signing and authentication of zones. Due
to implementation reasons, their effectiveness is deferred to a schedule
to be established by ICANN in consultation with the RSSAC. They provide:

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 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 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.

17. Dedicated Master. Section 3.3.4 of RFC 2870 provides:

3.3.4 A 'hidden primary' server, which only allows access by the authorized
secondary root servers, MAY be used.

By use of the term "MAY", this Section does not establish any
requirements.

18. Pre-Loading Checks. Section 3.3.5 of RFC 2870 is an initial
requirement. It provides:

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.

19. Time-to-Update. Section 3.3.6 of RFC 2870 provides:

3.3.6 Root zone updates SHOULD normally be effective no later than
6 hours from notification of the root server operator.

In place of this provision, the Root Nameserver shall complete updates
within 4 hours of when notification is provided of the availability of
the update.

20. Emergency Updates. Section 3.3.7 of RFC 2870 provides:

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.

In place of this provision, the Root Nameserver shall complete emergency
updates within 4 hours of when notification is provided of the availability
of the update.

21. Alternative Zone Update Method. Section 3.3.5 of RFC 2870
is an initial requirement. It provides:

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.

To the extent feasible, the method must allow update on (or near) the
same time schedule as the primary delivery mechanism.

22. Keeping of Statistics. Section 3.3.6 of RFC 2870 is an initial
requirement. It provides:

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.

The lower-case instance of "must" in the second sentence is
to be interpreted as if in ALL CAPITALS. The logs described in Section
3.2.6 of RFC 2870 (see item 14 above) MUST also be made available to RSSAC
and researchers designated by RSSAC.

23. Inter-Operator Communications. Sections 4.1, 4.2, and 4.3
provide:

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 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 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.

By use of the terms "SHOULD" and "MAY", these Sections
do not establish any requirements.

24. Reporting to the IANA. Section 4.4 of RFC 2870 is an initial
requirement. It provides:

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.

25. 24/7 Service. Section 4.5 of RFC 2870 is an initial requirement.
It provides:

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.

The 24-hour-per-day/7-day-per-week point of contact (Section
D.6 of the MOU) need not have personal expertise in service procedures,
but must be able to contact personnel with such expertise.