IPng Working Group Matt Crawford
Internet Draft Fermilab
March 13, 1998
DNS Lookups Keyed on IPv6 Addresses
<draft-ietf-ipngwg-dns-lookups-00.txt>
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (North
Europe), ftp.nis.garr.it (South Europe), ds.internic.net (US East
Coast), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
Distribution of this memo is unlimited.
1. Abstract
This document defines a new structure for the zones which support
DNS lookups keyed on IPV6 addresses. (Often called reverse
lookups.) It allows address space to be delegated on arbitrary
bit-boundaries. The delegation information can be be usefully
cached. A zone describing delegated space can be used for multiple
parallel copies of that address space, as for a dual-homed provider
or site, and need not be modified if the space is renumbered at a
higher level.
The new structure can coexist with the old tree under the same name,
IP6.INT.
Expires September 18, 1998 Crawford [Page 1]
Internet Draft IPv6 DNS March 13, 1998
2. Background
To fulfill the grand claims made in the abstract, this document
relies on new DNS features described in Internet-Drafts designated
[BITLBL], [DNAME], and [EDNS]. This first draft is a working
document intended only to sketch the new structure with the
intention of convincing the reader that the above claims are
realistic.
3. Underlying Mechanisms
This section describes the new proposed new DNS features which this
document exploits. The reader is directed to the referenced drafts
for more details on each.
3.1. Delegation on Arbitrary Boundaries
This new scheme for reverse lookups relies on a new type of DNS
label called the "bit-string label" [BITLBL]. This label compactly
represents an arbitrary string of bits which is treated as a
hierarchical sequence of one-bit domain labels. Resource records
can be stored on arbitrary bit-boundaries and bit-string label
processing is subject to a longest-match rule which will return
records from the nearest ancestor node which has them if the
requested information cannot be found at the queried name itself.
Examples in section 4 will employ the following textual format for
bit-string labels. A base indicator, either "b" for binary or "x"
for hexadecimal, and sequence of digits in the indicated base is
enclosed between "\[x" and "]". The bits denoted by the digits
represent a sequence of one-bit domain labels ordered from most to
least significant. (This is the opposite of the order they would
appear if listed one bit at a time, but it appears to be a
convenient notation.) The digit string may be followed by a slash
("/") and a decimal count. If omitted, the implicit count is equal
to the number of binary digits or four times the number of
hexadecimal digits.
Consecutive bit-string labels are equivalent (up to the limit
imposed by the size of the bit count field) to a single bit-string
label containing all the bits of the consecutive labels in the
proper order. As an example, either of the following domain names
could be used in a QCLASS=IN, QTYPE=PTR query to find the name of
Expires September 18, 1998 Crawford [Page 2]
Internet Draft IPv6 DNS March 13, 1998
the node with IPv6 address 3ffe:7c0:40:9:a00:20ff:fe81:2b32.
\[x3FFE07C0004000090A0020FFFE812B32/128].ip6.int.
\[x0A0020FFFE812B32/64].\[x0009/16].
\[x07C00040/32].\[xFFF0/13].\[b001/3].ip6.int.
None of the bit counts in the either form are required except the
"/13". Note that bits are left-justified in a hexadecimal string.
3.2. Reusable Zones
DNS address space delegation is implemented not by zone cuts and NS
records, but by a new analogue to the CNAME record, called the DNAME
record [DNAME]. The DNAME record provides alternate naming to an
entire subtree of the domain name space, rather than to a single
node. It causes some suffix of a queried name to be substituted
with a name from the DNAME record's RDATA.
For example, a resolver or server providing recursion, while looking
up a QNAME a.b.c.d.e.tld may encounter a DNAME record
d.e.tld. DNAME w.xy.
which will cause it to look for a.b.c.w.xy.
3.3. Coexistence
All data supporting the new reverse lookup scheme will be stored at
DNS nodes whose names include at least one bit-string label. By
issuing a query for such a name, a resolver indicates that it
understands the new label type [EDNS]. Alternatively, a resolver
can indicate its compliance with EDNS features by inclusion of a new
OPT RR in a query.
4. Zone Structure
Very little of the new scheme's data actually appears under IP6.INT.
Only the first level of delegation needs to be under that (or
another fixed and well-known) domain, although more levels of
delegation could be done under IP6.INT if some top-level delegations
were done via NS records instead of DNAME records. This would incur
a possibly-negligible cost in loss of renumbering ease at the level
of TLAs [AARCH]. The examples which follow assume that delegations
by NS records are not done.
Expires September 18, 1998 Crawford [Page 3]
Internet Draft IPv6 DNS March 13, 1998
4.1. The Top Level
Supposing that address space assignments in the TLAs with Format
Prefix (001) binary and IDs 1, 2 and 3 were maintained in zones
called alpha-registry.tld, bravo.tla.nil and charlie-net.xy, the
IP6.INT zone would include
$ORIGIN IP6.INT.
\[x200100/24] DNAME alpha-registry.tld.
\[x200200/24] DNAME bravo.tla.nil.
\[x200300/24] DNAME charlie-net.xy.
Eight trailing zero bits have been included in each TLA ID to
reflect the eight reserved bits in the current aggregatable global
unicast addresses format [AARCH].
4.2. The TLA level
Now suppose that Alpha-Registry has assigned the prefixes
2001:0:4000::0/34, 2001:1:200::0/39 and 2001:2:20::0/43 to a large
ISP, a medium-sized ISP, and a corporation with a network linking 25
sites. Its zone could record these assignments as
$ORIGIN alpha-registry.tld.
@ TXT "This domain delegates from a /24 prefix"
\[x004/10] DNAME ip6-addr.big-isp.example.
\[x0102/15] DNAME nla-space.med-isp.example.
\[x02002/19] DNAME site-register.world-wide-widgets.tld.
4.3. The ISP level
The medium-sized ISP of the previous section might list a lower-
level ISP and two customer sites in its zone as follows.
$ORIGIN nla-space.med-isp.example.
@ TXT "This domain delegates from a /39 prefix"
\[b001/3] DNAME customers.small-isp.example.
\[x800/9] DNAME reverse-zone.example.com.
\[x808/9] DNAME sla.example.org.
The last-listed customer site might be dual-homed to Big-ISP, who
delegates it another global prefix.
Expires September 18, 1998 Crawford [Page 4]
Internet Draft IPv6 DNS March 13, 1998
$ORIGIN ip6-addr.big-isp.example.
@ TXT "This domain delegates from a /34 prefix"
\[x1234/14] DNAME sla.example.org.
Note the same domain name in this DNAME record. The customer will
use the same zone to map both global prefixes.
4.4. The Site Level
Consider the customer Example.Org using sla.example.org for
address-to-name translations. This domain is now referenced by two
different DNAME records held by two different providers.
$ORIGIN \[x0001/16].sla.example.org. ; subnet 1
\[x020855FFFE012345] PTR www.example.org.
\[x020855FFFE345678] PTR ns1.example.org.
$ORIGIN \[x0001/16].sla.example.org. ; subnet 2
\[x020855FFFE67890A] PTR mailhub.example.org.
5. Lookups
A DNS resolver looking for a hostname for the address
2001:1:301:1:208:55ff:fe01:2345 would acquire certain of the DNAME
records shown above and would form new queries. Assuming that it
began the process knowing servers for IP6.INT, but that no server it
consulted provided recursion and none had other useful additional
information cached, the sequence of queried names and responses
would be:
Expires September 18, 1998 Crawford [Page 5]
Internet Draft IPv6 DNS March 13, 1998
To a server for ip6.int:
QTYPE=PTR QNAME=\[x2001000103010001020855fffe012345/128].ip6.int.
Answer:
\[x200100/24].ip6.int. DNAME alpha-registry.tld.
To a server for alpha-registry.tld:
QTYPE=PTR QNAME=\[x0103010001020855fffe012345/104].alpha-registry.tld.
Answer:
\[x0102/15].alpha-registry.tld. DNAME nla-space.med-isp.example.
To a server for nla-space.med-isp.example:
QTYPE=PTR QNAME=\[x80800081042affff0091a28/89].
nla-space.med-isp.example.
Answer:
\[x808/9].nla-space.med-isp.example. DNAME sla.example.org.
To a server for sla.example.org:
QTYPE=PTR QNAME=\[x0001020855fffe012345].sla.example.org.
Answer:
\[x0001020855fffe012345].sla.example.org. PTR www.example.org.
All the DNAME (and NS) records acquired along the way can be cached
to expedite resolution of addresses topologically near to this
address. And if the other global address of www.example.org were
resolved within the TTL of the final PTR record, that record would
not have to be fetched again.
6. Uniformity
The examples above assume that organizations conspicuously fail to
employ any sort of uniform naming convention for the part of their
DNS space in which they record address delegations and assignments.
Registries, network providers and sites might benefit from such a
convention.
7. Security Considerations
DNS Security [DNSSEC] is fully applicable to bit-string labels and
DNAME records. However, authentication of data in the reverse zones
is not equivalent to authentication of any "forward" data, such as
AAAA records.
Expires September 18, 1998 Crawford [Page 6]
Internet Draft IPv6 DNS March 13, 1998
8. References
[AARCH] R. Hinden, S. Deering, "IP Version 6 Addressing
Architecture", Currently draft-ietf-ipngwg-addr-arch-v2-
06.txt.
[BITLBL] M. Crawford, "Binary Labels in the Domain Name System",
currently draft-ietf-dnsind-binary-labels-01.txt.
[DNAME] M. Crawford, "Non-Terminal DNS Name Redirection", currently
draft-ietf-dnsind-dname-00.txt.
[DNSSEC] D. Eastlake, 3rd, C. Kaufman, "Domain Name System Security
Extensions", RFC 2065.
[EDNS] P. Vixie, "Extensions to DNS (EDNS)" currently draft-ietf-
dnsind-edns-01.txt.
9. Author's Address
Matt Crawford
Fermilab MS 368
PO Box 500
Batavia, IL 60510
USA
Phone: +1 630 840-3461
EMail: crawdad@fnal.gov
Expires September 18, 1998 Crawford [Page 7]
