Reverse DNS Naming Convention for CIDR Address Blocks
draft-gersch-dnsop-revdns-cidr-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Joe Gersch , Dan Massey , Eric Osterweil | ||
| Last updated | 2012-02-28 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-gersch-dnsop-revdns-cidr-01
Network Working Group J. Gersch
Internet-Draft Secure64 SW Corp
Intended status: Informational D. Massey
Expires: September 1, 2012 Colorado State University
E. Osterweil
Verisign
February 29, 2012
Reverse DNS Naming Convention for CIDR Address Blocks
draft-gersch-dnsop-revdns-cidr-01.txt
Abstract
The current reverse DNS naming method is used to specify a complete
IP address. There currently is no standard way for it to handle
address ranges; for example, there is no formal mechanism for
specifying a reverse DNS name for the block of addresses specified by
the IPv4 prefix 129.82.0.0/16. Defining such a reverse DNS naming
convention would be useful for a number of applications. These
include applications for secure BGP routing, and applications that
need host-information for a device owning a complete IPv6 address
block. This draft proposes a naming convention for encoding CIDR
address blocks in the reverse DNS.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 1, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Gersch, et al. Expires September 1, 2012 [Page 1]
Internet-Draft Reverse DNS CIDR February 2012
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Aligning the DNS and IP Hierarchies . . . . . . . . . . . 3
1.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used In This Document . . . . . . . . . . . . . . 6
3. Design Requirements . . . . . . . . . . . . . . . . . . . . . 7
4. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. CIDR Naming via RFC 2317 . . . . . . . . . . . . . . . . . 8
4.2. Prior Work on CIDR Names for Routing . . . . . . . . . . . 9
5. Reverse DNS CIDR Name Specification . . . . . . . . . . . . . 10
5.1. IPv4 Address Block Naming . . . . . . . . . . . . . . . . 10
5.2. IPv6 Address Block Naming . . . . . . . . . . . . . . . . 12
5.3. An Alternative Encoding For Names at Octet Boundaries . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Example Zone Files . . . . . . . . . . . . . . . . . 19
A.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 19
A.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Gersch, et al. Expires September 1, 2012 [Page 2]
Internet-Draft Reverse DNS CIDR February 2012
1. Introduction
This draft proposes a common naming convention for entering CIDR
prefixes into the Reverse DNS.
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
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
encoded as 2.138.82.129.in-addr.arpa and a PTR resource record
identifies the host name as alpha.netsec.colostate.edu. The Reverse
DNS would be more expressive if we had a formal convention for
encoding and returning information associated with a network address
range, not just a unique IP address. For example, one would like to
store and resolve resource records associated with a prefix range
such as 129.82.128/17.
Given such a capability, a variety of new applications and services
would be enabled. For example, internet routing operators could
publish authorized BGP route origins for their network address blocks
in the reverse-DNS as proposed in [I-D.gersch-grow-revdns-bgp].
Another application could query for a set of host-names or services
associated with an address block; for example, to indicate the
authorized mail servers for an address block.
Yet another interesting possibility is to solve a problem with IPv6
dynamic DNS assignments. In IPv4, the owner of address block could
simply include one PTR record for every available address. In fact,
ISPs commonly pre-populate the reverse DNS zone for their customers.
However, this approach clearly does not scale for IPv6 where the
number of addresses becomes excessively large. For example,
allocation of a /48 (not uncommon in IPv6) includes 2^80 addresses
and notes adding 1000 PTR records per second would require over 38
trillion years to pre-populate the reverse DNS
[I-D.howard-isp-ip6rdns]. The ability to name prefix blocks rather
than individual addresses could help address this problem by
publishing records associated with an entire IPv6 address range
instead of replicating or synthesizing answers to unique address
queries.
The above list of possible applications is not intended to be
complete, but instead suggest some of the possibilities.
1.1. Aligning the DNS and IP Hierarchies
A key observation is that both the DNS names and IP addresses are
part of a hierarchical tree structure and any naming convention
should respect and align these tree structures.
Gersch, et al. Expires September 1, 2012 [Page 3]
Internet-Draft Reverse DNS CIDR February 2012
In the DNS hierarchical tree structure 128.82.129.in-addr.apra is
logically below 82.129.in-addr.apra, which is logically below 129.in-
addr.arpa. Other "flat" approaches to naming, such as Distributed
Hash Tables, have been proposed, but the DNS tree structure remains a
powerful abstraction. It forms the basis for the operation of DNS;
caching, delegation, DNSSEC signing, and so forth all benefit from
the DNS tree structure.
IP addresses also have a logical tree structure where 129.82.128.0/24
is subprefix (logically below) 129.82.0.0/16 which is a subprefix of
129.0.0.0/8. The reverse DNS aligns with the structure;
128.82.129.in-addr.arpa is logically below 82.129.in-addr.arpa which
is logically below 129.in-addr.arpa. This alignment between the DNS
hierarchy and the IP address hierarchy serves both systems well and
allows one to easily encode prefixes that fall on an octet boundary
(e.g. IPv4 prefixes whose mask length is a multiple of 8).
The challenge is to preserve this alignment even when even when CIDR
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 should be logically below the DNS name for
129.82.128.0/18. This document introduces a naming convention for
CIDR prefixes that restores this alignment.
1.2. Purpose
In order to enable these applications, one must map an IPv4 or IPv6
prefix into a reverse-DNS name. There are various subtleties,
advantages and disadvantages that emerge when trying to define a
naming convention. Today, zone administrators can use their own
individual approaches to encode a prefix in the reverse DNS. This
requires no DNS protocol changes and no modifications to resolvers,
caches, or authoritative servers. The emergence of different
encoding standards complicates (but does not prevent) the design of
systems that would make use of these resource records. The aim of
this work is to introduce a standard convention.
1.3. Terminology
The following terms are used throughout out the document:
Reverse DNS:
We use the term Reverse DNS to refer to the domains in-addr.arpa
and ip6.arpa.
Gersch, et al. Expires September 1, 2012 [Page 4]
Internet-Draft Reverse DNS CIDR February 2012
Prefix:
A prefix refers to IPv4 or IPv6 address range specified by a
network portion and mask length, as described in [RFC4632]. For
example, 129.82.0.0/16 and 129.82.128/18 are examples of IPv4
prefixes.
Octet Boundary:
An IPv4 prefix falls on an octet boundary if its mask length is a
multiple 8. For example, 129.82.0.0/16 is on an octet boundary
while 129.82.128/18 does not fall on octet boundary. Prefixes
that are on octet boundary naturally map to the reverse DNS.
Prefixes that are not on octet boundary are more complex and the
main challenge for any naming convention.
Gersch, et al. Expires September 1, 2012 [Page 5]
Internet-Draft Reverse DNS CIDR February 2012
2. Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Gersch, et al. Expires September 1, 2012 [Page 6]
Internet-Draft Reverse DNS CIDR February 2012
3. Design Requirements
A naming convention to specify CIDR address blocks in the reverse-DNS
has several design goals:
1. Autonomy: The owner of a reverse-DNS zone file associated with a
CIDR address block must be able to act independently from any
other organization in order to create or modify data records
within the DNS zone.
2. Coverage Authority: With the exception of data that has been sub-
delegated to a child zone, the reverse DNS zone must be
authoritative for all sub-prefixes below the covering prefix.
Any query for a sub-prefix must be answered with a data record or
NXDOMAIN specifying this zone as the authority.
3. Allow Delegation: It must allow the zone owner to delegate
smaller address blocks to a child zone which will be
independently managed.
4. Conformance: It should align with naming conventions and
delegation structures already in use by the RIR's for IN-
ADDR.ARPA and IP6.ARPA.
5. Simplicity: The naming structure should be understandable, or at
a minimum, able to be easily constructed by software provisioning
tools and utilities such as DIG.
Gersch, et al. Expires September 1, 2012 [Page 7]
Internet-Draft Reverse DNS CIDR February 2012
4. Related Work
The process of mapping CIDR addresses into the reverse-DNS name space
is difficult because the prefix length of an IPv4 CIDR address is an
arbitrary number from 0 to 32. These numbers do not necessarily
align with an IPv4 octet.
4.1. CIDR Naming via RFC 2317
Since CIDR address no longer align with octet boundaries, the CIDR
specification in [RFC4632] notes that there is "some increase in work
for those who maintain parts of the IN-ADDR.ARPA zone." [RFC2317] is
offered as a technique to populate IN-ADDR.ARPA. The intent of this
work is to encode IPv4 addresses and the approach is designed to
"address spaces covering fewer than 256 addresses."
Suppose organization A owns 129.82.138.0/30. This address space
covers four IPv4 addresses; namely 129.82.138.0, 129.82.138.1,
129.82.138.2 and 129.82.138.3. Giving organization A control of the
reverse zone "138.82.129.in-addr.arpa." would allow Organization A to
enter PTR resource records for each of its 4 addresses. However, it
also gives organization A the ability to enter PTR resource records
for 252 other IP addresses from 129.82.138.4 to 129.82.138.255.
These addresses are managed by other organizations. Sharing the
138.82.129.in-addr.arpa between multiple organization is not
practical and creating a seperate zone for each IP address (e.g.
creating the zone 0.138.82.129.in-addr.arpa) is very high overhead to
store a single PTR record.
[RFC2317] addresses this problem by creating CNAME records in
138.82.129.in-addr.arpa zone. Organization A administers a zone
named 0/32.138.129.in-addr.arpa. CNAME records in the 138.82.129.in-
addr.arpa zone point to entries in Organization A's
0/32.138.82.129.in-addr.arpa zone. For example, 1.138.82.129.in-
addr.arpa. is a CNAME pointing to 1.0/32.138.82.129.in-addr.arpa. A
full description is found in [RFC2317].
This approach was not intended to encode IP address for address
spaces smaller than a "/24". It was not intended for encoding
prefixes. It does not specify how one might encode a prefix and it
is not trivial to extend this approach to CIDR prefixes. In
particular, the design requirements of Coverage Authority, Allowing
Delegation, and arguably Simplicity are not easily met by extending
the RFC to included prefixes.
Gersch, et al. Expires September 1, 2012 [Page 8]
Internet-Draft Reverse DNS CIDR February 2012
4.2. Prior Work on CIDR Names for Routing
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.
This requires both a naming convention for converting the name into a
prefix and additional resource record types for storing origin
information, along with recommendations on their use.
Our focus in this draft is on the naming convention. Draft
[I-D.bates-bgp4-nlri-orig-verif] as well as other subsequent work on
BGP security, extends [RFC2317] style names to encode a prefix. For
example, the draft proposes to encode the prefix 10.1.128/20 as the
DNS name 128/20.1.10.bgp.in-addr.arpa.
In [I-D.bates-bgp4-nlri-orig-verif], the DNS hierarchy and the IP
address hierarchy diverge and the approach fails to meet the Coverage
Authority requirement. To see this, consider the prefixes
10.1.128/20 and 10.1.128/21. in CIDR terminology, 10.1.128/21 is
covered by 10.1.128/20, but this relationship is not captured in the
DNS hierarchy. 10.1.128/21 is encoded as 128/21.1.10.bgp.in-addr.arpa
and thus 10.1.128/20 and 10.1.128/21 are siblings in the DNS tree
structure.
This can be overcome by introducing a large number of CNAME records;
one for every potential subprefix. We instead provide an approach
where the CIDR hierarchy and DNS hierarchy align.
Gersch, et al. Expires September 1, 2012 [Page 9]
Internet-Draft Reverse DNS CIDR February 2012
5. Reverse DNS CIDR Name Specification
The naming method described in this section is based on the well-
known technique of ANDing a bit-mask with the low-order octet of an
IP address. The binary result is then broken up into individual sub-
names using the "." separator. The result looks like an ENUM or IPv6
reverse-DNS address; that is, a string of chained empty non-terminal
sub-names.
This name-chaining creates the desired effect of being able to allow
a DNS zone delegation at any point in the chain. The naming scheme
allows the creation of two /17's from a /16, two /18's from a /17,
and so on.
5.1. IPv4 Address Block Naming
The CIDR to Reverse-DNS naming convention works as follows:
1. Remove any octets that are not significant. An octet is
signficant if it includes any part of the network address. An
octet is not significant if all bits correspond to the host
portion of the address. For example, 129.82.0.0/16 --> 129.82
and 129.82.160.0/19 --> 129.82.160
2. Calculate N where N = prefix_length mod 8. If N equals 0, invert
the address and add in-addr.arpa, per the usual reverse-DNS
method; 129.82 --> 82.129.in-addr.arpa.
3. If N is not equal 0, the prefix is not on an octet boundary and
we perform the following name construction:
A. Truncate the name to remove the least significant octet. Add
a "m" label to this domain name to indicate "mask".
B. Convert the least significant octet to binary, separating
each bit into its own label (with a "." character).
C. Truncate the binary labels to the N significant labels that
correspond to the given prefix_length.
D. Reverse the string and add ".in-addr.arpa."
Several examples illustrate this algorithm. These examples show the
conversion to binary, followed by the truncation, followed by the
name reversal.
129.82.0.0/16 --> 82.129.in-addr.arpa. (at octet boundary)
Gersch, et al. Expires September 1, 2012 [Page 10]
Internet-Draft Reverse DNS CIDR February 2012
129.82.64.0/18 --> 129.82.m.0.1.0.0.0.0.0.0
--> 129.82.m.0.1 (N = 18 mod 8 = 2)
--> 1.0.m.82.129.in-addr.arpa.
129.82.64.0/20 --> 129.82.m.0.1.0.0.0.0.0.0
--> 129.82.m.0.1.0.0 (N = 20 mod 8 = 4)
--> 0.0.1.0.m.82.129.in-addr.arpa.
129.82.160.0/20 --> 129.82.m.1.0.1.0.0.0.0.0
--> 129.82.m.1.0.1.0 (N = 20 mod 8 = 4)
--> 0.1.0.1.m.82.129.in-addr.arpa.
129.82.160.0/23 --> 129.82.m.1.0.1.0.0.0.0.0
--> 129.82.m.1.0.1.0.0.0.0 (N = 23 mod 8 = 7)
--> 0.0.0.0.1.0.1.m.82.129.in-addr.arpa.
15.192.0.0/12 --> 15.192.m.1.1.0.0.0.0.0.0
--> 15.192.m.1.1.0.0 (N = 12 mod 8 = 4)
--> 0.0.1.1.m.15.in-addr.arpa.
The conversion from a reverse-DNS name back to CIDR is simple. First
calculate the prefix length from the name using the formula:
plen = 8*(count of full octets) + (count of binary digits)
Then reverse the string, add up the values of the binary digits to
build a final octet, then append a "/" and the prefix length.
Examples:
1.0.m.82.129.in-addr.arpa --> 129.82.64.0/18
(example has 2 octets + 2 binary digits, so mask length = 18)
0.0.1.0.m.82.129.in-addr.arpa --> 129.82.64.0/20
(example has 2 octets + 4 binary digits, so mask length = 20)
0.0.0.1.0.1.m.129.in-addr.arpa--> 129.160.0/14
(example has 1 octet + 6 binary digits, so mask length = 14)
Gersch, et al. Expires September 1, 2012 [Page 11]
Internet-Draft Reverse DNS CIDR February 2012
5.2. IPv6 Address Block Naming
The IPv6 naming convention is similar, with the exception that 4-bit
nibble boundaries are used instead of octets, the mod calculation is
based on 4 instead of 8, and "ip6.arpa" is used as the suffix.
Examples:
2607:fa88::/32 --> 8.8.a.f.7.0.6.2.ip6.arpa
(on nibble boundary)
2607:fa88:8000::/33 --> 2.6.0.7.f.a.8.8.m.1.0.0.0
--> 2.6.0.7.d.a.8.8.m.1 (33 mod 4 = 1)
--> 1.m.8.8.a.f.7.0.6.2.ip6.arpa
2607:fa88:e000::/35 --> 2.6.0.7.f.a.8.8.m.1.1.1.0
--> 2.6.0.7.d.a.8.8.m.1.1.1(35 mod 4 = 3)
--> 1.1.1.m.8.8.a.f.7.0.6.2.ip6.arpa
5.3. An Alternative Encoding For Names at Octet Boundaries
If a prefix is on an octet boundary, the algorithm stops at step 2.
However by applying Step 3 of the algorithm, one could also obtain an
alternate encoding for the same prefix For example, applying the
algorithm produces the standard encoding 129.82.1.0/24 -->
1.82.129.in-addr.arpa. If one applies step 3 of the algorithm, one
gets the alternate encoding 129.82.1.0/24 -->
1.0.0.0.0.0.0.0.m.82.129.in-addr.arpa.
Deployment experience has shown that the alternate encoding can be
very useful in some circumstances. To see this, consider the case
where an organization owns the prefix 129.82.0.0/16. The
organization's central IT office administers the 82.129.in-addr.arpa
zone. The central IT office has delegated 1.82.129.in-addr.arpa to a
remote division. The remote division is capable of managing PTR
records within this zone, but lacks the technical expertise to manage
records associated with the prefix 129.82.1.0/24. For example, the
remote division should not be authorizing mail servers, announcing
BGP routes, or other prefix related tasks.
Unfortunately for the central IT office, it is sometimes useful to
store information at the 129.82.1.0/24 prefix. For example, the
central IT office may want to add a record listing the authorized
mail servers for this prefix or indicate the prefix cannot announce
BGP routes. The problem is that these records would be stored at the
name 1.82.129.in-addr.arpa, which is managed by the remote
Gersch, et al. Expires September 1, 2012 [Page 12]
Internet-Draft Reverse DNS CIDR February 2012
subdivision. Rather than ask the remote division to enter these
resource records, the central IT office would like to handle this
taks for the remote division.
By exploiting the alternate encoding, the central IT office can store
and manage records at the name 1.0.0.0.0.0.0.0.m.82.129.in-addr.arpa.
The key distinction is that this alternate encoding of the name is
part of the 82.129.in-addr.arpa zone. This allows the central IT
organization to administer resource records on behalf of the remote
division and greatly simplifies some operations.
The following rules apply to the alternate encoding:
An application MUST first try the standard encoding of the name.
If the requested resource record type is not found at the standard
encoding of the name and the prefix is at an octet boundary, an
application SHOULD try the alternate encoding.
If the same resource record type is present at both the standard
encoding and the alternate encoding, the RRSet at the standard
encoding of the name MUST take precedence.
Finally, note that the alternate encoding allows a parent zone to
create RRSets on behalf of a child zone. If an RRSet exists at both
the parent and the child, the child's RRset takes precedence. In
other words, the parent can enter data on behalf of a child but the
child can always over-ride the parent.
Examples:
129.82.160.0/24 --> 129.82.m.1.0.1.0.0.0.0.0
--> 0.0.0.0.0.1.0.1.m.82.129.in-addr.arpa.
129.82.255.0/24 --> 129.82.m.1.1.1.1.1.1.1.1
--> 1.1.1.1.1.1.1.1.m.82.129.in-addr.arpa.
2607:fa88:e000::/36 --> 2.6.0.7.f.a.8.8.m.1.1.1.0
--> 0.1.1.1.m.8.8.a.f.7.0.6.2.ip6.arpa
Gersch, et al. Expires September 1, 2012 [Page 13]
Internet-Draft Reverse DNS CIDR February 2012
6. Security Considerations
This document only introduces a naming convention. Applications that
make use of this naming convention may require the use of DNSSEC to
validate the resource records stored at these names.
Gersch, et al. Expires September 1, 2012 [Page 14]
Internet-Draft Reverse DNS CIDR February 2012
7. IANA Considerations
This document does not request any IANA action.
Gersch, et al. Expires September 1, 2012 [Page 15]
Internet-Draft Reverse DNS CIDR February 2012
8. Acknowledgments
The authors would like to thank Danny McPherson (Verisign), Lixia
Zhang (UCLA), and Kim Claffy (CAIDA) for their comments and
suggestions. This document was aided via numerous discussions at
NANOG, IETF and private meetings with ISPs, telecomm carriers, and
research organizations too numerous to mention by name. Thanks to
all for your comments and advice.
Gersch, et al. Expires September 1, 2012 [Page 16]
Internet-Draft Reverse DNS CIDR February 2012
9. Change History
Changes from version 00 to 01
Introduction added an additional subsection on aligning the DNS
hierarchy with the IP address hierarchy.
Clarified step 1 of the naming algorithm on removing octets that
are not signficant.
Expanded and clarified the discusion of alternate name encodings
for prefixes on an octet boundary.
Added Eric Osterweil as a co-author
Gersch, et al. Expires September 1, 2012 [Page 17]
Internet-Draft Reverse DNS CIDR February 2012
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, August 2006.
10.2. Informative References
[I-D.bates-bgp4-nlri-orig-verif]
Bates, T., Bush, R., Li, T., and Y. Rekhter, "DNS-based
NLRI origin AS verification in BGP",
draft-bates-bgp4-nlri-orig-verif-00 (work in progress),
January 1998.
[I-D.gersch-grow-revdns-bgp]
Gersch, J., Massey, D., Osterweil, E., and L. Zhang, "DNS
Resource Records for BGP Routing Data",
draft-gersch-grow-revdns-bgp-00 (work in progress),
February 2012.
[I-D.howard-isp-ip6rdns]
Howard, L. and A. Durand, "Reverse DNS in IPv6 for
Internet Service Providers", draft-howard-isp-ip6rdns-04
(work in progress), September 2010.
[RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-
ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998.
Gersch, et al. Expires September 1, 2012 [Page 18]
Internet-Draft Reverse DNS CIDR February 2012
Appendix A. Example Zone Files
A.1. Example 1
This example shows several DNS records added to an existing reverse-
DNS zone file at octet boundary 129.82.0.0/16. The records show how
BGP route origins for a CIDR prefix could be specified in the zone
file. Otherwise no other changes were made. This example has added
records with routing information pertinent to address blocks
129.82/16 and the four /18's at 129.82.0.0/18, 129.82.64.0/18,
129.82.128.0/18, and 129.82.192.0/18.
Note: this internet draft is not proposing the RRTypes for routing
shown here; they are only presented as sample content for the
proposed naming convention. A separate document
[I-D.gersch-grow-revdns-bgp] provides details on these RRTYpes.
In addition, the example shows a record for a /24 using the full
8-bit alternate encoding (Section 5.3) so that the data can be placed
in this parent zone rather than in the child zone at 177.82.129.in-
addr.arpa.
Gersch, et al. Expires September 1, 2012 [Page 19]
Internet-Draft Reverse DNS CIDR February 2012
$TTL 3600
$ORIGIN 82.129.in-addr.arpa.
@ IN SOA rush.colostate.edu. dnsadmin.colostate.edu. (
2012021300 ; serial number
900 ; refresh, 15 minutes
600 ; update retry, 10 minutes
86400 ; expiry, 1 day
3600 ; minimum, 1 hour
)
IN NS dns1.colostate.edu.
IN NS dns2.colostate.edu.
@ IN TYPE65400 \# 0
; RLOCK deny all route announcements
; except those authorized
@ IN TYPE65401 \# 4 00002f71
; 129.82.0.0/16 SRO 12145 (SRO "Secure Route Origin")
0.0.m IN TYPE65401 \# 4 00002f71
; 129.82.0.0/18 SRO 12145
1.0.m IN TYPE65401 \# 4 00002f71
; 129.82.64.0/18 SRO 12145
0.1.m IN TYPE65401 \# 4 00002f71
; 129.82.128.0/18 SRO 12145
1.1.m IN TYPE65401 \# 4 00002f71
; 129.82.192.0/18 SRO 12145
1.0.0.0.1.1.0.1.m IN TYPE65401 \# 4 00004070
; 129.82.177.0/24 SRO 12145
; delegations required for 256 /24 zones which contain PTR records
1 IN NS dns1.colostate.edu.
IN NS dns2.colostate.edu.
2 IN NS dns1.colostate.edu.
IN NS dns2.colostate.edu.
; continuation to 255 is left out for the sake of brevity
Gersch, et al. Expires September 1, 2012 [Page 20]
Internet-Draft Reverse DNS CIDR February 2012
A.2. Example 2
This example illustrates the creation of a new zone for
216.17.128.0/17 which is not at an octet boundary. The existing 256
zones delegated at IN-ADDR.ARPA for the range 0.17.128 through
255.17.216.in-addr.arpa remain unchanged; they contain PTR records
maintained by the appropriate zone owners.
In this example we have added several records all at the same domain
name with information pertinent to address block 216.17.128.0/17.
Only a single new delegation needs to be added to IN-ADDR.ARPA:
1.m.17.216.in-addr.arpa NS ns.frii.net
This delegation refers to the new /17 zone and is not in conflict
with any of the pre-existing /24 zones.
$TTL 3600
$ORIGIN 1.m.17.216.in-addr.arpa.
@ IN SOA ns1.frii.net. hostmaster.frii.net. (
2012021300 ; serial number
14400 ; refresh, 4 hours
3600 ; update retry, 1 hour
604800 ; expiry, 7 days
600 ; minimum, 10 minutes
)
IN NS ns1.frii.net.
IN NS ns2.frii.net.
$ORIGIN 17.216.in-addr.arpa.
1.m IN TYPE65400 \# 0
; RLOCK deny all route announcements
; except those authorized
1.m IN TYPE65401 \# 8 000019b6
; 216.17.128.0/17 SRO 6582 (SRO "Secure Route Origin")
1.m IN TYPE65401 \# 8 000019b6
; 216.17.128.0/17 SRO 6582
; no other delegations or PTR records are needed in this zone file
Gersch, et al. Expires September 1, 2012 [Page 21]
Internet-Draft Reverse DNS CIDR February 2012
Authors' Addresses
Joe Gersch
Secure64 SW Corp
Fort Collins, CO
US
Email: joe.gersch@secure64.com
Dan Massey
Colorado State University
Fort Collins, CO
US
Email: massey@cs.colostate.edu
Eric Osterweil
Verisign
Reston, VA
US
Email: eosterweil@verisign.com
Gersch, et al. Expires September 1, 2012 [Page 22]