< draft-wkumari-dnsop-omniscient-as112-00.txt   draft-wkumari-dnsop-omniscient-as112-01.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: BCP NRC-CNRC Intended status: Informational NRC-CNRC
Expires: December 1, 2012 J. Abley Expires: March 2, 2013 J. Abley
ICANN ICANN
May 30, 2012 R. Bellis
Nominet UK
August 29, 2012
Omniscient AS112 Servers Omniscient AS112 Servers
draft-wkumari-dnsop-omniscient-as112-00 draft-wkumari-dnsop-omniscient-as112-01
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 the 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, directing the load instead servers that would otherwise receive them, and instead direct the
to name servers operated within the AS112 project. load to name servers operated within the AS112 project.
Adding and dropping zones from the AS112 servers is difficult, due to Adding and dropping zones from the AS112 servers is difficult, due to
the loosely-coordinated nature of the project. This document the loosely-coordinated nature of the project. This document
proposes a mechanism by which AS112 name servers could answer proposes a mechanism by which AS112 name servers could answer
authoritatively for all possible zones, reducing the add/drop problem authoritatively for all possible zones. This eliminates the add/drop
to one of delegation within the DNS without operational impact on the problem, changing it to a matter of delegation within the DNS and
servers themselves. requiring no operational changes on the servers themselves.
This document updates RFC 6304. This document updates RFC 6304.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 December 1, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Considerations . . . . . . . . . . . . . . . . . . . 4 3. Protocol Considerations . . . . . . . . . . . . . . . . . . . 5
4. Operational Considerations . . . . . . . . . . . . . . . . . . 4 4. Operational Considerations . . . . . . . . . . . . . . . . . . 6
5. Addressing Considerations . . . . . . . . . . . . . . . . . . 5 5. Addressing Considerations . . . . . . . . . . . . . . . . . . 7
6. Updates to RFC 6304 . . . . . . . . . . . . . . . . . . . . . 5 6. Updates to RFC 6304 . . . . . . . . . . . . . . . . . . . . . 7
6.1. Changes to Section 3.4, Routing Software . . . . . . . . . 5 6.1. Changes to Section 3.4, Routing Software . . . . . . . . . 7
6.2. Changes to Section 3.5, DNS Software . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . 10 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. Document Notes . . . . . . . . . . . . . . . . . . . 11 Appendix A. Implementation / "Running Code" . . . . . . . . . . . 11
A.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Appendix B. Document Notes . . . . . . . . . . . . . . . . . . . 11
A.2. Textual Substitutions . . . . . . . . . . . . . . . . . . 11 B.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 11
A.3. Open Questions . . . . . . . . . . . . . . . . . . . . . . 11 B.2. Textual Substitutions . . . . . . . . . . . . . . . . . . 11
A.4. Change History . . . . . . . . . . . . . . . . . . . . . . 11 B.3. Open Questions . . . . . . . . . . . . . . . . . . . . . . 11
A.4.1. draft-wkumari-dnsop-omniscient-as112-00 . . . . . . . 11 B.4. Change History . . . . . . . . . . . . . . . . . . . . . . 11
A.4.2. draft-wkumari-omniscient-as112-00 . . . . . . . . . . 12 B.4.1. draft-wkumari-dnsop-omniscient-as112-00 . . . . . . . 11
B.4.2. draft-wkumari-dnsop-omniscient-as112-00 . . . . . . . 12
B.4.3. draft-wkumari-omniscient-as112-00 . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 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
skipping to change at page 3, line 31 skipping to change at page 4, line 31
Other DNS domains have analogously local significance. Examples Other DNS domains have analogously local significance. Examples
corresponding to the reverse-mapping of special-use IPv4 and IPv6 corresponding to the reverse-mapping of special-use IPv4 and IPv6
addresses can be found in [RFC6303]. addresses can be found in [RFC6303].
It is to be expected that new domains will be identified from time to It is to be expected that new domains will be identified from time to
time that fit the use pattern for which delegation to AS112 servers time that fit the use pattern for which delegation to AS112 servers
might be desirable. There is currently no mechanism by which might be desirable. There is currently no mechanism by which
particular zones can be reliably added to or dropped from AS112 particular zones can be reliably added to or dropped from AS112
servers, however. This is principally a consequence of the loosely- servers, however. This is principally a consequence of the loosely-
coordinated nature of the project, coupled with a desire to avoid coordinated nature of the project, coupled with a desire to avoid
lame delegations which might have unforseen operational consequences. lame delegations which might have unforeseen operational
consequences.
This document proposes a mechanism by which AS112 servers could This document proposes a mechanism by which AS112 servers could
provide consistent, reliable negative responses for all DNS queries, provide consistent, reliable negative responses for all DNS queries,
eliminating the operational requirement to add or drop particular eliminating the operational requirement to add or drop particular
zones from all AS112 servers. zones from all AS112 servers.
2. Terminology 2. Terminology
An "Existing AS112 Server" is a DNS name server configured according An "Existing AS112 Server" is a DNS name server configured according
to the guidance provided in [RFC6304] and listening on the IPv4 to the guidance provided in [RFC6304] and listening on the IPv4
skipping to change at page 4, line 14 skipping to change at page 5, line 15
used. used.
An "AS112 Zone" is a DNS zone which has been delegated to an AS112 An "AS112 Zone" is a DNS zone which has been delegated to an AS112
Server. Server.
An "Existing AS112 Zone" is an AS112 Zone which has been delegated to An "Existing AS112 Zone" is an AS112 Zone which has been delegated to
an existing AS112 Server. an existing AS112 Server.
3. Protocol Considerations 3. Protocol Considerations
An AS112 Server responds with an authoritative (AA=1) name error Familiarity with [RFC1034] and [RFC1035] is assumed.
(NXDOMAIN, RCODE=3) for any query request whose (QNAME, QCLASS) falls
within an AS112 Zone [RFC1035].
AS112 Servers do not respond to zone transfer requests (QTYPE=252). In order to safely cache the response, DNS implementations require
the closest-enclosing SOA to be returned. An omniscient AS112 server
(which is not configured with a specific list of zones, and hence
zone cuts) cannot necessarily know where that is. Removing labels
and guessing (whether to the extreme case of removing all labels, or
returning one, or anything in between) cannot be guaranteed to be
appropriate, since the answers might clash with authentic answers
already present in client caches. A client that has followed a
referral to an omniscient AS112 server is guaranteed not to have a
cached SOA that matches the QNAME, however, so Omnicinet AS112
servers use the QNAME as the SOA and owner name.
The name error (NXDOMAIN) response from an Omnisicient AS112 Server Please see Appendix A for information on an implementation ("running
differs from that sent by an Existing AS112 Server in that the code") that does this.
closest enclosing SOA returned has a different owner name. Existing
AS112 Servers return an authority-section SOA with an owner name AS112 Servers do not respond to AXFR (QTYPE=252) or IXFR (QTYPE=251)
corresponding to the apex of the AS112 Zone concerned; Omniscient requests.
AS112 Servers return an SOA with an owner name of ".". This
difference has not been shown to cause any practical change in A TYPE=6 (SOA) resource record for Omniscient AS112 servers contains:
behaviour in commonly-deployed DNS resolver software. o MNAME = "a.as112.net."
o RNAME = "hostmaster.as112.net."
o SERIAL = 1
o REFRESH =604800 (7 days)
o RETRY = 2592000 (30 days)
o EXPIRE = 604800 (7 days)
o MINIMUM = 604800 (7 days, negative caching TTL)
For all queries with QTYPE=2 (NS) an AS112 Server responds with an
authoritative (AA=1) answer with NoError (RCODE=0), the owner name
copied from the QNAME and two resource records of TYPE=2 (NS), one
containing "B.AS112.NET." and the containing "C.AS112.NET.".
For all queries with QTYPE=6 (SOA) an AS112 Server responds with an
authoritative (AA=1) answer with NoError (RCODE=0), the owner name
copied from the QNAME and one (ANCOUNT=1) resource record of TYPE=6
(SOA).
For all queries with QTYPE= 255 (*, also known as ANY) an AS112
Server responds with an authoritative (AA=1) answer with NoError
(RCODE=0) the owner name copied from the QNAME and three (ANCOUNT=3)
resource records, one containing the SOA (as described above), and
two containing NS (also as described above).
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
the request and no answers (ANCOUNT=0). The resource record of
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
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 in order to add or drop the zone. Server operators.
There is no practical expectation that AS112 Server operators There is no practical expectation that AS112 Server operators
coordinate the configuration of their infrastructure or even make coordinate the configuration of their infrastructure or even make
their existence known in any systematic way. Delegation of new zones their existence known in any systematic way. Delegation of new zones
to Existing AS112 Servers is hence problematic; there is an to Existing AS112 Servers is hence problematic; there is an
expectation that such delegations would be lame for a significant expectation that such delegations would be lame for a significant
client population. Since the predictable behaviour of AS112 Servers client population. Since the predictable behaviour of AS112 Servers
from clients is desirable, and it is possible that significant from clients is desirable, and it is possible that significant
variation would have operational consequences, no new zones should be variation would have operational consequences, no new zones should be
delegated to existing AS112 Servers. delegated to existing AS112 Servers.
Omniscient AS112 Servers serve an unsigned root zone, containing only Omniscient AS112 Servers generate a response (as described in
required apex SOA and NS records. Adding or dropping a delegation Section3 (Section 3)) as though they are authoritative for everything
for an AS112 Zone requires imposes no operational requirements on ("."). Adding or dropping a delegation for an AS112 Zone therefore
Omniscient AS112 Server operators. imposes no operational requirements on Omniscient AS112 Server
operators.
Delegation of new AS112 Zones should only be made to Omniscient AS112 Delegation of new AS112 Zones should only be made to Omniscient AS112
Servers. The desire to delegate new AS112 Zones therefore imposes a Servers. Omniscient AS112 Servers, therefore, must listen on
requirement on Omnisicient AS112 Servers to listen on addresses which additional addresses to those used by existing AS112 Servers.
are different to those used by Existing AS112 Servers. Addressing is Addressing is discussed in Section 5.
discussed in Section 5.
By ensuring that Omnisicient AS112 Servers listen on Existing AS112 By ensuring that Omniscient AS112 Servers listen on Existing AS112
Servers' addresses as well as the new addresses specified in Servers' addresses as well as the new addresses specified in
Section 5 a smooth migration is possible, allowing Existing AS112 Section 5 a smooth migration is possible, allowing Existing AS112
Servers to be reconfigured as Omnisicient AS112 Servers. Omnisicient Servers to be reconfigured as Omniscient AS112 Servers. Omniscient
AS112 Servers are therefore a superset of AS112 Servers. AS112 Servers are therefore a superset of AS112 Servers.
5. Addressing Considerations 5. Addressing Considerations
Omniscient AS112 Servers listen on the following addresses: Omniscient AS112 Servers listen on the following addresses:
o IPv4-TBA1 (A.AS112.NET) o IPv4-TBA1 (A.AS112.NET)
o IPv6-TBA1 (A.AS112.NET) o IPv6-TBA1 (A.AS112.NET)
o IPv4-TBA2 (B.AS112.NET) o IPv4-TBA2 (B.AS112.NET)
o IPv6-TBA2 (B.AS112.NET) o IPv6-TBA2 (B.AS112.NET)
o IPv4-TBA3 (C.AS112.NET) o IPv4-TBA3 (C.AS112.NET)
o IPv6-TBA3 (C.AS112.NET) o IPv6-TBA3 (C.AS112.NET)
Pv4-TBA1, IPv4-TBA2 and IPv4-TBA3 are covered by a single IPv4 IPv4-TBA1, IPv4-TBA2 and IPv4-TBA3 are covered by a single IPv4
prefix, IPv4-PREFIX-TBA. Similarly, IPv6-TBA1, IPv6-TBA2 and IPv6- prefix, IPv4-PREFIX-TBA. Similarly, IPv6-TBA1, IPv6-TBA2 and IPv6-
TBA3 are covered by a single IPv6 prefix, IPv6-PREFIX-TBA. TBA3 are covered by a single IPv6 prefix, IPv6-PREFIX-TBA.
The addresses specified for Omnisicient AS112 Servers are The addresses specified for Omniscient AS112 Servers are deliberately
deliberately different from those assigned to Existing AS112 Servers different from those assigned to Existing AS112 Servers for reasons
for reasons discussed in Section 4. discussed in Section 4.
6. Updates to RFC 6304 6. Updates to RFC 6304
6.1. Changes to Section 3.4, Routing Software 6.1. Changes to Section 3.4, Routing Software
Omnisicient AS112 Nodes with IPv4 connectivity should originate the Omniscient AS112 Nodes with IPv4 connectivity should originate the
IPv4 service prefix associated with Existing AS112 Nodes, IPv4 service prefix associated with Existing AS112 Nodes,
192.175.48.0/24, and also the IPv4 service prefix associated with 192.175.48.0/24, and also the IPv4 service prefix associated with
Omniscient AS112 Nodes, IPv4-PREFIX. Omniscient AS112 Nodes, IPv4-PREFIX.
Omniscient AS112 Nodes with IPv6 connectivity should originate the Omniscient AS112 Nodes with IPv6 connectivity should originate the
IPv6 service prefix IPv6-PREFIX-TBA. IPv6 service prefix IPv6-PREFIX-TBA.
Applying this direction to the "bgpd.conf" file included as an Applying this direction to the "bgpd.conf" file included as an
example in this section results in the configuration shown in example in this section results in the configuration shown in
Figure 1. Figure 1.
skipping to change at page 7, line 4 skipping to change at page 8, line 50
address-family ipv6 unicast address-family ipv6 unicast
neighbor 2001:db8::1 remote-as 64496 neighbor 2001:db8::1 remote-as 64496
neighbor 2001:db8::1 next-hop-self neighbor 2001:db8::1 next-hop-self
neighbor 2001:db8::1 prefix-list AS112-v6 out neighbor 2001:db8::1 prefix-list AS112-v6 out
neighbor 2001:db8::1 filter-list 1 out neighbor 2001:db8::1 filter-list 1 out
neighbor 2001:db8::2 remote-as 64497 neighbor 2001:db8::2 remote-as 64497
neighbor 2001:db8::2 next-hop-self neighbor 2001:db8::2 next-hop-self
neighbor 2001:db8::2 prefix-list AS112-v6 out neighbor 2001:db8::2 prefix-list AS112-v6 out
neighbor 2001:db8::2 filter-list 1 out neighbor 2001:db8::2 filter-list 1 out
network IPv6-PREFIX-TBA network IPv6-PREFIX-TBA
! !
ip prefix-list AS112-v4 permit 192.175.48.0/24 ip prefix-list AS112-v4 permit 192.175.48.0/24
ip prefix-list AS112-v4 permit IPv4-PREFIX-TBA ip prefix-list AS112-v4 permit IPv4-PREFIX-TBA
! !
ipv6 prefix-list AS112-v6 permit IPv6-PREFIX-TBA ipv6 prefix-list AS112-v6 permit IPv6-PREFIX-TBA
! !
ip as-path access-list 1 permit ^$ ip as-path access-list 1 permit ^$
Figure 1 Figure 1
6.2. Changes to Section 3.5, DNS Software 6.2. Changes to Section 3.5, DNS Software
Omniscient AS112 Servers with IPv4 connectivity should include DNS Omniscient AS112 Servers should be configured to listen on the
software configured to listen on the addresses IPv4-TBA1, IPv4-TBA2 addresses Pv6-TBA1, IPv6-TBA, IPv6-TBA3, IPv4-TBA1, IPv4-TBA2 and
and IPv4-TBA3 in addition to the addresses used by Existing AS112 IPv4-TBA3 in addition to the addresses used for Existing AS112
Servers. Servers.
Omniscient AS112 Servers with IPv6 connectivity should include DNS Omniscient AS112 Servers generate an answer as described in Section 3
software configured to listen on the addresses IPv6-TBA1, IPv6-TBA2 instead of explicitly serving the zones specified in [RFC6304].
and IPv6-TBA3.
Omniscient AS112 Servers serve an empty, unsigned root zone instead
of explicitly serving the zones specified in [RFC6304].
Applying this direction to the "named.conf" file included as an
example in this section results in the configuration fragment shown
in Figure 2.
options {
// The following configuration stanza is for Omniscient AS112
// Servers with IPv4 connectivity
listen-on {
127.0.0.1; // localhost
// The following address is node-dependent and should be set to
// something appropriate for the new AS112 node.
203.0.113.1; // local address (globally unique, unicast)
// the following addresses correspond to Existing AS112 Server
// addresses
192.175.48.1; // prisoner.iana.org (anycast)
192.175.48.6; // blackhole-1.iana.org (anycast)
192.175.48.42; // blackhole-2.iana.org (anycast)
// the following addresses are required by Omniscient AS112 Servers
IPv4-TBA1; // A.AS112.NET
IPv4-TBA2; // B.AS112.NET
IPv4-TBA3; // C.AS112.NET
};
// The following configuration stanza is for Omniscient AS112
// Servers with IPv6 connectivity
listen-on-v6 {
::1; // localhost
IPv6-TBA1; // A.AS112.NET
IPv6-TBA2; // B.AS112.NET
IPv6-TBA3; // C.AS112.NET
};
directory "/var/named";
recursion no; // authoritative-only server
query-source address *;
};
// Log queries, so that when people call us about unexpected
// answers to queries they didn't realise they had sent, we
// have something to talk about. Note that activating this
// has the potential to create high CPU load and consume
// enormous amounts of disk space.
logging {
channel "querylog" {
file "/var/log/query.log" versions 2 size 500m;
print-time yes;
};
category queries { querylog; };
};
// Substantially empty root zone (replaces explicit zone
// configuration specified in RFC 6304 for Existing AS112 Servers)
zone "." {
type master;
file "db.empty";
};
// Also answer authoritatively for the HOSTNAME.AS112.NET zone,
// which contains data of operational relevance.
zone "hostname.as112.net" {
type master;
file "db.hostname.as112.net";
// No other zones should be hosted on this name server.
};
Figure 2
The "db.empty" file is updated to include references to nameservers
used by Omniscient AS112 Servers, as shown in Figure 3.
; db.empty
;
; Empty zone for AS112 server.
;
$TTL 1W
@ IN SOA A.AS112.NET. hostmaster.root-servers.org. (
1 ; serial number
1W ; refresh
1M ; retry
1W ; expire
1W ) ; negative caching TTL
;
NS B.AS112.NET.
NS C.AS112.NET.
;
; There should be no other resource records included in this zone.
;
Figure 3 As ISC BIND [BIND]does not provide the required functionality a
custom nameserver implementation needs to be deployed, and so the
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.
7. IANA Considerations 7. IANA Considerations
skipping to change at page 10, line 32 skipping to change at page 10, line 22
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,
Shane Kerr and Bill Manning in the preparation of this document. Bill Manning, George Michaelson, Mark Andrews, Shane Kerr and S.
Moonesamy 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.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998.
[RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations", [RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations",
RFC 6304, July 2011. RFC 6304, July 2011.
10.2. Informative References 10.2. Informative References
[BIND] Nominet UK, "Internet Systems Consortium, "BIND"",
<http://www.isc.org/>.
[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163,
RFC 6303, July 2011. RFC 6303, July 2011.
Appendix A. Document Notes [evldns] Bellis, R., "evldns", <http://code.google.com/p/evldns/>.
Appendix A. Implementation / "Running Code"
The "evldns" [evldns] library (written by Ray Bellis, Nominet UK)
includes an Omniscient AS112 Server implementation in the file
"oas112d.c"
Appendix B. Document Notes
This section (and sub-sections) contain information useful for This section (and sub-sections) contain information useful for
development and review of this document, and should be removed prior development and review of this document, and should be removed prior
to publication. to publication.
A.1. Venue B.1. Venue
This document is an individual submission, and is not the product of This document is an individual submission, and is not the product of
an IETF working group. However, a suitable venue for discussion is an IETF working group. However, a suitable venue for discussion is
the dnsop working group mailing list. the dnsop working group mailing list.
A.2. Textual Substitutions B.2. Textual Substitutions
The strings "IPv4-TBA1", "IPv4-TBA2" and "IPv4-TBA3" should be The strings "IPv4-TBA1", "IPv4-TBA2" and "IPv4-TBA3" should be
replaced in this document should be replaced with IPv4 addresses replaced in this document should be replaced with IPv4 addresses
assigned for the purpose described. The covering IPv4 prefix for all assigned for the purpose described. The covering IPv4 prefix for all
three addresses should replace the string "IPv4-PREFIX-TBA". three addresses should replace the string "IPv4-PREFIX-TBA".
Similarly, the strings "IPv6-TBA1", "IPv6-TBA2", "IPv6-TBA3" and Similarly, the strings "IPv6-TBA1", "IPv6-TBA2", "IPv6-TBA3" and
"IPv6-PREFIX-TBA" should be substituted in the text with assigned "IPv6-PREFIX-TBA" should be substituted in the text with assigned
production values. production values.
A.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.
A.4. Change History B.4. Change History
A.4.1. draft-wkumari-dnsop-omniscient-as112-00 B.4.1. draft-wkumari-dnsop-omniscient-as112-00
o Rewrote much of the document (especially Section 3 to explain how
(and why) resonses should be generated.
o Updated "Updates to RFC 6304" section to explain the BIND does not
currently implement this, and so named.conf, etc should be
ignored.
o Removed example "empty" zone.
o Changed the addressing bit at the suggestion of SM.
B.4.2. 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.
A.4.2. draft-wkumari-omniscient-as112-00 B.4.3. draft-wkumari-omniscient-as112-00
Initial draft, circulated privately, not submitted. 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
skipping to change at page 12, line 27 skipping to change at page 13, line 4
Email: warren@kumari.net Email: warren@kumari.net
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: wfms@ryouko.imsb.nrc.ca Email: wfms@ryouko.imsb.nrc.ca
Joe Abley Joe Abley
ICANN ICANN
12025 Waterfront Drive, Suite 300 12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536 Los Angeles, CA 90094-2536
USA USA
Phone: +1 519 670 9327 Phone: +1 519 670 9327
Email: joe.abley@icann.org Email: joe.abley@icann.org
Ray Bellis
Nominet UK
Edmund Halley Road
Oxford, OX4 4DQ
United Kingdom
Phone: +44 1865 332211
Email: ray.bellis@nominet.org.uk
 End of changes. 39 change blocks. 
178 lines changed or deleted 149 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/