Classless IN-ADDR.ARPA delegation and dynamic reverse DNS UPDATE
draft-fanf-dnsop-rfc2317bis-00
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 "Replaced".
|
|
|---|---|---|---|
| Author | Tony Finch | ||
| Last updated | 2015-10-13 | ||
| Replaced by | draft-ietf-dnsop-rfc2317bis | ||
| 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-fanf-dnsop-rfc2317bis-00
Domain Name System Operations T. Finch
Internet-Draft University of Cambridge
Obsoletes: 2317 (if approved) October 13, 2015
Updates: 2136 (if approved)
Intended status: Standards Track
Expires: April 15, 2016
Classless IN-ADDR.ARPA delegation and dynamic reverse DNS UPDATE
draft-fanf-dnsop-rfc2317bis-00
Abstract
This memo describes how to do IN-ADDR.ARPA delegation on any non-
octet boundary, and how to consolidate reverse DNS for multiple
address blocks into one zone.
It also clarifies the behaviour of dynamic reverse DNS UPDATE
clients.
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 April 15, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(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
Finch Expires April 15, 2016 [Page 1]
Internet-Draft Classless reverse DNS delegation October 2015
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. DNS master file $GENERATE directive . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Classless IN-ADDR.ARPA delegation for long prefixes . . . . . 5
5. IN-ADDR.ARPA delegation for individual addresses . . . . . . 7
6. Classless IN-ADDR.ARPA delegation for short prefixes . . . . 8
7. Alternative naming conventions . . . . . . . . . . . . . . . 10
8. Consolidated reverse DNS zones . . . . . . . . . . . . . . . 12
9. Dynamic DNS UPDATE for reverse DNS pointers . . . . . . . . . 14
10. Operational considerations . . . . . . . . . . . . . . . . . 16
11. Security Considerations . . . . . . . . . . . . . . . . . . . 16
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
Appendix A. Changes since RFC2317 . . . . . . . . . . . . . . . 19
Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
Since the introduction of classless inter-domain routing (CIDR), it
has become common to assign IPv4 address space on non-octet
boundaries. This memo describes how to do IN-ADDR.ARPA delegation on
any non-octet boundary. There are two complementary methods, using
CNAME records for long prefixes (greater than 24 bits) and using
DNAME records for shorter prefixes.
The CNAME method (Section 4) makes it possible to assign IP address
blocks with prefixes longer than 24 bits, covering fewer than 256
addresses, without losing the ability to delegate authority for the
corresponding IN-ADDR.ARPA mappings. This method is fully compatible
with the original DNS lookup mechanisms specified in [RFC1034], i.e.
there is no need to modify the lookup algorithm used, and there
should be no need to modify any software which does DNS lookups.
For shorter prefixes IN-ADDR.ARPA space is usually delegated on octet
boundaries, which can lead to a proliferation of zones, for instance
a /17 assignment requires 128 delegations. The DNAME method
(Section 6) makes it possible to reduce the number of zones to match
the number of address space assignments. Although DNAME records
[RFC6672] are an extension to the original DNS specification, they
are sufficiently widely supported to make this method feasible.
Finch Expires April 15, 2016 [Page 2]
Internet-Draft Classless reverse DNS delegation October 2015
There is a discussion of DNAME deployment considerations in [RFC7535]
section 6.
These methods can also be used to consolidate multiple address blocks
into a single DNS zone. (Section 8.) This reduces the
administrative overhead of managing delegations; for instance it
reduces the need to update DS records when DNSSEC keys are rolled.
While these methods interoperate well with DNS resolvers, they
require some care from dynamic DNS UPDATE clients that are trying to
change IN-ADDR.ARPA mappings. The client needs to follow the CNAME
and/or DNAME redirections so that its UPDATE request changes the
canonical PTR record without disrupting the redirections.
(Section 9.)
1.1. Terminology
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].
Examples use the "example" special-use domain name [RFC6761], the
example networks 192.0.2.0/24 [RFC5735] and 2001:db8::/32 [RFC5156],
and to illustrate shorter prefixes, the private network 10.0.0.0/8
[RFC1918].
2. DNS master file $GENERATE directive
The examples in this memo are written using DNS master file syntax as
specified in [RFC1035] section 5. Some examples use the $GENERATE
extension, which allows you to generate multiple resource records
based on a numeric range and a template.
The syntax of the $GENERATE directive is:
$GENERATE range domain [ttl] [class] type rdata [comment]
The directive and numeric range are followed by a template resource
record. The ttl, class, type, and comment fields are in standard
master file format.
The range is a pair of unsigned decimal numbers separated by a "-",
and the left-hand (first) number is less than or equal to the right-
hand (last) number. The $GENERATE directive expands an instance of
the template for each number in the range including both endpoints.
range = 1*DIGIT "-" 1*DIGIT ; first-last
Finch Expires April 15, 2016 [Page 3]
Internet-Draft Classless reverse DNS delegation October 2015
The owner domain of the template is a normal domain name, except that
where "$" occurs it is replaced by the generated number. A literal
"$" can be included by escaping it with a backslash, like "\$", or
doubling it, like "$$".
The rdata is expanded in the same way as the domain. If the rdata
includes white space (as in MX records, for example) then the whole
rdata must be quoted. If the rdata needs to be quoted, then it must
be quoted twice.
$GENERATE 0-1 $.text.example. TXT "\"slightly arcane\""
Extended versions of the $GENERATE directive allow you to modify a
substitution by following the "$" with a clause in braces like
"${...}". These modifiers are not described here.
For example, you can use the $GENERATE directive to populate the
reverse zone for a DHCP pool like this:
$ORIGIN 2.0.192.in-addr.arpa.
$GENERATE 1-254 $ PTR dhcp-$.example.com.
This expands to:
$ORIGIN 2.0.192.in-addr.arpa.
1 PTR dhcp-1.example.com.
2 PTR dhcp-2.example.com.
; ... 250 more records ...
253 PTR dhcp-253.example.com.
254 PTR dhcp-254.example.com.
3. Motivation
One of the problems encountered when assigning address space with a
longer prefix (fewer addresses) is that it seems impossible for the
user of the address space to maintain their own reverse ("IN-
ADDR.ARPA") zone autonomously. This obstacle can be overcome using
the reverse delegation method described below.
Let us assume we have assigned the address spaces to three different
parties as follows:
192.0.2.0/25 to organization A
192.0.2.128/26 to organization B
192.0.2.192/26 to organization C
Finch Expires April 15, 2016 [Page 4]
Internet-Draft Classless reverse DNS delegation October 2015
In the classical approach, this would lead to a single zone like
this:
$ORIGIN 2.0.192.in-addr.arpa.
;
1 PTR host1.A.example.
2 PTR host2.A.example.
3 PTR host3.A.example.
;
129 PTR host1.B.example.
130 PTR host2.B.example.
131 PTR host3.B.example.
;
193 PTR host1.C.example.
194 PTR host2.C.example.
195 PTR host3.C.example.
The administration of this zone is problematic. Authority for this
zone can only be delegated once, and this usually translates into
"this zone can only be administered by one organization." The other
organizations with address space that corresponds to entries in this
zone would thus have to depend on another organization for their
address to name translation. This potential problem can be avoided
using the method described in this memo.
4. Classless IN-ADDR.ARPA delegation for long prefixes
This section describes classless IN-ADDR.ARPA delegation for prefix
lengths between /25 and /31 inclusive.
Since a single zone (such as 2.0.192.in-addr.arpa) can only be
delegated once, we need more delegation points to solve our problem.
An extra delegation point can be introduced by extending the IN-
ADDR.ARPA tree downwards, by adding a label that is not entirely
numeric so it does not clash with the existing reverse DNS names.
For each /24 subdivided up using this method, there are 256 CNAME
records in the parent zone pointing into the child zones via these
extra delegation points. It is quite easy to automatically generate
the CNAME resource records in the parent zone once and for all, after
you know the way the address space is partitioned.
Finch Expires April 15, 2016 [Page 5]
Internet-Draft Classless reverse DNS delegation October 2015
Continuing the motivating example given in Section 3, here is how you
can divide a /24 into a /25 and two /26 ranges.
$ORIGIN 2.0.192.in-addr.arpa.
@ IN SOA ns0.isp.example. ( ... )
; ...
;
0-127 NS ns1.A.example.
0-127 NS ns2.A.example.
;
$GENERATE 0-127 $ CNAME $.0-127
;
128-191 NS ns1.B.example.
128-191 NS ns2.B.example.
;
$GENERATE 128-191 $ CNAME $.128-191
;
192-255 NS ns1.C.example.
192-255 NS ns2.C.example.
;
$GENERATE 192-255 $ CNAME $.192-255
In this example the extra delegation points are named after the
bottom and top addresses in the delegated address range, using the
same format as the $GENERATE range specifier.
The $GENERATE directives produce 256 CNAME records which when
expanded look like:
42.2.0.192.in-addr.arpa. CNAME 42.0-127.2.0.192.in-addr.arpa.
The child zones might look something like:
$ORIGIN 0-127.2.0.192.in-addr.arpa.
@ IN SOA ns0.A.example. ( ... )
NS ns1.A.example.
NS ns2.A.example.
;
1 PTR host1.A.example.
2 PTR host2.A.example.
3 PTR host3.A.example.
Finch Expires April 15, 2016 [Page 6]
Internet-Draft Classless reverse DNS delegation October 2015
$ORIGIN 128-191.2.0.192.in-addr.arpa.
@ IN SOA ns0.B.example. ( ... )
NS ns1.B.example.
NS ns2.B.example.
;
129 PTR host1.B.example.
130 PTR host2.B.example.
131 PTR host3.B.example.
$ORIGIN 192-255.2.0.192.in-addr.arpa.
@ IN SOA ns0.C.example. ( ... )
NS ns1.C.example.
NS ns2.C.example.
;
193 PTR host1.C.example.
194 PTR host2.C.example.
195 PTR host3.C.example.
When a client does a reverse DNS query for an IP address in this
range, it will get an answer like this:
;; QUESTION SECTION:
;42.2.0.192.in-addr.arpa. IN PTR
;; ANSWER SECTION:
42.2.0.192.in-addr.arpa. CNAME 42.0-127.2.0.192.in-addr.arpa.
42.0-127.2.0.192.in-addr.arpa. PTR host42.A.example.
(TTL and CLASS omitted to save space.)
5. IN-ADDR.ARPA delegation for individual addresses
This section describes IN-ADDR.ARPA delegation for prefix lengths of
/32, that is, individual IP addresses.
The CNAME trick described in the previous section is not necessary
when delegating the reverse DNS for an individual IP address.
Instead you can delegate at the reverse DNS name itself (for example,
delegate at 42.2.0.192.in-addr.arpa), and put the PTR record at the
apex of the delegated zone.
Finch Expires April 15, 2016 [Page 7]
Internet-Draft Classless reverse DNS delegation October 2015
In detail (not continuing the previous examples), say isp.example has
delegated the reverse DNS for 192.0.2.42/32 to their customer
K.example:
$ORIGIN 2.0.192.in-addr.arpa.
@ IN SOA ns0.isp.example. ( ... )
; ...
42 NS ns1.K.example.
42 NS ns2.K.example.
; ...
The delegated zone will only have a few records at its apex:
$ORIGIN 42.2.0.192.in-addr.arpa.
@ IN SOA ns0.K.example. ( ... )
NS ns1.K.example.
NS ns2.K.example.
PTR host42.K.example.
The CNAME method described in Section 4 is in fact not necessary.
You can delegate the reverse DNS for a CIDR address block by setting
up delegations and /32 zones for every address in the block. However
it is usually simpler to set up a single delegated zone and an
automatically-generated set of CNAME records.
6. Classless IN-ADDR.ARPA delegation for short prefixes
This section describes classless IN-ADDR.ARPA delegation for prefix
lengths between /9 and /23 inclusive, except for /16 which falls on
an octet boundary.
Just as you can replace lots of /32 zones with one CIDR zone and some
CNAME records, you can replace lots of /24 or /16 zones with one CIDR
zone and some DNAME records. It is equally easy to set up, though
the way it works is a bit more complicated.
DNAME records are described in [RFC6672], but here is a very terse
summary. Whereas a CNAME record acts as a redirect for its owner
name, a DNAME record acts as a redirect for descendents of its owner
name, but not the name itself. Whereas a wildcard CNAME redirects a
subtree of the DNS namespace to a single target name, a DNAME
redirects a subtree to corresponding names in a different subtree.
Say, for example, that two organizations A and B want to share
10.0.0.0/8, one using the bottom half and the other using the top
half. But they would each prefer not to have to manage 128 master
zones of their own and 128 secondary zones from their counterpart.
Finch Expires April 15, 2016 [Page 8]
Internet-Draft Classless reverse DNS delegation October 2015
They can reduce this from 256 zones (one for each /16) to 2 zones
(one for each /9) by setting up the parent zone like this:
$ORIGIN 10.in-addr.arpa.
@ IN SOA ns0.B.example. ( ... )
; ...
;
0-127 NS ns1.A.example.
0-127 NS ns2.A.example.
;
$GENERATE 0-127 $ DNAME $.0-127
;
128-255 NS ns1.B.example.
128-255 NS ns2.B.example.
;
$GENERATE 128-255 $ DNAME $.128-255
The $GENERATE directives produce 256 DNAME records which when
expanded look like:
2.10.in-addr.arpa. DNAME 2.0-127.10.in-addr.arpa.
This DNAME record has the effect of mapping names under 2.10.in-
addr.arpa to corresponding names under 2.0-127.10.in-addr.arpa, like
this:
4.3.2.10.in-addr.arpa -> 4.3.2.0-127.10.in-addr.arpa
The child zones will look something like,
$ORIGIN 0-127.10.in-addr.arpa.
@ IN SOA ns0.A.example. ( ... )
NS ns1.A.example.
NS ns2.A.example.
;
4.3.2 PTR host4.A.example. ; 10.2.3.4
$ORIGIN 128-255.10.in-addr.arpa.
@ IN SOA ns0.B.example. ( ... )
NS ns1.B.example.
NS ns2.B.example.
;
20.100.200 PTR host20.B.example. ; 10.200.100.20
Finch Expires April 15, 2016 [Page 9]
Internet-Draft Classless reverse DNS delegation October 2015
When a client does a reverse DNS query for an IP address in this
range, it will get an answer containing a DNAME record, a synthesized
CNAME record, and the canonical answer:
;; QUESTION SECTION:
;4.3.2.10.in-addr.arpa. IN PTR
;; ANSWER SECTION:
2.10.in-addr.arpa. DNAME 2.0-127.10.in-addr.arpa.
4.3.2.10.in-addr.arpa. CNAME 4.3.2.0-127.10.in-addr.arpa.
4.3.2.0-127.10.in-addr.arpa. PTR host4.A.example.
(TTL and CLASS omitted to save space.)
7. Alternative naming conventions
In the sections above, we have suggested naming CIDR subdomains using
the same notation as $GENERATE ranges, first-last. However the
choice of name is just convention, and you are free to use a
different convention if that is more convenient for you.
7.1. Subnet base slash prefix length (a bad idea)
In its main example, the predecessor to this memo [RFC2317] suggested
using the subnet's first address and prefix length separated by a
slash, for instance,
$ORIGIN 2.0.192.in-addr.arpa.
129 CNAME 129.128/26.2.0.192.in-addr.arpa.
However, it then went on to say this is a bad idea. The remainder of
this section quotes [RFC2317]:
Some DNS implementations are not kind to special characters in domain
names, e.g. the "/" used in the above examples. As [RFC2181] makes
clear, these are legal, though some might feel unsightly. Because
these are not host names the restriction of [RFC0952] does not apply.
Modern clients and servers have an option to act in the liberal and
correct fashion.
The examples here use "/" because it was felt to be more visible and
pedantic reviewers felt that the 'these are not hostnames' argument
needed to be repeated. We advise you not to be so pedantic, and to
not precisely copy the above examples, e.g. substitute a more
conservative character, such as hyphen, for "/".
Finch Expires April 15, 2016 [Page 10]
Internet-Draft Classless reverse DNS delegation October 2015
7.2. Subnet base hyphen prefix length
The sensible version of the [RFC2317] convention is to use the
subnet's first address and prefix length separated by a hyphen, for
instance,
$ORIGIN 2.0.192.in-addr.arpa.
129 CNAME 129.128-26.2.0.192.in-addr.arpa.
7.3. Subnet base only (a bad idea)
Another alternative mentioned in [RFC2317] is the subnet's first
address by itself.
With this convention, most addresses in the subnet have a CNAME (as
in Section 4), but the subnet base address does not and instead looks
like a /32 delegation (as in Section 5).
Because of its lack of uniformity we discourage you from using this
convention.
7.4. Customer ID
It is not necessary for the subdomain to be tied to an address range;
it could instead be a customer name or other ID. Then if that
customer's address allocation changes, their provider can just add or
remove CNAME or DNAME records without having to change the
delegation.
This convention can also be useful if two organizations somehow share
the same physical subnet (and corresponding IP address space) with no
"neat" CIDR split between the allocations, but they still want to
administrate their own IN-ADDR.ARPA mappings.
7.5. In the forward DNS tree
Finch Expires April 15, 2016 [Page 11]
Internet-Draft Classless reverse DNS delegation October 2015
The CNAME or DNAME records do not have to point into a subdomain: it
is also possible to point to an entirely different part of the DNS
tree, that is, outside of the IN-ADDR.ARPA tree. This variant of our
running example might look like,
$ORIGIN 2.0.192.in-addr.arpa.
@ IN SOA ns0.isp.example. ( ... )
; ...
$GENERATE 0-127 $ CNAME $.A.example.
$GENERATE 128-191 $ CNAME $.B.example.
$GENERATE 192-255 $ CNAME $.C.example.
$ORIGIN A.example.
@ IN SOA ns0.A.example. ( ... )
; ...
;
host1 A 192.0.2.1
1 PTR host1
;
host2 A 192.0.2.2
2 PTR host2
;
; ...
This way you can actually end up with the name -> address and the
(pointed-to) address -> name mapping data in the same zone file. The
two mutually inverse mappings can be updated in the same DNS UPDATE
transaction (though this benefit should not be exaggerated: the
records will be still be cached separately and will time out
independently). Do however note that the resolver's traversal via
the IN-ADDR.ARPA tree will still be done, so the CNAME records
inserted there need to point to the right place for this to work.
8. Consolidated reverse DNS zones
This section describes how to reduce the number of reverse DNS
delegations. It applies to any prefix length, and can be used for
IPv6 as well as IPv4.
Section 7.5 suggests setting up DNAME and/or CNAME records to point
from the reverse DNS tree to the forward DNS. A significant
advantage of this is that it eliminates a delegation: instead of
having to agree on a CIDR subdomain name, an NS RRset, and a DS
RRset, and keep these up-to-date as name servers and DNSSEC keys
change, you only need to agree on a target consolidation domain name.
The convention we recommend is to lay out part of your forward DNS
namespace in the same way as the standard reverse DNS. That is, set
Finch Expires April 15, 2016 [Page 12]
Internet-Draft Classless reverse DNS delegation October 2015
up an "in-addr" subdomain under which you place PTR records for
reversed dotted-quad IPv4 addresses, and/or an "ip6" subdomain under
which you place PTR records for reversed exploded IPv6 addresses.
This allows you to consolidate the reverse DNS for multiple disparate
address blocks into the same zone. (You can have separate
consolidation zones for IPv4 and IPv6, and for public and private
addresses.)
For example, say organization A decides to consolidate their reverse
zones. They would set up their forward DNS like this:
$ORIGIN A.example.
@ IN SOA ns0.A.example. ( ... )
; ...
;
1.2.0.192.in-addr PTR host1
2.2.0.192.in-addr PTR host2
4.3.2.10.in-addr PTR host4
For long prefixes like 192.0.2.0/25, organization A asks their
provider to point CNAME records at their consolidation domain under
A.example, like this:
$ORIGIN 2.0.192.in-addr.arpa.
; ...
$GENERATE 0-127 $ CNAME $.2.0.192.in-addr.A.example.
For short prefixes like 10.0.0.0/9, organization A asks their
provider to point DNAME records at their consolidation domain under
A.example, like this:
$ORIGIN 10.in-addr.arpa.
; ...
$GENERATE 0-127 $ DNAME $.10.in-addr.A.example.
Similarly, for its IPv6 network 2001:db8:A::/48, organization A again
asks for a DNAME record, like this:
$ORIGIN 8.b.d.0.1.0.0.2.ip6.arpa.
; ...
A.0.0.0 DNAME A.0.0.0.8.b.d.0.1.0.0.2.ip6.A.example.
To get the full benefit of a consolidated reverse zone, DNAME records
should be used instead of delegations. However this requires co-
operation from the provider of the address space.
It is possible to delegate the reverse DNS as usual, then put a DNAME
record at the apex of the delegated zone. (Unlike CNAMEs, DNAMEs do
Finch Expires April 15, 2016 [Page 13]
Internet-Draft Classless reverse DNS delegation October 2015
not conflict with other records at the same name.) This makes the
reverse zone small and static, which is a small advantage, though it
does not avoid the other overheads of managing a delegation.
9. Dynamic DNS UPDATE for reverse DNS pointers
This section updates the DNS UPDATE specification [RFC2136]. It
specifies additional requirements for DNS UPDATE clients, so they can
dynamically change revers DNS PTR records in a way that is compatible
with the techniques described in the previous sections. It applies
both to the IPv4 reverse DNS under IN-ADDR.ARPA and the IPv6 reverse
DNS under IP6.ARPA.
These additional requirements only apply to DNS UPDATE clients that
wish to add, remove, or change PTR records in the reverse DNS. No
new requirements affect other uses of DNS UPDATE, including changes
to other records in the reverse DNS. (In particular, these
requirements do not apply if you are using DNS UPDATE to deploy
classless IN-ADDR.ARPA delegations.)
In this section, we use the term "reverse DNS query name" to mean a
name under IN-ADDR.ARPA or IP6.ARPA which a resolver uses when making
a reverse DNS query. The resolver expects this name to resolve to a
PTR RRset, but (as described in previous sections) it does not have
to be the direct owner of the PTR RRset but can instead be an alias.
The problem addressed by this section is that DNS UPDATE clients
sometimes use a reverse DNS query name in an UPDATE message without
checking for CNAME or DNAME redirections. If the usual reverse DNS
query name is an alias, then this behavior results in an attempt to
add or delete a PTR record to or from a node that already contains
the CNAME record, and the update fails.
Aside: Presumably the UPDATE will also fail if the node is occluded
below a DNAME record, but neither [RFC2136] nor [RFC6672]
specifies how a server out to react to attempts to UPDATE an
occluded domain name.
9.1. Requirements for updating PTR records in the reverse DNS
When updating a PTR record in the reverse DNS, an UPDATE client
SHOULD NOT simply convert the IP address to a reverse DNS query name
and send an UPDATE request for the PTR RRset at that name. It MUST
NOT assume the zone cut falls on a particular boundary such as /24
for IPv4 or /64 for IPv6.
Instead, the UPDATE client SHOULD canonicalize all reverse DNS query
names that it uses in its UPDATE message. It MUST ensure that all
Finch Expires April 15, 2016 [Page 14]
Internet-Draft Classless reverse DNS delegation October 2015
the canonical names are within the same zone and that the ZNAME field
in the UPDATE message refers to this zone.
9.2. Suggested behaviour
In the absence of more specific configuration, a reverse DNS UPDATE
client can follow this procedure.
Send a SOA query for the reverse DNS query name. There are four
kinds of useful response.
o There is a SOA record at the query name, which is returned in the
answer section of the response. This can occur if the name has a
/32 delegation.
o The query name is an alias for a name with a SOA record. The
answer section of the response contains a CNAME chain and a SOA
record.
o The query name is not an alias. The response is NOERROR or
NXDOMAIN. The answer section is empty, and the authority record
contains a SOA record. This is the traditionally expected result.
o The query name is an alias. The response is NOERROR or NXDOMAIN.
The answer section has a CNAME chain, and the authority record
contains a SOA record. This is the normal case for classless IN-
ADDR.ARPA delegations or consolidated reverse DNS.
In other cases there has been some kind of problem and the DNS UPDATE
cannot proceed.
(Note that if the reverse DNS query name is under a DNAME, the
response will contain a DNAME in the answer section and a synthesized
CNAME. The UPDATE client can ignore the DNAME and just use the CNAME
records.)
(There can also be other records in the response, but they are not
relevant to this procedure and so are not discussed here.)
All of the useful responses give the DNS UPDATE client enough
information to construct a correct UPDATE message.
o The server to send the UPDATE message to comes from the SOA MNAME
field.
o The UPDATE ZNAME comes from the owner name of the SOA record.
Finch Expires April 15, 2016 [Page 15]
Internet-Draft Classless reverse DNS delegation October 2015
o The canonical name of the PTR RRset comes from the final target of
the CNAME chain, or the QNAME if there are no CNAME records in the
answer.
10. Operational considerations
10.1. Secondary name service
Very old name server software might not find and return the target
name in CNAME records if the targte name is not already known locally
as cached or as authoritative data. This can cause some confusion in
stub resolvers, as only the CNAME record will be returned in the
response. To avoid this problem it is recommended that the
authoritative name servers for the delegating zone (the zone
containing all the CNAME or DNAME records) all run as secondary name
servers for the target zones delegated and pointed into via the
CNAME/DNAME records.
10.2. CNAME chains
Multiple levels of delegation using the methods described in this
memo lead to multi-step CNAME and/or DNAME chains. Although
[RFC1034] requires resolvers to handle CNAME chains robustly, such a
setup might be less reliable overall.
10.3. Mail servers
SMTP servers are often very picky about reverse DNS, and some are
known to be intolerant of DNAME records. Therefore it is wise to be
wary of deploying the methods described in Section 6 and Section 8
for IP address ranges that contain outgoing inter-domain mail
senders.
11. Security Considerations
With this scheme, the "leaf sites" might need to rely on one more
site running their DNS name service correctly than they would be if
they had a /24 allocation of their own, and this might add an extra
component which will need to work for reliable name resolution.
Normal reverse DNS delegations and classless delegations require more
frequent changes when zones are signed for DNSSEC [RFC4034]
[RFC4035], to update the DS records in the parent zone to track key
rollovers. Consolidated reverse zones (Section 8) replace
delegations with CNAME and/or DNAME pointers. This reduces the
number of secure delegations that must be managed, which should make
operations simpler and more robust; however it means that reverse DNS
resolution depends on chains of trust in the forward DNS as well as
Finch Expires April 15, 2016 [Page 16]
Internet-Draft Classless reverse DNS delegation October 2015
the reverse DNS. This does not necessarily increase the number of
trusted entities in a meaningful way, if the consolidated reverse
zone is in the same part of the namespace as the targets of the PTR
records.
12. Acknowledgments
Glen A. Herrmannsfeldt described this technique (specifically the
Section 7.4 variant) on the comp.protocols.tcp-ip.domains newsgroup
in 1991 [GAH1] and in more detail in 1994 [GAH4]. Alan Barrett and
Sam Wilson provided valuable comments.
Chris Thompson described the technique in Section 8 on the bind-users
mailing list in 2009 [CET]. Chris Hills and Niall O'Reilly confirmed
they had also deployed it.
Petr Spacek pointed out the need to clarify the behaviour of dynamic
DNS UPDATE requests for reverse DNS mappings
[I-D.spacek-dnsop-update-clarif].
Thanks to the authors of [RFC2317]: Havard Eidnes, Geert Jan de
Groot, and Paul Vixie.
13. References
13.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997,
<http://www.rfc-editor.org/info/rfc2136>.
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
<http://www.rfc-editor.org/info/rfc6672>.
Finch Expires April 15, 2016 [Page 17]
Internet-Draft Classless reverse DNS delegation October 2015
13.2. Informative References
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
host table specification", RFC 952, DOI 10.17487/RFC0952,
October 1985, <http://www.rfc-editor.org/info/rfc952>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<http://www.rfc-editor.org/info/rfc1918>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
<http://www.rfc-editor.org/info/rfc2181>.
[RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-
ADDR.ARPA delegation", BCP 20, RFC 2317, DOI 10.17487/
RFC2317, March 1998,
<http://www.rfc-editor.org/info/rfc2317>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<http://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<http://www.rfc-editor.org/info/rfc4035>.
[RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, DOI
10.17487/RFC5156, April 2008,
<http://www.rfc-editor.org/info/rfc5156>.
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
RFC 5735, DOI 10.17487/RFC5735, January 2010,
<http://www.rfc-editor.org/info/rfc5735>.
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
RFC 6761, DOI 10.17487/RFC6761, February 2013,
<http://www.rfc-editor.org/info/rfc6761>.
[RFC7535] Abley, J., Dickson, B., Kumari, W., and G. Michaelson,
"AS112 Redirection Using DNAME", RFC 7535, DOI 10.17487/
RFC7535, May 2015,
<http://www.rfc-editor.org/info/rfc7535>.
Finch Expires April 15, 2016 [Page 18]
Internet-Draft Classless reverse DNS delegation October 2015
[I-D.spacek-dnsop-update-clarif]
Spacek, P., "Clarifications to the Dynamic Updates in the
Domain Name System (DNS UPDATE) specification", draft-
spacek-dnsop-update-clarif-01 (work in progress), August
2015.
[GAH1] Herrmannsfeldt, G., "Re: Subnets and IN-ADDR.ARPA", April
1991, <https://groups.google.com/d/original/
comp.protocols.tcp-ip.domains/39RWpZ549AY/T10zM45oT88J>.
[GAH4] Herrmannsfeldt, G., "Re: Nonstandard subnetting", December
1994, <https://groups.google.com/d/original/
comp.protocols.tcp-ip.domains/ejo4z2CTVLc/s3sTyhjDtOQJ>.
[CET] Thompson, C., "Pruning the reverse zone tree", February
2009, <https://lists.isc.org/pipermail/bind-
users/2009-February/075240.html>.
Appendix A. Changes since RFC2317
o Use a recommended naming convention in the main example. Clearly
describe which alternative conventions are good and bad ideas.
o Add a description of /32 delegations.
o Add a description of using DNAME for delegations on short
prefixes.
o Emphasize the consolidated reverse DNS convention.
o Add a description of $GENERATE and use it in the examples.
o Specify new requirements on dynamic reverse DNS UPDATE clients.
o Better citations for Glen Herrmannsfeldt's original description.
Appendix B. Changelog
Note to RFC editor: This section should be removed before
publication. The important points should appear in the previous
section.
A detailed revision log can be found at
<https://git.csx.cam.ac.uk/x/ucs/u/fanf2/rfc2317bis.git>.
Finch Expires April 15, 2016 [Page 19]
Internet-Draft Classless reverse DNS delegation October 2015
Author's Address
Tony Finch
University of Cambridge Information Services
Roger Needham Building
7 JJ Thomson Avenue
Cambridge CB3 0RB
England
Phone: +44 797 040 1426
Email: dot@dotat.at
Finch Expires April 15, 2016 [Page 20]