draft-ietf-dnsop-as112-ops-01.txt   draft-ietf-dnsop-as112-ops-02.txt 
Network Working Group J. Abley Network Working Group J. Abley
Internet-Draft Afilias Canada Internet-Draft TekSavvy
Intended status: Informational W. Maton Intended status: Informational W. Maton
Expires: May 19, 2008 NRC-CNRC Expires: September 10, 2009 NRC-CNRC
November 16, 2007 March 9, 2009
AS112 Nameserver Operations AS112 Nameserver Operations
draft-ietf-dnsop-as112-ops-01 draft-ietf-dnsop-as112-ops-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 19, 2008. This Internet-Draft will expire on September 10, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
Many sites connected to the Internet make use of IPv4 addresses which Many sites connected to the Internet make use of IPv4 addresses which
are not globally unique. Examples are the addresses designated in are not globally unique. Examples are the addresses designated in
RFC1918 for private use within individual sites. RFC1918 for private use within individual sites.
Devices in such environments may occasionally originate reverse DNS Devices in such environments may occasionally originate reverse DNS
queries corresponding to those private-use addresses. Since the queries corresponding to those private-use addresses. Since the
addresses concerned have only local significance, it is good practice addresses concerned have only local significance, it is good practice
skipping to change at page 3, line 7 skipping to change at page 4, line 7
addresses and the continuing growth of the Internet, the volume of addresses and the continuing growth of the Internet, the volume of
such queries is large and growing. The AS112 project aims to provide such queries is large and growing. The AS112 project aims to provide
a distributed sink for such queries in order to reduce the load on a distributed sink for such queries in order to reduce the load on
the root and IN-ADDR.ARPA authority servers. the root and IN-ADDR.ARPA authority servers.
This document describes the steps required to install a new AS112 This document describes the steps required to install a new AS112
node, and offers advice relating to such a node's operation. node, and offers advice relating to such a node's operation.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. AS112 DNS Service . . . . . . . . . . . . . . . . . . . . . . 5 2. AS112 DNS Service . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Nameservers . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Nameservers . . . . . . . . . . . . . . . . . . . . . . . 6
3. Installation of a New Node . . . . . . . . . . . . . . . . . . 6 3. Installation of a New Node . . . . . . . . . . . . . . . . . . 7
3.1. Useful Background Knowledge . . . . . . . . . . . . . . . 6 3.1. Useful Background Knowledge . . . . . . . . . . . . . . . 7
3.2. Topological Location . . . . . . . . . . . . . . . . . . . 6 3.2. Topological Location . . . . . . . . . . . . . . . . . . . 7
3.3. Operating System and Host Considerations . . . . . . . . . 6 3.3. Operating System and Host Considerations . . . . . . . . . 7
3.4. Routing Software . . . . . . . . . . . . . . . . . . . . . 7 3.4. Routing Software . . . . . . . . . . . . . . . . . . . . . 8
3.5. DNS Software . . . . . . . . . . . . . . . . . . . . . . . 8 3.5. DNS Software . . . . . . . . . . . . . . . . . . . . . . . 9
3.6. Testing a Newly-Installed Node . . . . . . . . . . . . . . 11 3.6. Testing a Newly-Installed Node . . . . . . . . . . . . . . 12
4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Downtime . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Downtime . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3. Statistics and Measurement . . . . . . . . . . . . . . . . 12 4.3. Statistics and Measurement . . . . . . . . . . . . . . . . 13
5. Communications . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Communications . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Future Usefulness of AS112 Nodes . . . . . . . . . . . . . . . 14 6. Future Usefulness of AS112 Nodes . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
Appendix A. History . . . . . . . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 19 Appendix A. History . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix C. Change History . . . . . . . . . . . . . . . . . . . 20 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Appendix C. Change History . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Many sites connected to the Internet make use of IPv4 addresses which Many sites connected to the Internet make use of IPv4 addresses which
are not globally unique. Examples are the addresses designated in are not globally unique. Examples are the addresses designated in
[RFC1918] for private use within individual sites. [RFC1918] for private use within individual sites.
Devices in such environments may occasionally originate reverse DNS Devices in such environments may occasionally originate reverse DNS
queries [RFC1034] corresponding to those private-use addresses. queries [RFC1034] corresponding to those private-use addresses.
Since the addresses concerned have only local significance, it is Since the addresses concerned have only local significance, it is
good practice for site administrators to ensure that they are good practice for site administrators to ensure that they are
answered locally [I-D.andrews-full-service-resolvers]. However, it answered locally [I-D.ietf-dnsop-default-local-zones]. However, it
is not uncommon for such queries to follow the normal delegation path is not uncommon for such queries to follow the normal delegation path
in the public DNS instead of being answered within the site. in the public DNS instead of being answered within the site.
It is not possible for public DNS servers to give useful answers to It is not possible for public DNS servers to give useful answers to
such queries. In addition, due to the wide deployment of private-use such queries. In addition, due to the wide deployment of private-use
addresses and the continuing growth of the Internet, the volume of addresses and the continuing growth of the Internet, the volume of
such queries is large and growing. The AS112 project aims to provide such queries is large and growing. The AS112 project aims to provide
a distributed sink for such queries in order to reduce the load on a distributed sink for such queries in order to reduce the load on
the root and IN-ADDR.ARPA authority servers. the root and IN-ADDR.ARPA authority servers.
skipping to change at page 14, line 10 skipping to change at page 15, line 10
Information about an AS112 node should also be published within the Information about an AS112 node should also be published within the
DNS, within the "HOSTNAME.AS112.NET" zone. See Section 3.5 for more DNS, within the "HOSTNAME.AS112.NET" zone. See Section 3.5 for more
details. details.
6. Future Usefulness of AS112 Nodes 6. Future Usefulness of AS112 Nodes
It is recommended practice for the operators of recursive nameservers It is recommended practice for the operators of recursive nameservers
to answer queries for zones served by AS112 nodes locally, such that to answer queries for zones served by AS112 nodes locally, such that
queries never have an opportunity to reach AS112 servers queries never have an opportunity to reach AS112 servers
[I-D.andrews-full-service-resolvers]. Operational experience with [I-D.ietf-dnsop-default-local-zones]. Operational experience with
AS112 nodes does not currently indicate an observable trend towards AS112 nodes does not currently indicate an observable trend towards
compliance with those recommendations, however. compliance with those recommendations, however.
It is expected that some DNS software vendors will include default It is expected that some DNS software vendors will include default
configuration which will implement measures such as those described configuration which will implement measures such as those described
in [I-D.andrews-full-service-resolvers]. If such software is widely in [I-D.ietf-dnsop-default-local-zones]. If such software is widely
deployed, it is reasonable to assume that the query load received by deployed, it is reasonable to assume that the query load received by
AS112 nodes will decrease; however, it is safe to assume that the AS112 nodes will decrease; however, it is safe to assume that the
query load will not decrease to zero, and consequently that AS112 query load will not decrease to zero, and consequently that AS112
nodes will continue to provide a useful service for the foreseeable nodes will continue to provide a useful service for the foreseeable
future. future.
There may be a requirement in the future for AS112 nodes to answer There may be a requirement in the future for AS112 nodes to answer
for their current set of zones over IPv6 transport. Such a for their current set of zones over IPv6 transport. Such a
requirement would necessitate the assignment of a corresponding IPv6 requirement would necessitate the assignment of a corresponding IPv6
netblock for use as an anycast service prefix. netblock for use as an anycast service prefix.
There may be a requirement in the future for AS112 nodes to serve There may be a requirement in the future for AS112 nodes to serve
additional zones, or to stop serving particular zones that are additional zones, or to stop serving particular zones that are
currently served. Such changes would be widely announced in currently served. Such changes would be widely announced in
operational forums, and published at <http://www.as112.net/>. operational forums, and published at <http://www.as112.net/>.
7. Security Considerations 7. IANA Considerations
The AS112 nameservers are all named under the domain IANA.ORG (see
Section 2.2). The IANA is the organisation responsible for the
coordination of many technical aspects of the Internet's basic
infrastructure. The AS112 project nameservers provide a public
service to the Internet which is sanctioned by and operated in
coordination with the IANA.
This document does not require any IANA actions.
8. Security Considerations
Hosts should never normally send queries to AS112 servers; queries Hosts should never normally send queries to AS112 servers; queries
relating to private-use addresses should be answered locally within a relating to private-use addresses should be answered locally within a
site. Hosts which send queries to AS112 servers may well leak site. Hosts which send queries to AS112 servers may well leak
information relating to private infrastructure to the public network, information relating to private infrastructure to the public network,
which could represent a security risk. This risk is orthogonal to which could represent a security risk. This risk is orthogonal to
the presence or absence of authority servers for these zones in the the presence or absence of authority servers for these zones in the
public DNS infrastructure, however. public DNS infrastructure, however.
Requests which are answered by AS112 servers are usually Requests which are answered by AS112 servers are usually
skipping to change at page 16, line 5 skipping to change at page 18, line 5
received by AS112 nodes might influence the behaviour of the hosts received by AS112 nodes might influence the behaviour of the hosts
sending the queries, such a compromise might be used as an attack sending the queries, such a compromise might be used as an attack
vector against private infrastructure. vector against private infrastructure.
Operators of AS112 should take appropriate measures to ensure that Operators of AS112 should take appropriate measures to ensure that
AS112 nodes are appropriately protected from compromise, such as AS112 nodes are appropriately protected from compromise, such as
would normally be employed for production nameserver or network would normally be employed for production nameserver or network
infrastructure. The guidance provided for root nameservers in infrastructure. The guidance provided for root nameservers in
[RFC2870] may be instructive. [RFC2870] may be instructive.
8. References 9. References
8.1. Normative References 9.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root [RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root
Name Server Operational Requirements", BCP 40, RFC 2870, Name Server Operational Requirements", BCP 40, RFC 2870,
June 2000. June 2000.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
Services", BCP 126, RFC 4786, December 2006. Services", BCP 126, RFC 4786, December 2006.
8.2. Informative References 9.2. Informative References
[I-D.andrews-full-service-resolvers] [I-D.ietf-dnsop-default-local-zones]
Andrews, M., "Configuration Issues Facing Full Service DNS Andrews, M., "Locally-served DNS Zones",
Resolvers In The Presence of Private Network Addressing", draft-ietf-dnsop-default-local-zones-08 (work in
draft-andrews-full-service-resolvers-02 (work in progress), February 2009.
progress), February 2006.
[ISC-TN-2003-1] [ISC-TN-2003-1]
Abley, J., "Hierarchical Anycast for Global Service Abley, J., "Hierarchical Anycast for Global Service
Distribution", Distribution",
<http://www.isc.org/pubs/tn/isc-tn-2003-1.html>. <http://www.isc.org/pubs/tn/isc-tn-2003-1.html>.
[RFC1876] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A [RFC1876] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A
Means for Expressing Location Information in the Domain Means for Expressing Location Information in the Domain
Name System", RFC 1876, January 1996. Name System", RFC 1876, January 1996.
skipping to change at page 21, line 5 skipping to change at page 22, line 17
This section to be removed prior to publication. This section to be removed prior to publication.
00 Initial draft, circulated as draft-jabley-as112-ops-00 and 00 Initial draft, circulated as draft-jabley-as112-ops-00 and
reviewed at the DNSOP working group meeting at IETF 66. reviewed at the DNSOP working group meeting at IETF 66.
00 Document adoped by the DNSOP working group and renamed 00 Document adoped by the DNSOP working group and renamed
accordingly. accordingly.
01 Input from reviewers of DNSOP and others, some cosmetic tweaks. 01 Input from reviewers of DNSOP and others, some cosmetic tweaks.
02 Version bump as request by working group chairs.
02 Added missing IANA Considerations section.
02 Updated author's addresses.
Authors' Addresses Authors' Addresses
Joe Abley Joe Abley
Afilias Canada Corp. TekSavvy Solutions, Inc.
Suite 204, 4141 Yonge Street 330 Richmond Street, Suite 205
Toronto, ON M2P 2A8 Chatham, ON N7M 1P7
Canada Canada
Phone: +1 416 673 4176 Phone: +1 519 670 9327
Email: jabley@ca.afilias.info Email: jabley@teksavvy.com
William F. Maton Sotomayor William F. Maton Sotomayor
National Research Council of Canada National Research Council of Canada
1200 Montreal Road 1200 Montreal Road
Ottawa, ON K1A 0R6 Ottawa, ON K1A 0R6
Canada Canada
Phone: +1 613 993 0880 Phone: +1 613 993 0880
Email: wmaton@ryouko.imsb.nrc.ca Email: wmaton@ryouko.imsb.nrc.ca
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 19 change blocks. 
53 lines changed or deleted 84 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/