< draft-wkumari-dnsop-omniscient-as112-01.txt   draft-wkumari-dnsop-omniscient-as112-02.txt >
Network Working Group W. Kumari Network Working Group W. Kumari
Internet-Draft Google Internet-Draft Google
Updates: 6304 (if approved) W. Sotomayor Updates: 6304 (if approved) W. Sotomayor
Intended status: Informational NRC-CNRC Intended status: Informational NRC-CNRC
Expires: March 2, 2013 J. Abley Expires: August 29, 2013 J. Abley
ICANN ICANN
R. Bellis R. Bellis
Nominet UK Nominet UK
August 29, 2012 February 25, 2013
Omniscient AS112 Servers Omniscient AS112 Servers
draft-wkumari-dnsop-omniscient-as112-01 draft-wkumari-dnsop-omniscient-as112-02
Abstract Abstract
The AS112 Project loosely coordinates Domain Name System (DNS) The AS112 Project loosely coordinates Domain Name System (DNS)
servers to which DNS zones corresponding to private use addresses are servers to which DNS zones corresponding to private use addresses are
delegated. Queries for names within those zones have no useful delegated. Queries for names within those zones have no useful
responses in a global context. The purpose of this project is to responses in a global context. The purpose of this project is to
reduce the load of such junk queries on the authoritative name reduce the load of such junk queries on the authoritative name
servers that would otherwise receive them, and instead direct the servers that would otherwise receive them, and instead direct the
load to name servers operated within the AS112 project. load to name servers operated within the AS112 project.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on March 2, 2013. This Internet-Draft will expire on August 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 22 skipping to change at page 3, line 22
6. Updates to RFC 6304 . . . . . . . . . . . . . . . . . . . . . 7 6. Updates to RFC 6304 . . . . . . . . . . . . . . . . . . . . . 7
6.1. Changes to Section 3.4, Routing Software . . . . . . . . . 7 6.1. Changes to Section 3.4, Routing Software . . . . . . . . . 7
6.2. Changes to Section 3.5, DNS Software . . . . . . . . . . . 9 6.2. Changes to Section 3.5, DNS Software . . . . . . . . . . . 9
6.3. Changes to Section 3.6, Testing a Newly Installed Node . . 9 6.3. Changes to Section 3.6, Testing a Newly Installed Node . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Implementation / "Running Code" . . . . . . . . . . . 11 Appendix A. Implementation / "Running Code" . . . . . . . . . . . 10
Appendix B. Document Notes . . . . . . . . . . . . . . . . . . . 11 Appendix B. Document Notes . . . . . . . . . . . . . . . . . . . 11
B.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 11 B.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 11
B.2. Textual Substitutions . . . . . . . . . . . . . . . . . . 11 B.2. Textual Substitutions . . . . . . . . . . . . . . . . . . 11
B.3. Open Questions . . . . . . . . . . . . . . . . . . . . . . 11 B.3. Open Questions . . . . . . . . . . . . . . . . . . . . . . 11
B.4. Change History . . . . . . . . . . . . . . . . . . . . . . 11 B.4. Change History . . . . . . . . . . . . . . . . . . . . . . 11
B.4.1. draft-wkumari-dnsop-omniscient-as112-00 . . . . . . . 11 B.4.1. draft-wkumari-dnsop-omniscient-as112-00 . . . . . . . 12
B.4.2. draft-wkumari-dnsop-omniscient-as112-00 . . . . . . . 12 B.4.2. draft-wkumari-omniscient-as112-00 . . . . . . . . . . 13
B.4.3. draft-wkumari-omniscient-as112-00 . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The AS112 Project loosely coordinates Domain Name System (DNS) The AS112 Project loosely coordinates Domain Name System (DNS)
servers [RFC1034] to which DNS zones corresponding to private use servers [RFC1034] to which DNS zones corresponding to private use
addresses are delegated. Queries for names within those zones have addresses are delegated. Queries for names within those zones have
no useful responses in a global context. The purpose of the project no useful responses in a global context. The purpose of the project
is to reduce the load of such junk queries on the authoritative name is to reduce the load of such junk queries on the authoritative name
servers that would otherwise receive them, directing the load instead servers that would otherwise receive them, directing the load instead
to name servers operated within the AS112 project. to name servers operated within the AS112 project.
skipping to change at page 5, line 26 skipping to change at page 5, line 26
In order to safely cache the response, DNS implementations require In order to safely cache the response, DNS implementations require
the closest-enclosing SOA to be returned. An omniscient AS112 server the closest-enclosing SOA to be returned. An omniscient AS112 server
(which is not configured with a specific list of zones, and hence (which is not configured with a specific list of zones, and hence
zone cuts) cannot necessarily know where that is. Removing labels zone cuts) cannot necessarily know where that is. Removing labels
and guessing (whether to the extreme case of removing all labels, or and guessing (whether to the extreme case of removing all labels, or
returning one, or anything in between) cannot be guaranteed to be returning one, or anything in between) cannot be guaranteed to be
appropriate, since the answers might clash with authentic answers appropriate, since the answers might clash with authentic answers
already present in client caches. A client that has followed a already present in client caches. A client that has followed a
referral to an omniscient AS112 server is guaranteed not to have a referral to an omniscient AS112 server is guaranteed not to have a
cached SOA that matches the QNAME, however, so Omnicinet AS112 cached SOA that matches the QNAME, however, so Omniscient AS112
servers use the QNAME as the SOA and owner name. servers use the QNAME as the SOA and owner name.
Please see Appendix A for information on an implementation ("running Please see Appendix A for information on an implementation ("running
code") that does this. code") that does this.
AS112 Servers do not respond to AXFR (QTYPE=252) or IXFR (QTYPE=251) AS112 Servers do not respond to AXFR (QTYPE=252) or IXFR (QTYPE=251)
requests. requests.
A TYPE=6 (SOA) resource record for Omniscient AS112 servers contains: A TYPE=6 (SOA) resource record for Omniscient AS112 servers contains:
o MNAME = "a.as112.net." o MNAME = "a.as112.net."
o RNAME = "hostmaster.as112.net." o RNAME = "hostmaster.as112.net."
o SERIAL = 1 o SERIAL = 1
o REFRESH =604800 (7 days) o REFRESH =604800 (7 days)
o RETRY = 2592000 (30 days) o RETRY = 2592000 (30 days)
o EXPIRE = 604800 (7 days) o EXPIRE = 604800 (7 days)
o MINIMUM = 604800 (7 days, negative caching TTL) o MINIMUM = 604800 (7 days, negative caching TTL)
For all queries with QTYPE=2 (NS) an AS112 Server responds with an For all queries with QTYPE=2 (NS) an AS112 Server responds with an
authoritative (AA=1) answer with NoError (RCODE=0), the owner name authoritative (AA=1) answer with NXDomain (RCODE=3), the owner name
copied from the QNAME and two resource records of TYPE=2 (NS), one copied from the QNAME and two resource records of TYPE=2 (NS), one
containing "B.AS112.NET." and the containing "C.AS112.NET.". containing "B.AS112.NET." and the containing "C.AS112.NET.".
For all queries with QTYPE=6 (SOA) an AS112 Server responds with an For all queries with QTYPE=6 (SOA) an AS112 Server responds with an
authoritative (AA=1) answer with NoError (RCODE=0), the owner name authoritative (AA=1) answer with NXDomain (RCODE=3), the owner name
copied from the QNAME and one (ANCOUNT=1) resource record of TYPE=6 copied from the QNAME and one (ANCOUNT=1) resource record of TYPE=6
(SOA). (SOA).
For all queries with QTYPE= 255 (*, also known as ANY) an AS112 For all queries with QTYPE= 255 (*, also known as ANY) an AS112
Server responds with an authoritative (AA=1) answer with NoError Server responds with an authoritative (AA=1) answer with NXDomain
(RCODE=0) the owner name copied from the QNAME and three (ANCOUNT=3) (RCODE=3) the owner name copied from the QNAME and three (ANCOUNT=3)
resource records, one containing the SOA (as described above), and resource records, one containing the SOA (as described above), and
two containing NS (also as described above). two containing NS (also as described above).
For all other queries an AS112 Server responds with an authoritative For all other queries an AS112 Server responds with an authoritative
(AA=1) NoError (RCODE=0) with the owner name copied from the QNAME in (AA=1) NoError (RCODE=0) with the owner name copied from the QNAME in
the request and no answers (ANCOUNT=0). The resource record of the request and no answers (ANCOUNT=0). The resource record of
TYPE=6 (SOA) (as described above) should be returned in the authority TYPE=6 (SOA) (as described above) should be returned in the authority
section. The presence of the SOA is to allow the negative cache TTL section. The presence of the SOA is to allow the negative cache TTL
to be set(see [RFC2308]). to be set(see [RFC2308]).
*** Editor note -- below paragraph be removed prior to publication.
It is here just to provide some background and to head off onlist
discussions :-P ***
[NoError was chosen instead of NXDOMAIN because we did not think that
we could reasonably return an SOA RR which clearly indicates that the
QNAME does exist, and also return an NXDOMAIN.]
4. Operational Considerations 4. Operational Considerations
Existing AS112 Servers address the protocol considerations described Existing AS112 Servers address the protocol considerations described
in Section 3 by serving each existing AS112 Zone explicitly. In each in Section 3 by serving each existing AS112 Zone explicitly. In each
case the zone contents are identical, containing only required apex case the zone contents are identical, containing only required apex
SOA and NS records. Adding or dropping a delegation for an Existing SOA and NS records. Adding or dropping a delegation for an Existing
AS112 Zone requires coordination amongst all deployed Existing AS112 AS112 Zone requires coordination amongst all deployed Existing AS112
Server operators. Server operators.
There is no practical expectation that AS112 Server operators There is no practical expectation that AS112 Server operators
skipping to change at page 9, line 22 skipping to change at page 9, line 15
6.2. Changes to Section 3.5, DNS Software 6.2. Changes to Section 3.5, DNS Software
Omniscient AS112 Servers should be configured to listen on the Omniscient AS112 Servers should be configured to listen on the
addresses Pv6-TBA1, IPv6-TBA, IPv6-TBA3, IPv4-TBA1, IPv4-TBA2 and addresses Pv6-TBA1, IPv6-TBA, IPv6-TBA3, IPv4-TBA1, IPv4-TBA2 and
IPv4-TBA3 in addition to the addresses used for Existing AS112 IPv4-TBA3 in addition to the addresses used for Existing AS112
Servers. Servers.
Omniscient AS112 Servers generate an answer as described in Section 3 Omniscient AS112 Servers generate an answer as described in Section 3
instead of explicitly serving the zones specified in [RFC6304]. instead of explicitly serving the zones specified in [RFC6304].
As ISC BIND [BIND]does not provide the required functionality a As ISC BIND [BIND] does not provide the required functionality a
custom nameserver implementation needs to be deployed, and so the custom nameserver implementation needs to be deployed, and so the
example "named.conf" file in this section can be disregarded. example "named.conf" file in this section can be disregarded.
6.3. Changes to Section 3.6, Testing a Newly Installed Node 6.3. Changes to Section 3.6, Testing a Newly Installed Node
Testing should include all configured service addresses for an Testing should include all configured service addresses for an
Omniscient AS112 Server (IPv4 or IPv6 or both, as appropriate). Note Omniscient AS112 Server (IPv4 or IPv6 or both, as appropriate). Note
that the IPv4 service addresses include those described in [RFC6304] that the IPv4 service addresses include those described in [RFC6304]
for Existing AS112 Servers. for Existing AS112 Servers.
skipping to change at page 10, line 22 skipping to change at page 10, line 14
The delegation of new zones to AS112 Servers has the potential to The delegation of new zones to AS112 Servers has the potential to
increase the traffic received by those servers. AS112 Server increase the traffic received by those servers. AS112 Server
operators are encouraged to monitor traffic levels, and to take operators are encouraged to monitor traffic levels, and to take
appropriate steps if traffic levels threaten the stability of their appropriate steps if traffic levels threaten the stability of their
networks. networks.
9. Acknowledgements 9. Acknowledgements
The authors thank and acknowledge the contributions of Dr Paul Vixie, The authors thank and acknowledge the contributions of Dr Paul Vixie,
Bill Manning, George Michaelson, Mark Andrews, Shane Kerr and S. Bill Manning, George Michaelson, Mark Andrews, Shane Kerr, Brian
Moonesamy in the preparation of this document. Dickson, S. Moonesamy, Chris Thompson, Nick Hilliard and all the folk
on the AS112 Project mailing lists in the preparation of this
document.
10. References 10. References
10.1. Normative References 10.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.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
skipping to change at page 11, line 42 skipping to change at page 11, line 36
production values. production values.
B.3. Open Questions B.3. Open Questions
1. Where to get IPv4 and IPv6 assignments from? There has already 1. Where to get IPv4 and IPv6 assignments from? There has already
been an assignment to DNS-OARC by ARIN for v6 service for AS112 been an assignment to DNS-OARC by ARIN for v6 service for AS112
servers. servers.
B.4. Change History B.4. Change History
B.4.1. draft-wkumari-dnsop-omniscient-as112-00 Template:
o Initial draft
o Initial draft, circulated privately, not submitted.
-00:
o Rewrote much of the document (especially Section 3 to explain how o Rewrote much of the document (especially Section 3 to explain how
(and why) resonses should be generated. (and why) resonses should be generated.
o Updated "Updates to RFC 6304" section to explain the BIND does not o Updated "Updates to RFC 6304" section to explain the BIND does not
currently implement this, and so named.conf, etc should be currently implement this, and so named.conf, etc should be
ignored. ignored.
o Removed example "empty" zone. o Removed example "empty" zone.
o Changed the addressing bit at the suggestion of SM. o Changed the addressing bit at the suggestion of SM.
B.4.2. draft-wkumari-dnsop-omniscient-as112-00 -01:
o Document title changed to include the dnsop keyword, so that IETF
document automation can send courtesy notifications of document
actions to the dnsop working group.
o Abstract and introduction expanded.
o RFC2119 requirements notation removed, since this is an
informational document and any normative language would be
toothless.
o Discussion broken out into Protocol Considerations, Operational
Considerations and Addressing Considerations.
o Reverted to the custom sowftware / synthesized answers.
o Added in the Ray Bellis evldns stuff.
-01 to -02:
o s/NoError/NXDomain/ -- Suggestion from Paul Vixie (and others).
"Nxd says there is no such name, no matter what the type was, and
there are no children. No data/noerror says there are either
other types or children or both. We know what the truth must be
and we know which implications we want the requestor to follow.
Right?" -- Paul.
o Need to retest with empty root zone, and "minimal responses".
Initial test didn't seem to suppress the 'Negative Answers from
Authoritative Servers' (rfc2308)
o Removed the ''Editor note: [NoError was chosen instead of NXDOMAIN
because we did not think that we could reasonably return an SOA RR
which clearly indicates that the QNAME does exist, and also return
an NXDOMAIN.]" as we are now using NXDomain :-P
o This version submitted by Warren, with no real discussion with co-
authors. Trying to squeeze things under the -01 cutoff.
B.4.1. draft-wkumari-dnsop-omniscient-as112-00
Document title changed to include the dnsop keyword, so that IETF Document title changed to include the dnsop keyword, so that IETF
document automation can send courtesy notifications of document document automation can send courtesy notifications of document
actions to the dnsop working group. actions to the dnsop working group.
Abstract and introduction expanded. Abstract and introduction expanded.
RFC2119 requirements notation removed, since this is an informational RFC2119 requirements notation removed, since this is an informational
document and any normative language would be toothless. document and any normative language would be toothless.
Discussion broken out into Protocol Considerations, Operational Discussion broken out into Protocol Considerations, Operational
Considerations and Addressing Considerations. Considerations and Addressing Considerations.
Detailed updates to [RFC6304] added. Detailed updates to [RFC6304] added.
B.4.3. draft-wkumari-omniscient-as112-00 B.4.2. draft-wkumari-omniscient-as112-00
Initial draft, circulated privately, not submitted.
Authors' Addresses Authors' Addresses
Warren Kumari Warren Kumari
Google Google
1600 Ampitheatre Parkway 1600 Ampitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
Email: warren@kumari.net Email: warren@kumari.net
 End of changes. 18 change blocks. 
32 lines changed or deleted 59 lines changed or added

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