Network Working Group P. Koch Internet-Draft Universitaet Bielefeld Updates: 3123 (if approved) August 12, 2004 Expires: February 10, 2005 Support for the DNS address family in the APL DNS RR draft-koch-dns-apl-domainname-01.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. This Internet-Draft will expire on February 10, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. 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. Koch Expires February 10, 2005 [Page 1] Internet-Draft Domain Names in APL RR August 2004 Table of Contents 1. Conventions used in this document . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Address family dependent part for Domain Names . . . . . . 3 2.2 RDATA format . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 Textual Representation of Domain Names . . . . . . . . . . 4 2.4 IDN Considerations . . . . . . . . . . . . . . . . . . . . 4 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 5 6.2 Informational References . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . 7 Koch Expires February 10, 2005 [Page 2] Internet-Draft Domain Names in APL RR August 2004 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 Systems on a network are sometimes grouped together 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 in 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. 2.1 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 a descendant of or equal to the Domain Name in the AFDPART and the candidate Domain Name 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 Koch Expires February 10, 2005 [Page 3] Internet-Draft Domain Names in APL RR August 2004 a complete name would not fit into the AFDPART. 2.2 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 [RFC2535] and the handling of unknown RR types [RFC3597] 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. 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). 2.3 Textual Representation of Domain Names A Domain Name in the address 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 prefix 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. 2.4 IDN Considerations The Domain Name in the AFDPART must be an old style Domain Name, i.e. IDNs MUST be represented with ACE labels [RFC3490]. That said, the Domain Name MUST follow hostname syntax [RFC2181]. An application scenario may impose further restrictions on the Domain Name (e.g. hostname syntax). 3. Examples The following examples only illustrate some of the possible usages outlined in the previous section. None of those applications are Koch Expires February 10, 2005 [Page 4] Internet-Draft Domain Names in APL RR August 2004 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 !16:./0 In these examples, "dhcp.example.org./127" matches everything below "dhcp.example.org" but also "dhcp.example.org" itself. Similarly, "16:./1" not only matches any single level domain, but also the root domain. The whole namespace is covered by "./127" and the root domain is described by "./0". 4. Security Considerations All security considerations of [RFC3123] apply. In addition, if the 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. 5. 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 . 6. References 6.1 Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. Koch Expires February 10, 2005 [Page 5] Internet-Draft Domain Names in APL RR August 2004 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999. [RFC3123] Koch, P., "A DNS RR Type for Lists of Address Prefixes (APL RR)", RFC 3123, June 2001. [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003. 6.2 Informational References [RFC3490] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003. Author's Address Peter Koch Universitaet Bielefeld Technische Fakultaet 33594 Bielefeld DE Phone: +49 521 106 2902 EMail: pk@TechFak.Uni-Bielefeld.DE Koch Expires February 10, 2005 [Page 6] Internet-Draft Domain Names in APL RR August 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Koch Expires February 10, 2005 [Page 7]