Internet-Draft O. Gudmundsson IPng Working Group TIS <draft-ietf-ipng-dns-reverse-lookup-00.txt> November 1997 Reverse Address lookup in DNS for IPng. <draft-ietf-ipngwg-dns-reverse-lookup-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 ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Distribution of this memo is unlimited. Abstract This document proposes a new mechanism to represent inverse address mapping in the Domain Name System (DNS) for IP version 6 (IPv6). Documented in here are the changes needed for securing the binding and delegation of address ranges, to facilitate queries for the binding of address to host name. This document also defines a mechanism for dumb resolvers to query directly for the binding. The changes include a new resource record to delegate the address space in segments based on arbitrary bit boundaries. This proposal provides a mechanism that is self checking and can be traversed from both top and bottom. Additional processing requirements on IPv6 aware resolvers and servers are defined. Gudmundsson Expires May 1998 [Page 1]
Internet-Draft ipngwg-dns-reverse-lookup-00.txt November 1997 1. Introduction Current support for the storage of Internet addresses in the Domain Name System (DNS)[RFC1034,RFC1035,RFC2181] cannot easily be extended to support IPv6 addresses[HD97] since applications assume that address queries return 32-bit IPv4 addresses only. A proposal to store IPv6 address was proposed[RFC1886] but that proposal does not scale well to the new IPv6 address architecture[HD97]. The main drawbacks are that there has to be a AAAA record for all routing prefixes for every host. If one routing prefix changes, all AAAA records affected need to be changed and, if DNSSEC[RFC2065] is used, then all affected AAAA sets need to be resigned. A new proposal[HT97] addresses a how IPv6 address lookup can be accomplished while avoiding the above problems. To support the lookup of the mapping from address to host name (reverse lookup) for IPv6 addresses this document defines the following extensions: * A new domain is defined to support lookups based on address. * A new resource record type to represent delegations in the reverse map. This memo proposes an incompatible extension to the specification in RFC 1886, and a departure from current implementation practices, but is as compatible with current practices as possible. The structure defined in here can also be extended to other address types, such as IPv4. 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]. 2. Motivation and Design criteria Reverse address maps are used to identify what computer is trying to connect to another computer. This is an essential tool for network services providers, this is also used to debug network problems. Gudmundsson Expires May 1998 [Page 2]
Internet-Draft ipngwg-dns-reverse-lookup-00.txt November 1997 This document proposes a radical new way to handle reverse mapping of addresses for IPng. The main motivations for this proposal are to meet the following requirements: * IPng new addressing architecture * Support for rapid renumbering with minimal cost to DNS servers * Allow the reverse address map to be maintained in a distributed way similar to the forward address map * Provide verifiable binding of addresses to names when DNSSEC is used. This design takes into account many of the lessons learned from the problems in IPv4 reverse address maps when classless delegations where introduced. This proposal requires that the domain names in the reverse map be binary values. This is done to save space and time. If the community does not think this is a good idea it is possible to encode the binary values in Base64 or Hex, but given that most reverse lookups are performed by computers without any human interaction this should not be a problem and will reduce DNS server overhead. This proposal allows delegations to occur on any bit boundary in the address. This could in theory lead to the problem where a reverse address has 130 labels (128 bits + 2 for IP6.INT.). In practice this is impossible as the bottom delegation is in most cases 64 bits. It is also expected that the high level delegations will be larger than one bit, somewhere in the range of 4-16 bits, but at this point in time there is no guarantee that all delegations will take place on boundaries that are a multiple of 4. Thus in practice the number of labels in the reverse map is quite limited. This proposal encodes each label as a length followed by bit field, this differs from the previous RFC[RFC1886] in which reverse address labels were on nibble boundaries. 3. Inverse queries Inverse queries are performed by looking for DBIT (Delegated BITs) records in the IP6.INT domain. A DBIT record contains the last bit in the next delegation and a domain name that prefix is delegated to. The domain name of the DBIT record encodes the delegation hierarchy of the IPv6 address. The DBIT record is specially designed to allow distributed maintenance of the reverse mapping and to fit well with DNSSEC[RFC2065]. This draft requires all address allocation Gudmundsson Expires May 1998 [Page 3]
Internet-Draft ipngwg-dns-reverse-lookup-00.txt November 1997 authorities and network providers to maintain an accurate reflection of their delegations in the DBIT records. It is further assumed that the DBIT records are signed to protect the data contents[RFC2065]. 3.1 DBIT record type The DBIT resource record type is a new record specific to the Internet class that stores a single IPv6 address. The value of the type is TBD (decimal). 3.2 IP6.INT Domain A special domain is defined to look up a record given an address. The intent of this domain is to provide a way of mapping an IPv6 address to a host name, although it may be used for other purposes as well. The domain is rooted at IP6.INT. 3.2.1 Encoding of domain names for DBIT records Domain names in the IP6.INT. domain encode each label in the following way: +-----------------+------------------------------+ | number of bits | bit field padded from left | | (1 octet) | (variable, 0..128) | +-----------------+------------------------------+ Thus a full domain name can be expressed as follows: <bits><bitfield>.<bits><bitfield>*.IP6.INT. Length of bit field is the smallest number of octets that the <bits> bits can fit in, the bit field is right justified and padded from left if necessary with bits set to zero. Suppression of leading bytes with value of zero, MUST NOT take place. Each label corresponds to a delegation, each delegation is at least 1 bit. The labels are in the inverse order of delegation. The top level delegation is closest to the IP6 label and the lowest delegation is the left most. Gudmundsson Expires May 1998 [Page 4]
Internet-Draft ipngwg-dns-reverse-lookup-00.txt November 1997 Domain names in the IP6.INT. domain are BINARY values. (This can be changed to hex or base64 encoding but at significant cost in server processing overhead and name size.) Calculating how many bits have been delegated is done by adding up the first octet of all but the two right most labels (IP6.INT.). There is no direct mapping between IPv6 address such as 4321:0:1:2:3:4:567:89ab and an IP6.INT. name. The name depends on the delegations of address space. Section 3.6.2 describes how to support "dumb resolvers". 3.3 DBIT rdata format The data portion of the DBIT record contains two fields: +------------+---------------------+ | Last bit | Name delegated to | | (2 octets) | (variable, 1..256) | +------------+---------------------+ * The last bit in the next delegation. (Counted from the first bit in an IPv6 address.) Size of this field is set to 2 octets for compatibility reasons with similar records such as NS and MX. * the domain name of the authority to which the delegation size bits has been delegated to, encoded as a domain name. Name compression is not allowed. There are two special values that resolvers need to be aware of in the last bit field. Value of 128 delegates all remaining bits in the address. Value of 0 indicates that a host name is represented in the domain name. DBIT records in the IP6.INT. domain are self checking, so that records reflect correct delegation sizes. If a resolver has the whole chain of DBIT records from the IP6.INT. root, this allows the resolver to perform full verification of the delegations. Similarly if a resolver gets a random DBIT record it can derive which bits have been delegated and at which boundaries, from the domain name. Gudmundsson Expires May 1998 [Page 5]
Internet-Draft ipngwg-dns-reverse-lookup-00.txt November 1997 When a resolver gets a DBIT record with value 128 it sends the next DBIT query to a name in the zone defined in the name delegated field. This is done for the following reasons: * The same DBIT 0 record can be used for all routing prefixes of a site and to avoid resigning all DBIT 0 records at a site when prefixes change. * EID records at a site are random and do not reflect routing in any way. When a resolver gets a DBIT record with the value 0 it has reached the end. It can now verify all the responses. In all cases where the value of ``Last bit'' is greater than 0, there MUST be one and only one DBIT record. When the value of ``Last bit'' is 0 there MAY be multiple DBIT records, each reflecting different host name for that address. 3.4 DBIT query A DBIT query for a specified domain name in the Internet class returns all associated DBIT resource records in the answer section of a response. A successful DBIT query MAY contain the NS records for the domain name in the DBIT record in the additional data section and MAY contain the address records for these name servers in as well as the KEY record for the domain name[RFC2065]. 3.5 Textual presentation of DBIT records Textual encoding the binary names on the DBIT records can be accomplished in hex or base64, or using standard \nnn octet notation for each byte, this draft uses hex for clarity reasons. The textual representation of the data portion of the DBIT resource record used in a master database file is composed of two fields separated by white space: * last delegated bit as a decimal number, * a domain name. Gudmundsson Expires May 1998 [Page 6]
Internet-Draft ipngwg-dns-reverse-lookup-00.txt November 1997 3.6 Processing of inverse queries In the following section the word ``resolver'' is used to denote both DNS server and a smart DNS resolver that can process multiple DBIT records and verify that bindings are correct. A DNS resolver that does not understand or does not want to perform or know about DBIT processing is called a "dumb resolver". The DBIT request may result in one of the four following possibilities: * an error, either in RCODE or the answer does not contain a DBIT record. * the return of a DBIT record with delegation value of 1-127 * the return of a DBIT record with delegation value of 128. * the return of a DBIT record with delegation value of 0. In the first case the server is stating that the delegation requested does not exist. The second case is a valid delegation. The third case indicates that all remaining bits are delegated to the next level and the domain name should be queried about the remaining bits as EID. The fourth is the host name corresponding to the address. 3.6.1 Smart Resolver query A DNS server or Smart Resolver will walk the IP6.INT. delegation tree to find the correct DBIT records. It will start at the top of the IP6.INT. tree and work its way down the delegation tree. As an example, a find reverse mapping of the following address aa2f:34:1::3fff:1234 To find the top delegation in IP6.INT. the server for INT. is queried for IP6.INT. DBIT In this example the numbering authority is delegated 8 bits, thus the answer is: IP6.INT. DBIT 8 iana.org. Gudmundsson Expires May 1998 [Page 7]
Internet-Draft ipngwg-dns-reverse-lookup-00.txt November 1997 Resolver now encodes the top eight bits of the address into a name 08aa.IP6.INT. and queries the name server for iana.org. The answer is: 08aa.IP6.INT. DBIT 20 ripe.org. Now the resolver knows that the next 12 bits (bits 8-19) are delegated to ripe.org. Next query is sent to the name server for ripe.org. 0c2f0.08aa.IP6.INT. DBIT 32 isnet.is.example. and this is followed up with a query for 0c034.0c2f0.08aa.IP6.INT. DBIT 64 ismennt.is.example. and followed by a query for name 2000010000.0c034.0c2f0.08aa.IP6.INT. with answer: 2000010000.0c034.0c2f0.08aa.IP6.INT. DBIT 128 \ thorshofn.ismennt.is.example. As this is a delegation for all the remaining bits the query moved from the IP6.INT. domain and is issued for 40000000003fff1234. in the domain pointed to. Now query is issued for 40000000003fff1234.thorshofn.isment.is.example. with answer: 40000000003fff1234.thorshofn.isment.is.example. DBIT 0 \ sia.thorshofn.ismennt.is.example. 3.6.2 Dumb resolver query Resolver that that does not want to process DBIT query issues a query for 80aa2f003400010000000000003fff1234.IP6.INT. DNS Server that gets this in a query MUST know to break it down into components as defined in previous section. The DNS server returns back to the resolver an answer that is synthesized from the responses it got in the answer section. The server MUST return the relevant DBIT records and their signatures in the additional data section. Gudmundsson Expires May 1998 [Page 8]
Internet-Draft ipngwg-dns-reverse-lookup-00.txt November 1997 In the above example DBIT aware server would have returned in the answer section 80aa2f003400010000000000003fff1234.IP6.INT. DBIT 0 \ sia.thorshofn.ismennt.is.example. The answer SHOULD have contained in the additional data section the DBIT records used to derive this answer from, along with their signatures. In the example above the answer would have looked like IP6.INT. DBIT 8 iana.org. 08aa.IP6.INT. DBIT 20 ripe.org. 0c2f0.08aa.IP6.INT. DBIT 32 isnet.is.example. 0c034.0c2f0.08aa.IP6.INT. DBIT 64 ismennt.is.example. 2000010000.0c034.0c2f0.08aa.IP6.INT. DBIT 128 \ thorshofn.ismennt.is.example. 40000000003fff1234.thorshofn.isment.is.example. DBIT 0 \ sia.thorshofn.ismennt.is.example. If a DNS server receiving a dumb DBIT query is authoritative for part of the delegation or if it has DBIT records in its cache that provide prefix match it MAY start from the longest correct prefix DBIT record. For example if the above dumb query has been asked of ripe.org. or someone that had the 0c02f3.08aa.IP6.INT. DBIT record. In any case the resolver expects to get the 80..... DBIT 0 record back. 4. Security Considerations This proposal does not address security per se. Correct verifiable operation of this model assumes that DNSSEC will be used in the IP6.INT. tree and the leaf notes. If DNSSEC is not used, it is possible to get verifiable answers if secure transmission channels are used to ALL authoritative name servers queried and no data is retrieved from untrusted caching servers. In the absence of those two secured communication mechanisms DNS data can be spoofed. 5. Acknowledgments Many of the ideas here were developed during a discussion between the author, Jim Bound, and Bill Manning. Further evolution of the idea has been taken place in conversations with Robert Elz, Christian Huitema, Susan Thompson, and Karen Tracy. Gudmundsson Expires May 1998 [Page 9]
Internet-Draft ipngwg-dns-reverse-lookup-00.txt November 1997 6. References [RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,'' RFC 1034, ISI, November 1987. [RFC1035] P. Mockapetris, ``Domain Names - Implementation and Specification,'' RFC 1034, ISI, November 1987. [RFC1886] S. Thomson, Huitema, ``DNS Extensions to support IP version 6,'' RFC 1886, Bellcore, December 1995. [RFC2065] D. Eastlake , C Kaufman, ``Domain Name System Security Extensions,'' RFC 2065, CyberCash & Iris, January 1997. [RFC2119] S. Bradner, ``Key words for use in RFCs to Indi- cate Requirement Level,'' RFC 2119, Harvard, March 1997. [RFC2137] D. Eastlake 3rd, ``Secure Domain Name System Dynamic Update,'' CyberCash, April 1997. [RFC2181] R. Elz, R. Bush, ``Clarifications to the DNS Specification.'', RFC 2181, Univeristy of Mel- borne, RGnet, July 1997. [HD97] R. Hinden, S. Deering, ``IP Version 6 Addressing Architecture'', Internet Draft, draft-ietf- ipngwg-addr-arch-v2-05.txt, Ipsilon, Cisco. [HT97] C. Huitema, S. Thomson, ``DNS Extensions to sup- port IP version 6'', Internet Draft, draft-ietf- ipngwg-aaaa-00.txt, Bellcore. 7. Authors Address Olafur Gudmundsson Trusted Information Systems 3060 Washington Road, MD 21738 (301) 854-5700 (301)-854-5363 FAX. ogud@tis.com. Gudmundsson Expires May 1998 [Page 10]
