< draft-gersch-dnsop-revdns-cidr-03.txt   draft-gersch-dnsop-revdns-cidr-04.txt >
Network Working Group J. Gersch Network Working Group J. Gersch
Internet-Draft Secure64 SW Corp Internet-Draft Secure64 SW Corp
Intended status: Informational D. Massey Intended status: Informational D. Massey
Expires: April 5, 2013 Maka'ala Networks Expires: August 29, 2013 Colorado State University
E. Osterweil E. Osterweil
Verisign Verisign
C. Olschanowsky C. Olschanowsky
Colorado State University Colorado State University
October 2, 2012 February 25, 2013
Reverse DNS Naming Convention for CIDR Address Blocks Reverse DNS Naming Convention for CIDR Address Blocks
draft-gersch-dnsop-revdns-cidr-03.txt draft-gersch-dnsop-revdns-cidr-04.txt
Abstract Abstract
This draft proposes a naming convention for encoding CIDR address This draft proposes a naming convention for encoding CIDR address
blocks into the reverse DNS namespace. The reverse DNS naming method blocks into the reverse DNS namespace. The reverse DNS naming method
is commonly used to specify a complete IP address. This document is commonly used to specify a complete IP address. This document
describes how to encode an IPv4 or IPv6 CIDR address block such as describes how to encode an IPv4 or IPv6 CIDR address block such as
129.82.0.0/16. By defining a common naming convention, one can 129.82.128.0/17. By defining a common naming convention, one can
associate information with a prefix. The convention builds on past associate information with a prefix. The convention builds on past
work in RFC 1101 that associates network names with prefixes. work in RFC 1101 that associates network names with prefixes.
However, this previous work pre-dated the introduction of CIDR and However, this previous work pre-dated the introduction of CIDR and
has several critical ambiguities. This convention corrects the has several critical ambiguities. This convention corrects the
ambiguities and enables new applications ranging from routing ambiguities and enables new applications ranging from routing
information to geolocation. information to geolocation.
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
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 April 5, 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 2, line 35 skipping to change at page 2, line 35
4.1. IPv4 Address Block Naming . . . . . . . . . . . . . . . . 9 4.1. IPv4 Address Block Naming . . . . . . . . . . . . . . . . 9
4.2. IPv6 Address Block Naming . . . . . . . . . . . . . . . . 11 4.2. IPv6 Address Block Naming . . . . . . . . . . . . . . . . 11
4.3. Maintaining one-to-one mapping . . . . . . . . . . . . . . 11 4.3. Maintaining one-to-one mapping . . . . . . . . . . . . . . 11
5. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Naming via RFC 1101 . . . . . . . . . . . . . . . . . . . 12 5.1. Naming via RFC 1101 . . . . . . . . . . . . . . . . . . . 12
5.2. CIDR Naming via RFC 2317 . . . . . . . . . . . . . . . . . 13 5.2. CIDR Naming via RFC 2317 . . . . . . . . . . . . . . . . . 13
5.3. Prior Work on CIDR Names for Routing . . . . . . . . . . . 14 5.3. Prior Work on CIDR Names for Routing . . . . . . . . . . . 14
6. Additional Considerations . . . . . . . . . . . . . . . . . . 16 6. Additional Considerations . . . . . . . . . . . . . . . . . . 16
6.1. Splitting a /16 into two /17s . . . . . . . . . . . . . . 16 6.1. Splitting a /16 into two /17s . . . . . . . . . . . . . . 16
6.2. Allocating a /16 and then assigning the /16 . . . . . . . 16 6.2. Allocating a /16 and then assigning the /16 . . . . . . . 16
6.3. Delegations that Span Octet boundaries . . . . . . . . . . 17 6.3. Delegations that Span Octet boundaries . . . . . . . . . . 16
6.4. Legacy Behavior at Octet Boundaries . . . . . . . . . . . 18 6.4. Legacy Behavior at Octet Boundaries . . . . . . . . . . . 17
6.5. The Naming Convention and Zone Structures . . . . . . . . 19 6.5. The Naming Convention and Zone Structures . . . . . . . . 17
6.6. Separation of Prefix Data and PTR Records . . . . . . . . 19 6.6. Separation of Prefix Data and PTR Records . . . . . . . . 17
6.7. Prefix Enumeration . . . . . . . . . . . . . . . . . . . . 20 6.7. Prefix Enumeration . . . . . . . . . . . . . . . . . . . . 18
6.8. Finding Longest Matches . . . . . . . . . . . . . . . . . 20 6.8. Finding Longest Matches . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
10. Change History . . . . . . . . . . . . . . . . . . . . . . . . 25 10. Change History . . . . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . . 27 11.2. Informative References . . . . . . . . . . . . . . . . . . 25
Appendix A. Example Zone Files . . . . . . . . . . . . . . . . . 28 Appendix A. Example Zone Files . . . . . . . . . . . . . . . . . 26
A.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 28 A.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 26
A.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 29 A.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
This draft proposes a common naming convention for entering CIDR This draft proposes a common naming convention for entering CIDR
prefixes into the Reverse DNS. prefixes into the Reverse DNS.
The Reverse DNS provides a naming convention for both IPv4 and IPv6 The Reverse DNS provides a naming convention for both IPv4 and IPv6
addresses. At this time, the most common use of the reverse-DNS is addresses. At this time, the most common use of the reverse-DNS is
to associate an IP address with a PTR resource record that identifies to associate an IP address with a PTR resource record that identifies
the corresponding host name. For example, IP address 129.82.138.2 is the corresponding host name. For example, IP address 129.82.138.2 is
skipping to change at page 5, line 22 skipping to change at page 5, line 22
is logically below 129.in-addr.arpa. This alignment between the DNS is logically below 129.in-addr.arpa. This alignment between the DNS
hierarchy and the IP address hierarchy serves both systems well and hierarchy and the IP address hierarchy serves both systems well and
allows one to easily encode prefixes that fall on an octet boundary allows one to easily encode prefixes that fall on an octet boundary
(e.g. IPv4 prefixes whose mask length is a multiple of 8). (e.g. IPv4 prefixes whose mask length is a multiple of 8).
The challenge is to preserve this alignment even when even when CIDR The challenge is to preserve this alignment even when even when CIDR
prefixes do not fall on octet boundaries. For example, prefixes do not fall on octet boundaries. For example,
129.82.128.0/19 is a subprefix of 129.82.128.0/18. The DNS name for 129.82.128.0/19 is a subprefix of 129.82.128.0/18. The DNS name for
129.82.128.0/19 should be logically below the DNS name for 129.82.128.0/19 should be logically below the DNS name for
129.82.128.0/18. This document introduces a naming convention for 129.82.128.0/18. This document introduces a naming convention for
CIDR prefixes that preserves this alignment. CIDR prefixes that preserves this alignment while also building on
the existing reverse DNS structure.
1.2. Purpose 1.2. Purpose
In order to enable the association of prefixes and data using reverse In order to enable the association of prefixes and data using reverse
DNS, one must map an IPv4 or IPv6 prefix into a reverse DNS name. DNS, one must map an IPv4 or IPv6 prefix into a reverse DNS name.
There are various subtleties, advantages and disadvantages that There are various subtleties, advantages and disadvantages that
emerge when trying to define a naming convention. This requires no emerge when trying to define a naming convention. This requires no
DNS protocol changes and no modifications to resolvers, caches, or DNS protocol changes and no modifications to resolvers, caches, or
authoritative servers. Today, zone administrators can use their own authoritative servers. Today, zone administrators can use their own
individual approaches to encode a prefix in the reverse DNS. The individual approaches to encode a prefix in the reverse DNS. The
skipping to change at page 13, line 23 skipping to change at page 13, line 23
This naming convention fails the "Unambiguous" requirement. We do This naming convention fails the "Unambiguous" requirement. We do
not consider additional issues since the above ambiguity makes the not consider additional issues since the above ambiguity makes the
RFC 1101 approach infeasible. The naming convention introduced later RFC 1101 approach infeasible. The naming convention introduced later
in this document builds on the main concepts in this RFC, resolves in this document builds on the main concepts in this RFC, resolves
the ambiguity, explicitly expands to more than just network names, the ambiguity, explicitly expands to more than just network names,
and addresses our design goals and operational concerns. and addresses our design goals and operational concerns.
5.2. CIDR Naming via RFC 2317 5.2. CIDR Naming via RFC 2317
According to [RFC2317] it describes "a way to do IN-ADDR.ARPA According to [RFC2317], the purpose of the document is to describe "a
delegation on non-octet boundaries for address spaces covering fewer way to do IN-ADDR.ARPA delegation on non-octet boundaries for address
than 256 addresses." It is not a general naming scheme for prefixes. spaces covering fewer than 256 addresses." It is not a general
However, some would argue that there is a "common understanding" for naming scheme for prefixes. However, some would argue that it might
how [RFC2317] might be extended into a general naming convention. be extended into a general naming convention.
There are obvious limitations to expanding the scope of any RFC to an
undocumented "common understanding"; the very purpose of a standard
is to provide clear written documentation. Nevertheless, there has
been sufficient discussion of [RFC2317]-like techniques that a
discussion of this technique is warranted.
To create a naming convention based on [RFC2317], we note a To create a naming convention based on [RFC2317], we note a
representative example maps prefix 192.0.2.0/25 to the DNS name representative example maps prefix 192.0.2.0/25 to the DNS name
0/25.2.0.192.in-addr.arpa. More generally, a prefix of the form 0/25.2.0.192.in-addr.arpa. More generally, a prefix of the form
A.B.C.D/M is mapped to the name D/M.C.B.A.in-addr.arpa. This is a A.B.C.D/M is mapped to the name D/M.C.B.A.in-addr.arpa. IPv6
type of naming convention; however IPv6 prefixes are not discussed prefixes are not discussed and the IPv4 mask length is assumed to be
and the IPv4 mask length is assumed to be strictly greater than 24. strictly greater than 24.
This approach becomes somewhat ambiguous for prefixes with a mask
length smaller than 24. For example, what is the [RFC2317] style
name for prefix 129.82.0.0/16? One might claim it maps to the DNS
name 0/16.0.82.129.in-addr.arpa. One might also claim it maps to the
DNS name 0/16.82.129.in-addr.arpa, or the DNS name 82/
16.129.in-addr.arpa, or the DNS name 82.129.in-addr.arpa. In fact,
[RFC2317] does not say which of these is correct. This is not a flaw
in the RFC. Instead, [RFC2317] says it is designed for "address
spaces covering fewer than 256 addresses". 129.82.0.0/16 covers over
65,000 addresses, is clearly out scope, and thus a name for this
prefix is not specified.
To extend this to a general naming convention, we assume that This approach does not satisfy the unambiguous requirement for
129.82.0.0/16 maps to the DNS name 82.129.in-addr.arpa, 129.82.0.0/18 prefixes with a mask length smaller than 24. For example, the
maps to the DNS name 0/18.82.129.in-addr.arpa, and 129.82.0.0/20 maps [RFC2317] style name for prefix 129.82.0.0/16 maps to the DNS name
to the DNS name 0/20.82.129.in-addr.arpa. This mapping improves on 0/16.0.82.129.in-addr.arpa. It also maps to the names
the previous [RFC1101] approach in that each prefix now has a unique 0/16.82.129.in-addr.arpa, 82/16.129.in-addr.arpa, and 82.129.in-
name, but we show the approach has several other critical flaws. addr.arpa. [RFC2317] does not defines which of these is correct.
This is not a flaw in the RFC. Instead, [RFC2317] says it is
designed for "address spaces covering fewer than 256 addresses".
129.82.0.0/16 covers over 65,000 addresses, is clearly out scope, and
thus a name for this prefix is not specified.
For those who feel a slightly different assumption should be used To extend this to a general naming convention, let 129.82.0.0/16 map
when extending [RFC2317], we first note this illustrates the danger to the DNS name 82.129.in-addr.arpa, 129.82.0.0/18 map to the DNS
of relying on a "common understanding" rather than a written name 0/18.82.129.in-addr.arpa, and 129.82.0.0/20 map to the DNS name
document. But more fundamentally, we claim all the various different 0/20.82.129.in-addr.arpa. This mapping improves on the previous
[RFC2317] extensions have the same critical flaws discussed below. [RFC1101] approach in that each prefix now has a unique name, but we
show the approach has several other critical flaws.
One limitation is that the scheme is flat rather than hierarchical. One limitation is that the scheme is flat rather than hierarchical.
In the prefix hierarchy, 129.82.0.0/18 is descendant of In the prefix hierarchy, 129.82.0.0/18 is descendant of
129.82.0.0/16. In the DNS tree, the name 0/18.82.129.in-addr.arpa is 129.82.0.0/16. In the DNS tree, the name 0/18.82.129.in-addr.arpa is
a descendant of 82.129.in-addr.arpa. This is the desired property, a descendant of 82.129.in-addr.arpa. This is the desired property,
but is only preserved at the octet boundary. but is only preserved at the octet boundary.
In the prefix hierarchy, 129.82.0.0/20 is descendant of In the prefix hierarchy, 129.82.0.0/20 is descendant of
129.82.0.0/18. In the DNS tree, the name 0/18.82.129.in-addr.arpa 129.82.0.0/18. In the DNS tree, the name 0/18.82.129.in-addr.arpa
and 0/20.82.129.in-addr.arpa are siblings, both are direct and 0/20.82.129.in-addr.arpa are siblings, both are direct
descendants of 82.129.in-addr.arpa. The hierarchical prefix descendants of 82.129.in-addr.arpa. The hierarchical prefix
structure is not preserved and mapped into a single flat space. structure is not preserved and mapped into a single flat space.
Worse still, all /17, /18, /19, /20, /21, /22, and /23 prefixes are Worse still, all /17, /18, /19, /20, /21, /22, and /23 prefixes are
siblings. There is no hierarchical relationship whatsoever for siblings. There is no hierarchical relationship whatsoever for
prefixes that don't fall on an octet boundary. prefixes that don't fall on an octet boundary, violating the Coverage
Authority and Delegation requirements.
This document proposes naming convention that adds as much hierarchy This document proposes a naming convention that adds as much
as possible, while still preserving the existing reverse DNS tree hierarchy as possible, while still preserving the existing reverse
structure. In our approach, the name for 129.82.0.0/20 is a DNS tree structure. In our approach, the name for 129.82.0.0/20 is a
descendant of the name for 129.82.0.0/18. descendant of the name for 129.82.0.0/18.
Overall, [RFC2317] was not intended to encode IPv4 prefixes with a Overall, [RFC2317] was not intended to encode IPv4 prefixes with a
mask length smaller than 24 and it does not consider IPv6. The mask length smaller than 24 and it does not consider IPv6. Because
"common understanding" on how to extend it results in a flat the namespace is flat, it fails to meet the design requirements of
namespace. Because the namespace is flat, it fails to meet the Coverage Authority, Allowing Delegation, and arguably Simplicity.
design requirements of Coverage Authority, Allowing Delegation, and
arguably Simplicity.
5.3. Prior Work on CIDR Names for Routing 5.3. Prior Work on CIDR Names for Routing
Over a decade ago, [I-D.bates-bgp4-nlri-orig-verif] proposed to use Over a decade ago, [I-D.bates-bgp4-nlri-orig-verif] proposed to use
the reverse DNS to verify the origin AS associated with a prefix. the reverse DNS to verify the origin AS associated with a prefix.
This requires both a naming convention for converting the name into a This requires both a naming convention for converting the name into a
prefix and additional resource record types for storing origin prefix and additional resource record types for storing origin
information, along with recommendations on their use. information, along with recommendations on their use.
Our focus in this draft is on the naming convention. Draft Our focus in this draft is on the naming convention. Draft
skipping to change at page 16, line 31 skipping to change at page 16, line 31
Suppose organization X has been allocated 10.10.0.0/16 by SomeRIR. Suppose organization X has been allocated 10.10.0.0/16 by SomeRIR.
Organization X assigns 10.10.0/17 to Organization Y and assigned Organization X assigns 10.10.0/17 to Organization Y and assigned
10.10.128/17 to Organization Z. Concerns have been raised that 10.10.128/17 to Organization Z. Concerns have been raised that
Organization X needs to create 256 delegations. More precisely, Organization X needs to create 256 delegations. More precisely,
Organization X needs to delegate 0.10.10.in-addr.arpa, 1.10.10.in- Organization X needs to delegate 0.10.10.in-addr.arpa, 1.10.10.in-
addr.arpa, up to 127.10.10.in-addr.arpa to Organization Y. Similarly, addr.arpa, up to 127.10.10.in-addr.arpa to Organization Y. Similarly,
128.10.10.in-addr.arpa up to 255.10.10.in-addr.arpa need to be 128.10.10.in-addr.arpa up to 255.10.10.in-addr.arpa need to be
delegated to Organization Z. This is the current practice and the delegated to Organization Z. This is the current practice and the
naming convention here does not change this. naming convention here does not change this.
If the naming convention in this document is adopted, no changes in The naming convention described in this document requires no changes
the existing delegation operations are introduced. The naming to the existing delegation operations. The naming convention does
convention does add one additional delegation, 0.m.10.10.in- add one additional delegation, 0.m.10.10.in-addr.arpa, to
addr.arpa, to Organization Y. Similarly, the naming convention does Organization Y. Similarly, the naming convention does add one
add one additional delegation, 1.m.10.10.in-addr.arpa, to additional delegation, 1.m.10.10.in-addr.arpa, to Organization Z.
Organization Z.
Some have suggested the new /17 zones could be used to change the
existing operational practice. However, to the best of knowledge, no
zone operator has openly stated a desire to change this operational
practice.
6.2. Allocating a /16 and then assigning the /16 6.2. Allocating a /16 and then assigning the /16
Suppose organization X has been allocated 10.10.0.0/16 by SomeRIR. Suppose organization X has been allocated 10.10.0.0/16 by SomeRIR.
Organization X assigns 10.10.0/16 to Organization Y. Concerns have Organization X assigns 10.10.0/16 to Organization Y. SomeRIR needs to
been raised that SomeRIR needs to update the delegation (NS and DS update the delegation (NS and DS records) in the 10.in-addr.arpa zone
records) in the 10.in-addr.arpa zone to point to Organization Y. The to point to Organization Y. Again, this is the current practice and
concern is that SomeRIR has no business relationship with the naming convention here does not change this.
Organization Y. Again, this is the current practice and the naming
convention here does not change this.
One particular concern is that a DNSSEC authentication chain from
10.in-addr.arpa to 10.10.in-addr.arpa goes from a DS record stored at
SomeRIR to a DNSKEY generated at Organization Y. This chain does not
include Organization X. Again, this is the current practice and the
naming convention does not change this.
6.3. Delegations that Span Octet boundaries 6.3. Delegations that Span Octet boundaries
Suppose organization X has been allocated 10.0.0.0/10 by SomeRIR. Suppose organization X has been allocated 10.0.0.0/10 by SomeRIR.
Organization X assigns 10.0.128/17 to Organization Y. SomeRIR Organization X assigns 10.0.128/17 to Organization Y. SomeRIR
allocates 10.0/10 to Organization X, SomeRIR should also delegate the allocates 10.0/10 to Organization X, SomeRIR should also delegate the
64 zones 0.10.in-addr.arpa, 1.10.in-addr.arpa, ... 63.10.in-addr.arpa 64 zones 0.10.in-addr.arpa, 1.10.in-addr.arpa, ... 63.10.in-addr.arpa
to Organization X. Organization Y should be delegated the 128 zones to Organization X. Organization Y should be delegated the 128 zones
from 128.0.10.in-addr.arpa to 255.0.10.in-addr.arpa. Note all these from 128.0.10.in-addr.arpa to 255.0.10.in-addr.arpa. Note all these
delegations come from the 0.10.in-addr.arpa zone, so SomeRIR is not delegations come from the 0.10.in-addr.arpa zone, so SomeRIR is not
involved in the delegation. Again, this is the current practice and involved in the delegation. Again, this is the current practice and
the naming convention here does not change this. the naming convention here does not change this.
If the naming convention in this document is adopted, SomeRIR should SomeRIR should also delegate the 0.0.m.10.in-addr.arpa namespace to
also delegate the 0.0.m.10.in-addr.arpa namespace to Organization X. Organization X. Similarly, Organization X should also delegate the
Similarly, Organization X should also delegate the namespace namespace 1.m.0.10.in-addr.arpa to Organization Y. Note this
128.m.0.10.in-addr.arpa to Organization Y. Note this delegation comes delegation comes from the 0.10.in-addr.arpa zone run by Organization
from the 0.10.in-addr.arpa zone run by Organization X and SomeRIR is X and SomeRIR is not involved in the delegation.
not involved in the delegation.
The concern raised is the addition of the new naming convention did
not obsolete the need to add to delegate the various octet boundary
zones. In other words, one still needs to continue the practice of
delegating zones like 0.10.in-addr.arpa and 128.0.10.in-addr.zones.
Wouldn't it be better if one could simply delegate the single 10.0/10
(or 10.0.128/17) and that would take care of the entire space?
While that may initially appear to be a valid goal, it actually
creates a new reverse DNS tree. Our objective is to work within the
confines of the existing reverse DNS tree, not define a new tree.
The zones such as 0.10.in-addr.arpa exist in the current tree. We
assume they will continue to exist and thus they still need to be
delegated as they were before.
Some other alternative naming convention could propose a completely The addition of the new naming convention did not obsolete the need
new reverse DNS tree and thus could avoid this. But such an approach to add to delegate the various octet boundary zones. In other words,
would face the problem of backwards compatibility with the existing one still needs to continue the practice of delegating zones like
reverse DNS. One might (unrealistically) propose the current reverse 0.10.in-addr.arpa and 128.0.10.in-addr.zones. This draft
DNS tree be discontinued at some point. We don't believe a flag day intentionally works with the existing reverse DNS tree and does not
for ending current reverse DNS is plausible and we also don't believe change the practices for existing octet boundary zones.
reverse DNS would simply cease to exist without a flag day. Further,
we don't believe this is desirable as current operations are in
place, operators successful manage current reverse DNS, and it
currently provides useful services. This means the existing reverse
DNS tree and some theoretical new tree would need to co-exist,
overlapping at some places, complicating resolver paths, and provide
multiple locations for the same data. This draft instead proposes
working with the existing reverse DNS tree.
6.4. Legacy Behavior at Octet Boundaries 6.4. Legacy Behavior at Octet Boundaries
The existing reverse DNS structure is aligned on octet boundaries for The existing reverse DNS structure is aligned on octet boundaries for
IPv4 and nibble boundaries for IPv6. The naming convention IPv4 and nibble boundaries for IPv6. The naming convention
introduced here adds to the existing reverse DNS tree; it does not introduced here adds to the existing reverse DNS tree; it does not
change the existing structure. This is a deliberate choice not to change the existing structure. This is a deliberate choice not to
reinvent the reverse DNS but rather to enhance the existing reinvent the reverse DNS but rather to enhance the existing
structure. The naming convention proposed here builds on the structure. The naming convention proposed here builds on the
existing reverse DNS structure and thus inherits both advantages and existing reverse DNS structure and thus inherits both advantages and
disadvantages from the existing system. disadvantages from the existing system.
One disadvantage is the existing octet boundary based tree for IPv4
(and nibble based tree for IPv6). To understand why this is a
disadvantage, suppose organization A owns the address space
129.82.0.0/16. Organization A allocates the address space
129.82.128.0/17 to Organization B. In typical operations,
Organization A would delegate 128 zones to Organization B; the zones
128.82.129.in-addr.arpa, 129.82.129.in-addr.arpa, ..., 255.82.129.in-
addr.arpa. Because the reverse DNS had no notion of CIDR prefixes,
all 128 delegations are need to give organization B full control over
its PTR records.
The example becomes worse if Organization B further suballocates
129.82.128/22 to Organization C. In this case, Organization C needs
to be given operational control of 4 zones; 128.82.129.in-addr.arpa,
129.82.129.in-addr.arpa. 130.82.129.in-addr.arpa, and 131.82.129.in-
addr.arpa. Delegating these zones to organization C requires an
action by the owner of 82.129.in-addr.arpa. Note that Organization C
does not have a business relationship with Organization A.
Organization C needs to pass information to Organization B who in
turn needs to pass the information to Organization A.
The above operation is not ideal. Delegating a non-octet boundary
prefix requires the delegation of multiple zones. Subdelegation can
require communication with organizations that do not have direct
business relationships. But it is essential to note that this is how
the reverse DNS currently operates and has successfully operated for
many years. Operational techniques have been developed to manage PTR
records and their respective zones. For better or worse, these
practices continue to work with this naming convention.
The naming convention here does introduce additional names for
prefixes. In the example above, Organization A could delegate the
1.m.82.129.in-addr.arpa to Organization B. Organization B could in
turn delegate 0.0.0.0.0.1.m.82.129.in-addr.arpa to Organization C.
Note the naming convention has allowed delegation of prefixes to work
in an efficient manner that respects business relationships. For
example, Organization B can delegate the prefix 129.82.128/22 to
Organization C without ever involving Organization A. Had this naming
convention been in place for the original reverse DNS, much of the
suboptimal behavior discussed above could have been avoided.
However, the naming convention explicitly chooses to enhance the
existing reverse DNS tree rather than replace.
6.5. The Naming Convention and Zone Structures 6.5. The Naming Convention and Zone Structures
The naming convention does not impose any semantics on zone The naming convention does not impose any semantics on zone
structure. As with any DNS name, a resolver need not be aware of how structure. As with any DNS name, a resolver need not be aware of how
the zone cuts are structured and no specific requirements are added the zone cuts are structured and no specific requirements are added
for zone management. For example, some sites may choose to delegate for zone management. For example, some sites may choose to delegate
at a subprefix boundary while others maintain one large zone. Names at a subprefix boundary while others maintain one large zone. Names
can make use of CNAME and DNAME records if the zone administrator so can make use of CNAME and DNAME records if the zone administrator so
desires. This is simply a naming convention and does not change any desires. This is simply a naming convention and does not change any
existing resolver or server behavior. existing resolver or server behavior.
skipping to change at page 19, line 50 skipping to change at page 18, line 19
addr.arpa. This zone can simply be delegated to the group managing addr.arpa. This zone can simply be delegated to the group managing
prefix related data while the group managing PTR records continues to prefix related data while the group managing PTR records continues to
be responsible for the zones 128.82.129.in-addr.arpa to be responsible for the zones 128.82.129.in-addr.arpa to
255.82.129.in-addr.arpa. 255.82.129.in-addr.arpa.
If prefix data is also to be stored at mask lengths ranging between If prefix data is also to be stored at mask lengths ranging between
24 and 32, then m.128.82.129.in-addr.arpa to m.255.82.129.in- 24 and 32, then m.128.82.129.in-addr.arpa to m.255.82.129.in-
addr.arpa can also be delegated to the group managing prefix data. addr.arpa can also be delegated to the group managing prefix data.
In this sense, an organization can keep a complete separation between In this sense, an organization can keep a complete separation between
groups managing prefix data and groups managing PTR records for host groups managing prefix data and groups managing PTR records for host
names. The use of PTR records to specify a network name (per names.
[RFC1101]) could be maintained by either group.
During the discussion of the draft, some organizations expressed a During the discussion of the draft, some organizations expressed a
desire to achieve this type of separation in operational practice. desire to achieve this type of separation in operational practice.
In particular, groups associated with routing and prefix management In particular, groups associated with routing and prefix management
might manage the prefix related records while other groups associated might manage the prefix related records while other groups associated
with DHCP and IP address management currently manage the PTR records. with DHCP and IP address management currently manage the PTR records.
This example simply illustrates these groups can be kept distinct if This example simply illustrates these groups can be kept distinct if
an organization so desires. As with any DNS deployment, an an organization so desires. As with any DNS deployment, an
organization makes its own decisions on where to make zone cuts and organization makes its own decisions on where to make zone cuts and
how to manage their own delegation. how to manage their own delegation.
skipping to change at page 20, line 34 skipping to change at page 18, line 50
An application can easily lookup the LOC resource record associated An application can easily lookup the LOC resource record associated
with a prefix using this naming convention. The application simply with a prefix using this naming convention. The application simply
converts the prefix (IPv4 or IPv6) into a DNS name as described in converts the prefix (IPv4 or IPv6) into a DNS name as described in
the previous sections and queries for the LOC record associated with the previous sections and queries for the LOC record associated with
that name. Using DNSSEC, an application can also authenticate the that name. Using DNSSEC, an application can also authenticate the
LOC record or provide authenticated denial of existence proving that LOC record or provide authenticated denial of existence proving that
no such LOC record exists. no such LOC record exists.
A distinct question is how one might enumerate all possible prefixes A distinct question is how one might enumerate all possible prefixes
that have LOC records. The naming convention does not directly that have LOC records. Techniques to provide enumeration of prefixes
provide enumeration. Applications might develop strategies for in the DNS are outside the scope of this document.
searching all possible names by variations of brute force searches,
exploiting NSEC records (if used), or by adding additional record
types to aid in finding related prefixes. The naming convention
proposed here does not provide an explicit mechanism to enumerate all
prefixes with a particular resource record type.
6.8. Finding Longest Matches 6.8. Finding Longest Matches
Another distinct question is how one could find the longest match for Another distinct question is how one could find the longest match for
a given IP address or prefix. For example, the application might a given IP address or prefix. For example, the application might
want to find the most specific prefix (longest match) that has a LOC want to find the most specific prefix (longest match) that has a LOC
record and covers a particular IP address. Similar to enumeration, record and covers a particular IP address. Similar to enumeration,
the naming convention does not directly provide longest match. the naming convention does not directly provide longest match.
Applications might develop strategies for searching all covering Applications might develop strategies for searching all covering
prefixes using variations of brute force searches, exploiting NSEC prefixes using variations of brute force searches, exploiting NSEC
skipping to change at page 24, line 11 skipping to change at page 22, line 11
8. IANA Considerations 8. IANA Considerations
This document does not request any IANA action. This document does not request any IANA action.
9. Acknowledgments 9. Acknowledgments
The authors would like to thank Danny McPherson (Verisign), Lixia The authors would like to thank Danny McPherson (Verisign), Lixia
Zhang (UCLA), and Kim Claffy (CAIDA) for their comments and Zhang (UCLA), and Kim Claffy (CAIDA) for their comments and
suggestions. This document was aided via numerous discussions at suggestions. This document was aided via numerous discussions at
NANOG, IETF and private meetings with ISPs, telecomm carriers, and NANOG, IETF and private meetings with ISPs, telecomm carriers, and
research organizations too numerous to mention by name. Thanks to research organizations too numerous to mention by name. Finally, the
all for your comments and advice. naming convention has been in use by some organizations for over a
year at the time of this draft. Thanks to all for your comments and
advice.
10. Change History 10. Change History
Changes from version 03 to 04
No changes were made to the naming convention, requirements, or
document scope.
Minor changes to fix two typos and also to improve grammar
throughout.
Clarified the description of Related Work based on feedback
received.
Simplified the Additional Considerations based on feedback
received.
No changes in the convention itself were added or removed.
Changes from version 02 to 03 Changes from version 02 to 03
Added detail regarding [RFC1101] and how it historically defined a Added detail regarding [RFC1101] and how it historically defined a
method to name subnets; explained how CIDR introduced ambiguities method to name subnets; explained how CIDR introduced ambiguities
into [RFC1101] creating the need for a more comprehensive naming into [RFC1101] creating the need for a more comprehensive naming
convention. convention.
Added similar explanatory material for [RFC2317]. Added similar explanatory material for [RFC2317].
Added "unambiguous" as a design objective. Added "unambiguous" as a design objective.
skipping to change at page 31, line 15 skipping to change at page 29, line 15
Authors' Addresses Authors' Addresses
Joe Gersch Joe Gersch
Secure64 SW Corp Secure64 SW Corp
Fort Collins, CO Fort Collins, CO
US US
Email: joe.gersch@secure64.com Email: joe.gersch@secure64.com
Dan Massey Dan Massey
Maka'ala Networks Colorado State University
Longmont, CO Fort Collins, CO
US US
Email: dan@makaalanetworks.com Email: massey@cs.colostate.edu
Eric Osterweil Eric Osterweil
Verisign Verisign
Reston, VA Reston, VA
US US
Email: eosterweil@verisign.com Email: eosterweil@verisign.com
Cathie Olschanowsky Cathie Olschanowsky
Colorado State University Colorado State University
 End of changes. 27 change blocks. 
184 lines changed or deleted 103 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/