IPng Working Group Matt Crawford Internet Draft Fermilab March 13, 1998 DNS Lookups Keyed on IPv6 Addresses 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]