diff --git a/doc/draft/draft-ietf-dnsext-unknown-rrs-00.txt b/doc/draft/draft-ietf-dnsext-unknown-rrs-00.txt new file mode 100644 index 0000000000..6c5cc994c3 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-unknown-rrs-00.txt @@ -0,0 +1,333 @@ +INTERNET-DRAFT Andreas Gustafsson +draft-ietf-dnsext-unknown-rrs-00.txt Nominum Inc. + November 2000 + + + Handling of Unknown DNS RR Types + + +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 + + Extending the Domain Name System with new Resource Record types + currently requires changes to name server software. This document + specifies the changes necessary to allow future DNS implementations + to handle new RR types transparently. + +1. Introduction + + The DNS is designed to be extensible to support new services through + the introduction of new resource record (RR) types. In practice, + deploying a new RR type currently requires changes to the name server + software not only at the authoritative DNS server that is providing + the new information and the client making use of it, but also at all + slave servers for the zone containing it, and in some cases also at + caching name servers and forwarders used by the client. + + Because the deployment of new server software is slow and expensive, + the potential of the DNS in supporting new services has never been + + + +Expires May 2001 [Page 1] + +draft-ietf-dnsext-unknown-rrs-00.txt November 2000 + + + fully realized. This memo proposes changes to name servers and to + procedures for defining new RR types aimed at simplifying the future + deployment of new RR types. + + 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 [RFC 2119]. + +2. Definitions + + In this document, a "well known" RR type means one defined in + RFC1035. + + An "RR of unknown type" is an RR type whose RDATA format is not known + to the DNS implementation at hand, and which therefore cannot be + converted to a type-specific text format, compressed, or otherwise + handled in any type-specific way. This includes the case where the + RR's type is recognized but its RDATA format is class specific and + the RR is of a class for which the format is not known. + +3. Transparency + + To enable new RR types to be deployed without server changes, name + servers and resolvers MUST handle RRs of unknown type transparently. + That is, they must treat the RDATA section of such RRs as + unstructured binary data, storing and transmitting it without change. + +4. Domain Name Compression + + RRs containing compression pointers in the RDATA part cannot be + treated transparently, as the compression pointers are only + meaningful within the context of a DNS message. Transparently + copying the RDATA into a new DNS message would cause the compression + pointers to point at the corresponding location in the new message, + which now contains unrelated data. This would cause the compressed + name to be corrupted. + + To avoid such corruption, servers MUST NOT compress domain names + embedded in the RDATA of types that are not well known. + + Receiving servers MUST decompress domain names in RRs of well-known + type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX, + NXT, NAPTR, and SRV (although the SRV RR is clearly defined to not + allow compression of the target field, some existing name servers + compress it anyway). + + Future specifications for new RR types that contain domain names + within their RDATA MUST NOT allow the use of name compression for + + + +Expires May 2001 [Page 2] + +draft-ietf-dnsext-unknown-rrs-00.txt November 2000 + + + those names, and SHOULD explicitly state that the embedded domain + names MUST NOT be compressed. + +5. Text Representation + + In the "type" field of a master file line, an unknown RR type is + represented by the word "TYPE" immediately followed by the decimal RR + type number, with no intervening whitespace. In the "class" field, + an unknown class is similarly represented as the word "CLASS" + immediately followed by the decimal class number. + + This convention allows types and classes to be distinguished from + each other and from TTL values, allowing the "[] [] + " and "[] [] " forms of + RFC1035 to both be unambiguously parsed. + + The RDATA section of an RR of unknown type is represented as a + sequence of white space separated words as follows: + + The special token \# (a backslash immediately + followed by a hash sign), which identifies the + RDATA as having the generic encoding defined + herein rather than a traditional type-specific + encoding. + + An unsigned decimal integer specifying the + RDATA length in octets. + + Zero or more words of hexadecimal data encoding + the actual RDATA field, each containing an even + number of hexadecimal digits. + + If the RDATA is of zero length, the text representation contains only + the \# token and the single zero representing the length. + + An implementation MAY also choose to represent some RRs of known type + using the above generic representations for the type, class and/or + RDATA, which carries the benefit of making the resulting master file + portable to servers where these types are unknown. + + Even though an RR of known type represented in the \# format is + effectively treated as an unknown type for the purpose of parsing the + RDATA text representation, all further processing by the server MUST + treat it as a known type and take into account any applicable type- + specific rules regarding compression, canonicalization, etc. + + The following are examples of RRs represented in this manner, + illustrating various combinations of generic and type-specific + + + +Expires May 2001 [Page 3] + +draft-ietf-dnsext-unknown-rrs-00.txt November 2000 + + + encodings for the different fields of the master file format: + + a.example. CLASS32 TYPE731 \# 6 abcd ( + ef 01 23 45 ) + b.example. HS TYPE62347 \# 0 + e.example. IN A \# 4 0A000001 + e.example. CLASS1 TYPE1 10.0.0.2 + +6. Equality Comparison + + Certain DNS protocols, notably Dynamic Update [RFC2136], require RRs + to be compared for equality. Two RRs of the same unknown type are + considered equal when their RDATA is bitwise equal. To ensure that + the outcome of the comparison is identical whether the RR is known to + the server or not, specifications for new RR types MUST NOT specify + type-specific comparison rules. + + This implies that embedded domain names, being included in the + overall bitwise comparison, are compared in a case-sensitive manner. + As a result, when a new RR type contains one or more embedded domain + names, it is possible to have multiple RRs owned by the same name + that differ only in the character case of the embedded domain + name(s). This is similar to the existing possibility of multiple TXT + records differing only in character case, and not expected to cause + any problems in practice. + +7. DNSSEC Canonical Form and Ordering + + DNSSEC [RFC2535] defines a canonical form and ordering for RRs. In + the canonical form, domain names embedded in the RDATA are converted + to lower case. + + To ensure backwards compatilbility, this canonical form remains + unchanged for any RR types defined in RFC2931 or earlier. That is, + the domain names embedded in RRs of type NS, MD, MF, CNAME, SOA, MB, + MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, + NAPTR, KX, SRV, DNAME, and A6 are converted to lower case. For all + other RR types, the canonical form is hereby changed such that no + downcasing of embedded domain names takes place. The owner name is + still set to lower case. + + The canonical ordering is as specified in RFC2535 section 8.3, where + the octet sequence is the canonical form as revised by this + specification. + +8. Additional Section Processing + + Unknown RR types cause no additional section processing. Future RR + + + +Expires May 2001 [Page 4] + +draft-ietf-dnsext-unknown-rrs-00.txt November 2000 + + + type specifications MAY specify type-specific additional section + processing rules, but any such processing MUST be optional as it can + only be performed by servers for which the RR type in case is known. + + 9. IANA Considerations + + The IANA is hereby requested to verify that specifications for new RR + types requesting an RR type number comply with this specification. + In particular, the IANA MUST NOT assign numbers to RR types whose + specification allows embedded domain names to be compressed. + + 10. Security Considerations + + This specification is not believed to cause any new security + problems, nor to solve any existing ones. + +References + + [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, + November 1987. + + [RFC1035] - Domain Names - Implementation and Specifications, P. + Mockapetris, November 1987. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE). P. + Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April 1997. + + [RFC2535] Domain Name System Security Extensions. D. Eastlake. March + 1999. + +Author's Address + + Andreas Gustafsson + Nominum Inc. + 950 Charter Street + Redwood City, CA 94063 + USA + + Phone: +1 650 779 6004 + + Email: Andreas.Gustafsson@nominum.com + + +Full Copyright Statement + + + + +Expires May 2001 [Page 5] + +draft-ietf-dnsext-unknown-rrs-00.txt November 2000 + + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implmentation may be prepared, copied, published and + distributed, in whole or in part, without restriction of any kind, + provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS 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." + + + + + + + + + + + + + + + + + + + + + + + + + + +Expires May 2001 [Page 6] +