Comments on Technical Checks Used for DNS Root Zone Changes
Hi, I've attached Afilias' response to this request for comments from the IANA. The same document is attached rendered in ASCII and HTML -- please feel free to use whatever seems most useful. (I've also attached a zip file containing both versions, to avoid any exploding MUA issues that might arise from having HTML attachments). If you could confirm that you got the text ok, that would be great. Thanks, Joe
Afilias J. Abley
G. Berezowsky
A. Sullivan
Afilias Canada Corp.
H. Eland
Afilias USA, Inc.
September 15, 2006
IANA Root Zone Checks
Abstract
This document is a response to IANA's request for review of the
procedures related to root zone management issued on 18 August 2006.
Table of Contents
1. Overview
2. Executive Summary
3. Suggested Test Regime
4. Regular, Scheduled Testing
5. Roles of the IANA and Verisign
6. Treatment of WARNING Conditions by the IANA
7. Renumbering Nameservers
8. Documentation
9. References
Authors' Addresses
1. Overview
This document is a response to the IANA's request for public
review [1] of the procedures related to root zone management issued
on 18 August 2006.
2. Executive Summary
Afilias is very much in favour of the general practice of performing
technical validation of change requests before they are implemented.
Such checks ought to provide little or no inconvenience to
established, experienced TLD operators, and play a useful role in
knowledge transfer to those TLD operators who are less experienced,
to the benefit of registrants and users of the Internet in general.
Afilias believes that while failures of some checks ought prevent the
corresponding changes from being implemented, other checks ought at
most to generate warnings, and should not prevent changes from being
implemented.
Afilias believes that the IANA should perform the same set of
automated checks against every TLD on a regular schedule, and
communicate any issues that become apparent to zone operators in a
proactive manner. This will increase contact between the IANA and
zone operators who have technical challenges to overcome, and should
help avoid the problem of urgent change requests being held up
because of pre-existing technical problems.
Afilias believes that the IANA should direct VeriSign Global Registry
Services in the checks that VeriSign performs as part of its
management role for the root zone, and the circumstances in which
Verisign should properly refuse to implement a change should be
clearly defined.
Afilias believes that the IANA should maintain technical point of
contact information for nameservers, as well as zones. In the event
that a change request relating to the renumbering of a nameserver is
received from a zone operator, the nameserver operator should be
contacted for confirmation, but the operators of other zones
delegated to that nameserver should receive a courtesy notification
of the change only; they should not be required to confirm acceptance
of the change. It should be possible for a nameserver operator to
request changes to the root zone in the event that the nameserver
must be renumbered.
Afilias suggests that the IANA should publish the complete procedure
for requesting and processing changes in the root zone through the
IETF as one or more Informational RFCs.
3. Suggested Test Regime
The following tests are numbered according identically to those in
the IANA's request for comments where they already exist, for ease of
reference. Tests are annotated as follows:
MANDATORY A failure of this test should result in the change request
being denied.
WARNING A failure of this test should result in a warning message
being sent to the requestor by a human operator. The operator
should confirm through dialogue with the requestor that the issues
encapsulated in the warnings are well-understood. The requestor
may opt to proceed with the change as submitted.
DELETE This check should be removed.
MODIFY This check should be modified.
ADD This new check should be added.
(1) Minimum Number of Nameservers. MANDATORY, MODIFY. The
requirement that the nameservers should not share the same IP
address is unnecessary; topological diversity is ensured through
test (10).
(2) Maximum Number of Nameservers. DELETE. This requirement is
encapsulated more appropriately within proposed new test (a).
(3) Hostname Validity. MANDATORY, MODIFY. The requirement should
be changed to match exactly what is specified in [RFC1034]
section 3.5.
(4) Nameserver Reachability. MANDATORY.
(5) Nameserver Authority. MANDATORY.
(6) Nameserver Coherency. WARNING. The delegation NS set in the
root zone may legitimately differ from the apex NS set in the
delegated TLD zone, e.g. as part of a transition plan from one
set of authority servers to another.
(7) Glue Coherency with Hostname. MANDATORY.
(8) Glue Coherency with Existing Glue. DELETE. A request to change
a glue record in the root zone in order to renumber a nameserver
should be processed as such, and should not trigger warnings.
See also Section 7.
(9) Serial Number Consistency. WARNING. For some zones, a
difference in SOA serial between authority servers is a natural
consequence of the rapid turnaround of changes submitted to a
registry.
(10) Minimum Network Diversity. MANDATORY, MODIFY. Network
diversity cannot be judged accurately by simply calculating the
arithmetic distance between IP addresses, nor by comparing
observed AS_PATH attributes in covering routes. A combination
of checks should be used to allow the IANA to gauge whether an
NS set has appropriate topological diversity. The requirement
should be that not all nameservers are colocated, not that no
two nameservers are colocated.
(11) Nameserver Continuity. WARNING. There are legitimate reasons
for changes to be processed in a single atomic operation,
without staging changes in the NS set as described.
(12) Whether Nameservers have Matching PTR Records. WARNING.
Although the management of PTR records is to be encouraged,
their absence does not impact the performance of the DNS.
(13) Whether Nameservers have RFC 1918 Addresses. MANDATORY. Due to
lax operational attention to the uses of these address ranges on
the Internet, it is possible to conceive of circumstances in
which nameservers so-numbered might pass other tests, and so
this ought to be checked explicitly.
(14) Whether Nameservers are on the List of Reserved IP Addresses.
MANDATORY, MODIFY. Reference should be made to [RFC3330], to
IPv4 multicast addresses and to the Unspecified, Loopback, Link-
Local, Site-Local and Multicast IPv6 addresses specified in
[RFC4291].
(15) Whether the Last Octet of the Nameserver IP Address is 0 or 255.
DELETE. This requirement is obsoleted by [RFC4632].
(16) Whether the Overall Length of the Nameserver Hostname is less
than 128 Characters. DELETE. This requirement is encapsulated
more succinctly in proposed new test (a).
(a) Size of Referral NS RRset and Glue. MANDATORY, ADD. The size of
the AUTHORITY and ADDITIONAL sections in a referral response from
a root server should be sufficiently small that reasonable
questions can be answered with a useful set of courtesy glue over
UDP Transport without requiring EDNS0. The functional details of
the corresponding test for this requirement should be specified
with the assistance of root server operators.
(b) EDNS0 Support. WARNING, ADD. Every nameserver should support
[RFC2671].
(c) TCP Transport Support. WARNING, ADD. Every nameserver should
support queries on both UDP and TCP transport.
4. Regular, Scheduled Testing
Afilias believes that the IANA should carry out regular, scheduled,
automated testing of TLD zones and should make proactive contact with
zone operators in the event that problems are detected.
Early warning of test failure gives zone operators more opportunity
to resolve problems, compared with the current process in which an
urgent change request can be denied due to pre-existing problems
unrelated to the requested change.
5. Roles of the IANA and Verisign
The IANA should carry out all tests, and should reject or clarify
requests in the event that failures are evident in MANDATORY or
WARNING checks, as appropriate.
Verisign should carry out MANDATORY tests only.
Afilias believes that there is benefit in having both the IANA and
Verisign carry out the same set of MANDATORY tests, since this
provides codebase diversity and helps to guard against systematic
false negative responses from tests.
6. Treatment of WARNING Conditions by the IANA
In the event that a request is received which pre-acknowledges the
results of one or more WARNING tests, the request should proceed
without requiring further acknowledgement of the WARNING test results
by the requestor.
For example, a zone operator may be well aware that SOA serial
numbers may differ between authority servers due to the architecture
in place for zone changes to propagate between authority servers. If
acknowledged in the original request, processing of the request
should not be held up by the results of the corresponding WARNING
test carried out by the IANA.
7. Renumbering Nameservers
Afilias suggests that the IANA should maintain point of contact
details for nameservers for which glue exists in the root zone, as
well as for zone operators.
A request to renumber a nameserver should be accepted from the
operator of any zone delegated to that nameserver, but confirmation
from the nameserver operator for the change should be sought before
the change is allowed to proceed. Requests to renumber a nameserver
should also be accepted by the nameserver operator.
When a nameserver is to be renumbered, notification of the change
should be sent to the operators of all zones delegated to that
nameserver. An additional delay should be instituted to give zone
operators the opportunity to request changes to their zones'
nameservers in response to the proposed nameserver change.
8. Documentation
Afilias believes that the IANA should publish the procedures and
functional specification of the tests carried out in the IETF, as an
informational RFC. Future changes to procedures or to the tests
should be published as additional RFCs in the usual manner of the
IETF.
9. References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999.
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330,
September 2002.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, August 2006.
[1] <http://www.icann.org/announcements/announcement-18aug06.htm>
Authors' Addresses
Joe Abley
Afilias Canada Corp.
Suite 204
4141 Yonge Street
Toronto, ON M1A 2P8
Canada
Phone: +1 416 673 4176
Email: jabley@xxxxxxxxxxxxxxx
URI: http://afilias.info/
Greg Berezowsky
Afilias Canada Corp.
Suite 204
4141 Yonge Street
Toronto, ON M1A 2P8
Canada
Phone: +1 416 673 4122
Email: gberezow@xxxxxxxxxxxxxxx
URI: http://afilias.info/
Andrew Sullivan
Afilias Canada Corp.
Suite 204
4141 Yonge Street
Toronto, ON M1A 2P8
Canada
Phone: +1 416 673 4110
Email: andrew@xxxxxxxxxxxxxxx
URI: http://afilias.info/
Howard Eland
Afilias USA, Inc.
300 Welsh Road
Building 3, Suite 105
Horsham, PA 19044
USA
Phone: +1 215 366 2758
Email: heland@xxxxxxxxxxxx
URI: http://afilias.info/
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd";> <html lang="en"><head><title>Afilias: IANA Root Zone Checks</title> <meta http-equiv="Expires" content="Fri, 29 Sep 2006 16:50:04 +0000"> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="description" content="IANA Root Zone Checks"> <meta name="generator" content="xml2rfc v1.30 (http://xml.resource.org/)"> <style type='text/css'> <!-- body { font-family: verdana, charcoal, helvetica, arial, sans-serif; margin: 2em; font-size: small ; color: #000000 ; background-color: #ffffff ; } .title { color: #990000; font-size: x-large ; font-weight: bold; text-align: right; font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif; background-color: transparent; } .filename { color: #666666; font-size: 18px; line-height: 28px; font-weight: bold; text-align: right; font-family: helvetica, arial, sans-serif; background-color: transparent; } td.rfcbug { background-color: #000000 ; width: 30px ; height: 30px ; text-align: justify; vertical-align: middle ; padding-top: 2px ; } td.rfcbug span.RFC { color: #666666; font-weight: bold; text-decoration: none; background-color: #000000 ; font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif; font-size: x-small ; } td.rfcbug span.hotText { color: #ffffff; font-weight: normal; text-decoration: none; text-align: center ; font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif; font-size: x-small ; background-color: #000000; } /* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */ div#counter{margin-top: 100px} a.info{ position:relative; /*this is the key*/ z-index:24; text-decoration:none} a.info:hover{z-index:25; background-color:#990000 ; color: #ffffff ;} a.info span{display: none} a.info:hover span.info{ /*the span will display just on :hover state*/ display:block; position:absolute; font-size: smaller ; top:2em; left:2em; width:15em; padding: 2px ; border:1px solid #333333; background-color:#eeeeee; color:#990000; text-align: left ;} A { font-weight: bold; } A:link { color: #990000; background-color: transparent ; } A:visited { color: #333333; background-color: transparent ; } A:active { color: #333333; background-color: transparent ; } p { margin-left: 2em; margin-right: 2em; } p.copyright { font-size: x-small ; } p.toc { font-size: small ; font-weight: bold ; margin-left: 3em ;} table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; } td.toc { font-size: small; font-weight: bold; vertical-align: text-top; } span.emph { font-style: italic; } span.strong { font-weight: bold; } span.verb, span.vbare { font-family: "Courier New", Courier, monospace ; } span.vemph { font-style: italic; font-family: "Courier New", Courier, monospace ; } span.vstrong { font-weight: bold; font-family: "Courier New", Courier, monospace ; } span.vdeluxe { font-weight: bold; font-style: italic; font-family: "Courier New", Courier, monospace ; } ol.text { margin-left: 2em; margin-right: 2em; } ul.text { margin-left: 2em; margin-right: 2em; } li { margin-left: 3em; } pre { margin-left: 3em; color: #333333; background-color: transparent; font-family: "Courier New", Courier, monospace ; font-size: small ; text-align: left; } h3 { color: #333333; font-size: medium ; font-family: helvetica, arial, sans-serif ; background-color: transparent; } h4 { font-size: small; font-family: helvetica, arial, sans-serif ; } table.bug { width: 30px ; height: 15px ; } td.bug { color: #ffffff ; background-color: #990000 ; text-align: center ; width: 30px ; height: 15px ; } td.bug A.link2 { color: #ffffff ; font-weight: bold; text-decoration: none; font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif; font-size: x-small ; background-color: transparent } td.header { color: #ffffff; font-size: x-small ; font-family: arial, helvetica, sans-serif; vertical-align: top; background-color: #666666 ; width: 33% ; } td.author { font-weight: bold; margin-left: 4em; font-size: x-small ; } td.author-text { font-size: x-small; } table.full { vertical-align: top ; border-collapse: collapse ; border-style: solid solid solid solid ; border-color: black black black black ; font-size: small ; text-align: center ; } table.headers, table.none { vertical-align: top ; border-collapse: collapse ; border-style: none; font-size: small ; text-align: center ; } table.full th { font-weight: bold ; border-style: solid ; border-color: black black black black ; } table.headers th { font-weight: bold ; border-style: none none solid none; border-color: black black black black ; } table.none th { font-weight: bold ; border-style: none; } table.full td { border-style: solid solid solid solid ; border-color: #333333 #333333 #333333 #333333 ; } table.headers td, table.none td { border-style: none; } hr { height: 1px } --> </style> </head> <body> <table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table> <table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1"> <tr><td class="header">Afilias</td><td class="header">J. Abley</td></tr> <tr><td class="header"> </td><td class="header">G. Berezowsky</td></tr> <tr><td class="header"> </td><td class="header">A. Sullivan</td></tr> <tr><td class="header"> </td><td class="header">Afilias Canada Corp.</td></tr> <tr><td class="header"> </td><td class="header">H. Eland</td></tr> <tr><td class="header"> </td><td class="header">Afilias USA, Inc.</td></tr> <tr><td class="header"> </td><td class="header">September 15, 2006</td></tr> </table></td></tr></table> <div align="right"><span class="title"><br />IANA Root Zone Checks</span></div> <h3>Abstract</h3> <p>This document is a response to IANA's request for review of the procedures related to root zone management issued on 18 August 2006. </p><a name="toc"></a><br /><hr /> <h3>Table of Contents</h3> <p class="toc"> <a href="#anchor1">1.</a> Overview<br /> <a href="#anchor2">2.</a> Executive Summary<br /> <a href="#anchor3">3.</a> Suggested Test Regime<br /> <a href="#anchor4">4.</a> Regular, Scheduled Testing<br /> <a href="#anchor5">5.</a> Roles of the IANA and Verisign<br /> <a href="#anchor6">6.</a> Treatment of WARNING Conditions by the IANA<br /> <a href="#ns-renumber">7.</a> Renumbering Nameservers<br /> <a href="#anchor7">8.</a> Documentation<br /> <a href="#rfc.references1">9.</a> References<br /> <a href="#rfc.authors">§</a> Authors' Addresses<br /> </p> <br clear="all" /> <a name="anchor1"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table> <a name="rfc.section.1"></a><h3>1. Overview</h3> <p>This document is a response to the IANA's <a href="http://www.icann.org/announcements/announcement-18aug06.htm";>request for public review</a> of the procedures related to root zone management issued on 18 August 2006. </p> <a name="anchor2"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table> <a name="rfc.section.2"></a><h3>2. Executive Summary</h3> <p>Afilias is very much in favour of the general practice of performing technical validation of change requests before they are implemented. Such checks ought to provide little or no inconvenience to established, experienced TLD operators, and play a useful role in knowledge transfer to those TLD operators who are less experienced, to the benefit of registrants and users of the Internet in general. </p> <p>Afilias believes that while failures of some checks ought prevent the corresponding changes from being implemented, other checks ought at most to generate warnings, and should not prevent changes from being implemented. </p> <p>Afilias believes that the IANA should perform the same set of automated checks against every TLD on a regular schedule, and communicate any issues that become apparent to zone operators in a proactive manner. This will increase contact between the IANA and zone operators who have technical challenges to overcome, and should help avoid the problem of urgent change requests being held up because of pre-existing technical problems. </p> <p>Afilias believes that the IANA should direct VeriSign Global Registry Services in the checks that VeriSign performs as part of its management role for the root zone, and the circumstances in which Verisign should properly refuse to implement a change should be clearly defined. </p> <p>Afilias believes that the IANA should maintain technical point of contact information for nameservers, as well as zones. In the event that a change request relating to the renumbering of a nameserver is received from a zone operator, the nameserver operator should be contacted for confirmation, but the operators of other zones delegated to that nameserver should receive a courtesy notification of the change only; they should not be required to confirm acceptance of the change. It should be possible for a nameserver operator to request changes to the root zone in the event that the nameserver must be renumbered. </p> <p>Afilias suggests that the IANA should publish the complete procedure for requesting and processing changes in the root zone through the IETF as one or more Informational RFCs. </p> <a name="anchor3"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table> <a name="rfc.section.3"></a><h3>3. Suggested Test Regime</h3> <p>The following tests are numbered according identically to those in the IANA's request for comments where they already exist, for ease of reference. Tests are annotated as follows: </p> <blockquote class="text"><dl> <dt>MANDATORY</dt> <dd>A failure of this test should result in the change request being denied. </dd> <dt>WARNING</dt> <dd>A failure of this test should result in a warning message being sent to the requestor by a human operator. The operator should confirm through dialogue with the requestor that the issues encapsulated in the warnings are well-understood. The requestor may opt to proceed with the change as submitted. </dd> <dt>DELETE</dt> <dd>This check should be removed. </dd> <dt>MODIFY</dt> <dd>This check should be modified. </dd> <dt>ADD</dt> <dd>This new check should be added. </dd> </dl></blockquote><p> </p> <p> </p> <blockquote class="text"> <dt>(1)</dt> <dd>Minimum Number of Nameservers. MANDATORY, MODIFY. The requirement that the nameservers should not share the same IP address is unnecessary; topological diversity is ensured through test (10). </dd> <dt>(2)</dt> <dd>Maximum Number of Nameservers. DELETE. This requirement is encapsulated more appropriately within proposed new test (a). </dd> <dt>(3)</dt> <dd>Hostname Validity. MANDATORY, MODIFY. The requirement should be changed to match exactly what is specified in <a class="info" href="#RFC1034">[RFC1034]<span> (</span><span class="info">Mockapetris, P., “Domain names - concepts and facilities,” November 1987.</span><span>)</span></a> section 3.5. </dd> <dt>(4)</dt> <dd>Nameserver Reachability. MANDATORY. </dd> <dt>(5)</dt> <dd>Nameserver Authority. MANDATORY. </dd> <dt>(6)</dt> <dd>Nameserver Coherency. WARNING. The delegation NS set in the root zone may legitimately differ from the apex NS set in the delegated TLD zone, e.g. as part of a transition plan from one set of authority servers to another. </dd> <dt>(7)</dt> <dd>Glue Coherency with Hostname. MANDATORY. </dd> <dt>(8)</dt> <dd>Glue Coherency with Existing Glue. DELETE. A request to change a glue record in the root zone in order to renumber a nameserver should be processed as such, and should not trigger warnings. See also <a class="info" href="#ns-renumber">Section 7<span> (</span><span class="info">Renumbering Nameservers</span><span>)</span></a>. </dd> <dt>(9)</dt> <dd>Serial Number Consistency. WARNING. For some zones, a difference in SOA serial between authority servers is a natural consequence of the rapid turnaround of changes submitted to a registry. </dd> <dt>(10)</dt> <dd>Minimum Network Diversity. MANDATORY, MODIFY. Network diversity cannot be judged accurately by simply calculating the arithmetic distance between IP addresses, nor by comparing observed AS_PATH attributes in covering routes. A combination of checks should be used to allow the IANA to gauge whether an NS set has appropriate topological diversity. The requirement should be that not all nameservers are colocated, not that no two nameservers are colocated. </dd> <dt>(11)</dt> <dd>Nameserver Continuity. WARNING. There are legitimate reasons for changes to be processed in a single atomic operation, without staging changes in the NS set as described. </dd> <dt>(12)</dt> <dd>Whether Nameservers have Matching PTR Records. WARNING. Although the management of PTR records is to be encouraged, their absence does not impact the performance of the DNS. </dd> <dt>(13)</dt> <dd>Whether Nameservers have RFC 1918 Addresses. MANDATORY. Due to lax operational attention to the uses of these address ranges on the Internet, it is possible to conceive of circumstances in which nameservers so-numbered might pass other tests, and so this ought to be checked explicitly. </dd> <dt>(14)</dt> <dd>Whether Nameservers are on the List of Reserved IP Addresses. MANDATORY, MODIFY. Reference should be made to <a class="info" href="#RFC3330">[RFC3330]<span> (</span><span class="info">IANA, “Special-Use IPv4 Addresses,” September 2002.</span><span>)</span></a>, to IPv4 multicast addresses and to the Unspecified, Loopback, Link-Local, Site-Local and Multicast IPv6 addresses specified in <a class="info" href="#RFC4291">[RFC4291]<span> (</span><span class="info">Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture,” February 2006.</span><span>)</span></a>. </dd> <dt>(15)</dt> <dd>Whether the Last Octet of the Nameserver IP Address is 0 or 255. DELETE. This requirement is obsoleted by <a class="info" href="#RFC4632">[RFC4632]<span> (</span><span class="info">Fuller, V. and T. Li, “Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan,” August 2006.</span><span>)</span></a>. </dd> <dt>(16)</dt> <dd>Whether the Overall Length of the Nameserver Hostname is less than 128 Characters. DELETE. This requirement is encapsulated more succinctly in proposed new test (a). </dd> </blockquote><p> </p> <blockquote class="text"> <dt>(a)</dt> <dd>Size of Referral NS RRset and Glue. MANDATORY, ADD. The size of the AUTHORITY and ADDITIONAL sections in a referral response from a root server should be sufficiently small that reasonable questions can be answered with a useful set of courtesy glue over UDP Transport without requiring EDNS0. The functional details of the corresponding test for this requirement should be specified with the assistance of root server operators. </dd> <dt>(b)</dt> <dd>EDNS0 Support. WARNING, ADD. Every nameserver should support <a class="info" href="#RFC2671">[RFC2671]<span> (</span><span class="info">Vixie, P., “Extension Mechanisms for DNS (EDNS0),” August 1999.</span><span>)</span></a>. </dd> <dt>(c)</dt> <dd>TCP Transport Support. WARNING, ADD. Every nameserver should support queries on both UDP and TCP transport. </dd> </blockquote><p> </p> <a name="anchor4"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table> <a name="rfc.section.4"></a><h3>4. Regular, Scheduled Testing</h3> <p>Afilias believes that the IANA should carry out regular, scheduled, automated testing of TLD zones and should make proactive contact with zone operators in the event that problems are detected. </p> <p>Early warning of test failure gives zone operators more opportunity to resolve problems, compared with the current process in which an urgent change request can be denied due to pre-existing problems unrelated to the requested change. </p> <a name="anchor5"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table> <a name="rfc.section.5"></a><h3>5. Roles of the IANA and Verisign</h3> <p>The IANA should carry out all tests, and should reject or clarify requests in the event that failures are evident in MANDATORY or WARNING checks, as appropriate. </p> <p>Verisign should carry out MANDATORY tests only. </p> <p>Afilias believes that there is benefit in having both the IANA and Verisign carry out the same set of MANDATORY tests, since this provides codebase diversity and helps to guard against systematic false negative responses from tests. </p> <a name="anchor6"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table> <a name="rfc.section.6"></a><h3>6. Treatment of WARNING Conditions by the IANA</h3> <p>In the event that a request is received which pre-acknowledges the results of one or more WARNING tests, the request should proceed without requiring further acknowledgement of the WARNING test results by the requestor. </p> <p>For example, a zone operator may be well aware that SOA serial numbers may differ between authority servers due to the architecture in place for zone changes to propagate between authority servers. If acknowledged in the original request, processing of the request should not be held up by the results of the corresponding WARNING test carried out by the IANA. </p> <a name="ns-renumber"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table> <a name="rfc.section.7"></a><h3>7. Renumbering Nameservers</h3> <p>Afilias suggests that the IANA should maintain point of contact details for nameservers for which glue exists in the root zone, as well as for zone operators. </p> <p>A request to renumber a nameserver should be accepted from the operator of any zone delegated to that nameserver, but confirmation from the nameserver operator for the change should be sought before the change is allowed to proceed. Requests to renumber a nameserver should also be accepted by the nameserver operator. </p> <p>When a nameserver is to be renumbered, notification of the change should be sent to the operators of all zones delegated to that nameserver. An additional delay should be instituted to give zone operators the opportunity to request changes to their zones' nameservers in response to the proposed nameserver change. </p> <a name="anchor7"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table> <a name="rfc.section.8"></a><h3>8. Documentation</h3> <p>Afilias believes that the IANA should publish the procedures and functional specification of the tests carried out in the IETF, as an informational RFC. Future changes to procedures or to the tests should be published as additional RFCs in the usual manner of the IETF. </p> <a name="rfc.references1"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table> <h3>9. References</h3> <table width="99%" border="0"> <tr><td class="author-text" valign="top"><a name="RFC1034">[RFC1034]</a></td> <td class="author-text">Mockapetris, P., “<a href="ftp://ftp.isi.edu/in-notes/rfc1034.txt";>Domain names - concepts and facilities</a>,” STD 13, RFC 1034, November 1987.</td></tr> <tr><td class="author-text" valign="top"><a name="RFC2671">[RFC2671]</a></td> <td class="author-text"><a href="mailto:vixie@xxxxxxx";>Vixie, P.</a>, “<a href="ftp://ftp.isi.edu/in-notes/rfc2671.txt";>Extension Mechanisms for DNS (EDNS0)</a>,” RFC 2671, August 1999.</td></tr> <tr><td class="author-text" valign="top"><a name="RFC3330">[RFC3330]</a></td> <td class="author-text">IANA, “<a href="ftp://ftp.isi.edu/in-notes/rfc3330.txt";>Special-Use IPv4 Addresses</a>,” RFC 3330, September 2002.</td></tr> <tr><td class="author-text" valign="top"><a name="RFC4291">[RFC4291]</a></td> <td class="author-text">Hinden, R. and S. Deering, “<a href="ftp://ftp.isi.edu/in-notes/rfc4291.txt";>IP Version 6 Addressing Architecture</a>,” RFC 4291, February 2006.</td></tr> <tr><td class="author-text" valign="top"><a name="RFC4632">[RFC4632]</a></td> <td class="author-text">Fuller, V. and T. Li, “<a href="ftp://ftp.isi.edu/in-notes/rfc4632.txt";>Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan</a>,” BCP 122, RFC 4632, August 2006.</td></tr> </table> <a name="rfc.authors"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="bug" align="right"><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></table> <h3>Authors' Addresses</h3> <table width="99%" border="0" cellpadding="0" cellspacing="0"> <tr><td class="author-text"> </td> <td class="author-text">Joe Abley</td></tr> <tr><td class="author-text"> </td> <td class="author-text">Afilias Canada Corp.</td></tr> <tr><td class="author-text"> </td> <td class="author-text">Suite 204</td></tr> <tr><td class="author-text"> </td> <td class="author-text">4141 Yonge Street</td></tr> <tr><td class="author-text"> </td> <td class="author-text">Toronto, ON M1A 2P8</td></tr> <tr><td class="author-text"> </td> <td class="author-text">Canada</td></tr> <tr><td class="author" align="right">Phone: </td> <td class="author-text">+1 416 673 4176</td></tr> <tr><td class="author" align="right">Email: </td> <td class="author-text"><a href="mailto:jabley@xxxxxxxxxxxxxxx";>jabley@xxxxxxxxxxxxxxx</a></td></tr> <tr><td class="author" align="right">URI: </td> <td class="author-text"><a href="http://afilias.info/";>http://afilias.info/</a></td></tr> <tr cellpadding="3"><td> </td><td> </td></tr> <tr><td class="author-text"> </td> <td class="author-text">Greg Berezowsky</td></tr> <tr><td class="author-text"> </td> <td class="author-text">Afilias Canada Corp.</td></tr> <tr><td class="author-text"> </td> <td class="author-text">Suite 204</td></tr> <tr><td class="author-text"> </td> <td class="author-text">4141 Yonge Street</td></tr> <tr><td class="author-text"> </td> <td class="author-text">Toronto, ON M1A 2P8</td></tr> <tr><td class="author-text"> </td> <td class="author-text">Canada</td></tr> <tr><td class="author" align="right">Phone: </td> <td class="author-text">+1 416 673 4122</td></tr> <tr><td class="author" align="right">Email: </td> <td class="author-text"><a href="mailto:gberezow@xxxxxxxxxxxxxxx";>gberezow@xxxxxxxxxxxxxxx</a></td></tr> <tr><td class="author" align="right">URI: </td> <td class="author-text"><a href="http://afilias.info/";>http://afilias.info/</a></td></tr> <tr cellpadding="3"><td> </td><td> </td></tr> <tr><td class="author-text"> </td> <td class="author-text">Andrew Sullivan</td></tr> <tr><td class="author-text"> </td> <td class="author-text">Afilias Canada Corp.</td></tr> <tr><td class="author-text"> </td> <td class="author-text">Suite 204</td></tr> <tr><td class="author-text"> </td> <td class="author-text">4141 Yonge Street</td></tr> <tr><td class="author-text"> </td> <td class="author-text">Toronto, ON M1A 2P8</td></tr> <tr><td class="author-text"> </td> <td class="author-text">Canada</td></tr> <tr><td class="author" align="right">Phone: </td> <td class="author-text">+1 416 673 4110</td></tr> <tr><td class="author" align="right">Email: </td> <td class="author-text"><a href="mailto:andrew@xxxxxxxxxxxxxxx";>andrew@xxxxxxxxxxxxxxx</a></td></tr> <tr><td class="author" align="right">URI: </td> <td class="author-text"><a href="http://afilias.info/";>http://afilias.info/</a></td></tr> <tr cellpadding="3"><td> </td><td> </td></tr> <tr><td class="author-text"> </td> <td class="author-text">Howard Eland</td></tr> <tr><td class="author-text"> </td> <td class="author-text">Afilias USA, Inc.</td></tr> <tr><td class="author-text"> </td> <td class="author-text">300 Welsh Road</td></tr> <tr><td class="author-text"> </td> <td class="author-text">Building 3, Suite 105</td></tr> <tr><td class="author-text"> </td> <td class="author-text">Horsham, PA 19044</td></tr> <tr><td class="author-text"> </td> <td class="author-text">USA</td></tr> <tr><td class="author" align="right">Phone: </td> <td class="author-text">+1 215 366 2758</td></tr> <tr><td class="author" align="right">Email: </td> <td class="author-text"><a href="mailto:heland@xxxxxxxxxxxx";>heland@xxxxxxxxxxxx</a></td></tr> <tr><td class="author" align="right">URI: </td> <td class="author-text"><a href="http://afilias.info/";>http://afilias.info/</a></td></tr> </table> </body></html> Attachment:
afilias-root-zone-checks.zip |