Network Working Group A. Main Internet-Draft: draft-main-addr-dns-rep-00 Black Ops Ltd Category: Informational May 2003 Expires: November 2003 Mapping Network Addresseses into Domain Name Space Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract Several network protocols and applications need to perform a DNS lookup using a network address, rather than a host or service name, as (part of) the key. This document provides a technique to map network protocol addresses into domain names for the purposes of such applications. 1 Introduction From very early on, the DNS has supported a mapping of IP addresses into domain names, under the in-addr.arpa domain, for the purposes of address-to-host-name (`reverse') lookups [DNS-SPEC]. The same mapping was also overloaded to provide DNS-based lookup of inter- network gateways in the classful Internet, but that usage is now obsolete. There has also been work on representing other information, such as network names and subnet masks [NET-DNS], in the same space. Main expires November 2003 [Page 1] Internet-Draft Network Addresses as Domain Names May 2003 In recent years, other applications have been developed that require a similar address-to-domain-name mapping. Several organisations maintain blacklists of IP addresses that are open email relays, or are dynamically assigned to dialup users, or are known to emit unsolicited bulk email, and so on; the DNS is a convenient way for these organisations to publish such lists, because it makes it easy for clients to perform individual lookups, and the DNS infrastructure provides useful caching capabilities. This type of blacklist facility has usually used the same form of address-to-domain-name mapping that is used under in-addr.arpa. With the development of IPv6, in-addr.arpa has now been joined by ip6.arpa ([DNS-IPV6] and [IP6-ARPA]), which provides the same address-to-host-name mapping for IPv6 addresses. [E164-DNS] added e164.arpa, mapping in E.164 addresses to provide service identification. Protocol-address-to-domain-name mapping is obviously a useful technique for many applications. It is occurring in increasingly many areas of the domain name space, and for increasingly many types of address. This document specifies how applications should perform address-to-domain-name mapping, and in particular how to handle multiple address types, in order to avoid unnecessary dependence of application protocols on a single network protocol. 2 Mapping Network Addresseses into Domain Name Space The domain naming scheme described in this section is to be used when an application protocol calls for it. This document does not specify any particular protocol in which this scheme is to be used. It is assumed that all parties to the protocol are aware in advance, through either protocol specification or a prior exchange of messages, of a domain name at which the address mapping tree is to be rooted. This domain name will be referred to as "". (For advice on the case where the existence of the address mapping tree is in question, see section 4.) Each network protocol address of interest is mapped into a domain name of the form .. where "" is a single domain name label indicating the type of address (e.g., IPv4 or IPv6) and "" is a type-specific encoding of the address as a sequence of domain name labels. Note that by explicitly encoding the type of address being represented the encoding scheme is rendered open-ended, so new types Main expires November 2003 [Page 2] Internet-Draft Network Addresses as Domain Names May 2003 of address, for network protocols that were previously not of interest, can be handled without changing the mapping scheme. The labels used in this scheme are identical to those used directly under the arpa domain to identify address types there. For example, there is "in-addr" for IPv4 addresses and "ip6" for IPv6 addresses. The type-specific address encodings are then identical to those used under the corresponding "arpa" domain. Essentially, the protocol-specific domain clones the layout of the arpa infrastructure domain, making its layout familiar and unsurprising to DNS administrators. The resource records to be stored at each domain name that is the mapping of an address into domain name space are not governed by this mapping scheme. The form and meaning of such records is to be determined by the protocol that specifies the use of this mapping. However, see section 4 for discussion of an issue that may affect design choices in this area. To avoid excessively burdening DNS administrators for whom wildcard records may be convenient in populating an address mapping tree, data stored at interior tree nodes that do not represent a mapped address should be ignored. 3 Currently Defined Address Types The arpa domain currently contains three address mapping domains. The labels thus defined are "in-addr" for IPv4 addresses, "ip6" for IPv6 addresses, and "e164" for E.164 (telephone) numbers. The in-addr.arpa domain for IPv4 address mapping is defined by [DNS- SPEC]. The address encoding that exists under in-addr.arpa, and hence under "in-addr" labels in the mapping scheme in this document, starts with the 32-bit address being divided into four octets. Each octet is represented in decimal, with leading zeroes suppressed. The four decimal octet values then form four labels, most-significant octet being represented by the most-significant label, so in the conventional little-endian order for representing domain names the octets appear reversed relative to the conventional big-endian order for representing IPv4 addresses. The ip6.arpa domain for IPv6 address mapping is defined by [DNS-IPV6] (which gives the address encoding scheme) and [IP6-ARPA] (which roots the address mapping tree at ip6.arpa). The 128-bit address is divided into 32 4-bit nybbles, each of which is represented as a label consisting of a single hexadecimal digit. The 32 single- character labels are used, similarly to the four labels for IPv4, with most-significant nybble represented by the most-significant label. Main expires November 2003 [Page 3] Internet-Draft Network Addresses as Domain Names May 2003 e164.arpa is specified by [E164-DNS]. It specifies an encoding in which each digit of the E.164 number is encoded as a single-character label, and the labels are used in order with the most-significant E.164 digit represented by the most-significant label. Internet standards that create new address-mapping domains under the arpa domain should be interpreted as also defining the corresponding label and address encoding scheme for the scheme described in section 2 of this document; no explicit addition to this document is required in such cases. Note that non-address-mapping domains can also exist under arpa, such as the existing uri.arpa and urn.arpa domains for URI resolution. 4 Wildcard Problem A great advantage of this address-to-domain-name mapping scheme is that records keyed by address can be looked up with a single DNS lookup. A corresponding weakness, however, is that the lookup does not positively confirm the existence of an address mapping tree in the expected place. For most applications using this technique that is not a problem, because the existence and location of the tree is determined either by the protocol specification or by a prior phase of the protocol. There are some protocols, however, where the existence of an address mapping tree at a particular location is merely a possibility; the provision of the tree may be an optional part of a protocol. In the case where an optional address mapping tree has not in fact been created, it is possible that resource records would appear at the same domain names, due to a wildcard record at a higher domain name. For example, a wildcard address record at *.example.com could be returned in response to a query for address records at 1.0.0.10.in-addr._foo.bar.example.com. This might be indistinguishable from "foo" protocol data attached to the IPv4 address 10.0.0.1 and the domain name bar.example.com. It is usually possible to have some additional sub-protocol to confirm the existence of an address mapping tree. For example, an application protocol could require that the root domain of the address mapping tree carry a distinctive resource record, such as a TXT record containing the protocol's name. However, this requires an extra DNS lookup, or some other extra protocol step. This need can be avoided by instead ensuring that protocol data stored at the leaves of the address mapping tree is in all cases sufficiently distinctive. A wildcard record covering the entire address mapping tree can be used to provide a distinctive result meaning "participating in the protocol but no data at this leaf". Main expires November 2003 [Page 4] Internet-Draft Network Addresses as Domain Names May 2003 5 Security Considerations This technique for representing network addresses as domain names raises no security issues that are not inherent in such a mapping. Each application that uses this technique must consider the security implications of permitting such a mapping and of using the DNS to store and distribute information. The use of DNSSEC to authenticate DNS data is recommended. 6 Acknowledgements The details of the protocol specification in section 2 came from a discussion between Gordon Fecyk and the author of this document. The wildcard problem discussed in section 4 was pointed out by der Mouse. 7 Normative References [DNS-IPV6] S. Thomson, C. Huitema, "DNS Extensions to support IP version 6", RFC 1886, December 1995. [DNS-SPEC] P.V. Mockapetris, "Domain names - implementation and specification", STD 13, RFC 1035, Nov-01-1987. [E164-DNS] P. Faltstrom, "E.164 number and DNS", RFC 2916, September 2000. [IP6-ARPA] R. Bush, "Delegation of IP6.ARPA", BCP 49, RFC 3152, August 2001. 8 Informative References [NET-DNS] P.V. Mockapetris, "DNS encoding of network names and other types", RFC 1101, Apr-01-1989. 9 Author's Address Andrew Main Black Ops Ltd 12 Montagu Mews South London W1H 7ER United Kingdom Phone: +44 7887 945779 EMail: zefram@fysh.org Main expires November 2003 [Page 5]