The following is a model memorandum of understanding for the operation
of root nameservers, prepared through the work of the Root Server System
[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].
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
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
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
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
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
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
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
[e-mail address of ICANN for operational matters]
[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
Internet Corporation for Assigned Names and Numbers
4676 Admiralty Way, Suite 330
Marina del Rey, California 90292 USA
Attn: Chief Executive Officer
[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.
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
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
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):
[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
Initially, the Root Nameserver may also (but is not required by this
MOU to) serve the following zones:
[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.
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.
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.
2.8 Servers MUST generate checksums when sending UDP datagrams and
MUST verify checksums when receiving UDP datagrams containing a non-zero
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.
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
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
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
By use of the term "SHOULD", this Section does not establish
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
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
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
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
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
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.
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.
the layout, construction and functionality of this site
should be sent to firstname.lastname@example.org.
©2002 The Internet Corporation for Assigned
Names and Numbers. All rights reserved.