INTERNET-DRAFT Peter Koch Expires: August 2004 Universitaet Bielefeld Updates: RFC 3123 February 2004 Support for the DNS address family in the APL DNS RR draft-koch-dns-apl-domainname-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Although Domain Names are not addresses in a strict sense, they are sometimes used to describe a group of related or proximate systems in a network similar to address prefixes. This document extends [RFC3123] by specifying the address family dependent part for Domain Names to be used in the DNS APL resource record. 1. Conventions used in this document 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]. Domain Names herein are for explanatory purposes only and should not be expected to lead to useful information in real life [RFC2606]. 2. Background Koch Expires August 2004 [Page 1] INTERNET-DRAFT Domain Names in APL RR February 2004 Sytems on a network are sometimes grouped together by using an address prefix notation, meaning all addresses in a certain address range. This can be accomplished in the DNS with the APL RR [RFC3123], both for IPv4 and IPv6 addresses. Occasionally it is not network proximity that makes up a group. Systems may change their addresses often or they use addresses from different address range not efficiently aggregatable, but they live below the same DNS domain. Since IP addresses and Domain Names are orthogonal concepts, both methods need to be addressed. The APL resource record type is extendable. This document defines an additional address family dependent part for the DNS APL RR. 3. Address family dependent part for Domain Names The address family number for Domain Names registered by IANA is 16. An carrying a Domain Name therefore has an ADDRESSFAMILY value of 16. The PREFIX value defines how many levels of the DNS hierarchy are taken into account when matching any candidate Domain Name against the . It starts with 0 for the root domain, 1 for the top level, 2 for the second level etc. A match occurs if the candidate Domain Name is below or equal to the Domain Name in the AFDPART and the candidate domain consists of at most PREFIX labels. The PREFIX value SHOULD NOT be lower than the actual number of labels of the Domain Name in the AFDPART. Truly speaking the PREFIX really denotes a suffix length in the case of Domain Names. Since a Domain Name cannot consist of more than 127 labels, legal values for PREFIX range from 0 to 127. Note that the limit is 127 and not 63 (as would be implied by a maximum Domain Name length of 127). This is to allow maximum depth names even in those cases where a complete name would not fit into the AFDPART. 3.1. RDATA format The encoding of a Domain Name in the AFDPART follows the encoding specified in [RFC1035]. The Domain Name MUST NOT be compressed [DNSSEC and the handling of unknown RR types prohibit use of the standard global label compression algorithm.] and MUST be sent in lower case only. It MUST be terminated by a zero octet. The Domain Name in the AFDPART does not cause any additional section processing. Koch Expires August 2004 [Page 2] INTERNET-DRAFT Domain Names in APL RR February 2004 Since the AFDLENGTH parameter cannot carry values larger than 127, the length of the encoded form of the Domain Name is limited to 127. The minimum length is 1 (for the root domain encoded as a single zero octet). 3.2. Textual Representation of Domain Names A Domain Name in the
part of an is to be shown as a fully qualified Domain Name followed by the trailing dot. Absence of that dot in a zone file MUST lead to the current origin being appended to the name. The root domain is represented as a single dot. The has values from the interval 0..127 (decimal). A wildcard label may be used, although there is no need for it since subdomains are already covered by the PREFIX value if it is larger than the number of labels in the Domain Name. However, for DNSSEC [RFC2535] a single unambiguous wire encoding must be used. Therefore an application MUST NOT optimize away wildcard labels. 3.3. IDN Considerations The Domain Name in the AFDPART must be a true Domain Name, i.e. IDNs MUST be represented with ACE labels [RFC3490]. An application scenario may impose further restrictions on the Domain Name (e.g. hostname syntax). 4. Examples The following examples only illustrate some of the possible usages outlined in the previous section. None of those applications are hereby specified nor is it implied that any particular APL RR based application does exist now or will exist in the future. ; all the names in example.com except foo.example.com _all.example.com. IN APL 16:example.com./127 !16:foo.example.com./3 ; Mail Relay restrictions _relays.mail.example. IN APL 1:127.0.0.1/32 16:dhcp.example.org./127 ; all top level (only) domains tlds.example.org. IN APL 16:./1 5. Security Considerations All security considerations of [RFC3123] apply. In addition, if the Koch Expires August 2004 [Page 3] INTERNET-DRAFT Domain Names in APL RR February 2004 APL RR is used for access control or other purposes of authorization, questions of authenticity and integrity not only arise for the APL RR itself, but also for the Domain Name or Names carried in its payload. In particular one should not assume availability, integrity or consistency of DNS reverse mapping if that is the source of Domain Names to be matched against this newly introduced AFDPART. 6. IANA Considerations This section is to be interpreted as following [RFC2434]. This document does not define any new namespaces. It uses the 16 bit identifiers for address families maintained by IANA in http://www.iana.org/numbers.html. 7. References [RFC1034] Mockapetris,P., "Domain Names - Concepts and Facilities", RFC 1034, STD 13, November 1987 [RFC1035] Mockapetris,P., "Domain Names - Implementation and Specif- ication", RFC 1035, STD 13, November 1987 [RFC2119] Bradner,S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997 [RFC2181] Elz,R., Bush,R., "Clarifications to the DNS Specifica- tion", RFC 2181, July 1997 [RFC2434] Narten,T., Alvestrand,H., "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, BCP 26, October 1998 [RFC2606] Eastlake,D., Panitz,A., "Reserved Top Level DNS Names", RFC 2606, BCP 32, June 1999 [RFC3123] Koch,P., "A DNS RR Type for Lists of Address Prefixes (APL RR)", RFC 3123, June 2001 [RFC3490] Faltstrom,P., Hoffman,P., Costello,A., "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003 [RFC3597] Gustafsson,A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003 Koch Expires August 2004 [Page 4] INTERNET-DRAFT Domain Names in APL RR February 2004 8. Author's Address Peter Koch Universitaet Bielefeld Technische Fakultaet 33594 Bielefeld Germany +49 521 106 2902 Koch Expires August 2004 [Page 5]