RFC 3597

RFC 3597 💖 Handling of Unknown DNS Resource Record (RR) Types 🎀

Okay bestie, this one is RFC 3597, written by A. Gustafsson of Nominum Inc. in September 2003. It's on the Standards Track 👑, so it's a real spec that implementers have to follow. It updates [RFC2163] and [RFC2535] (I'll explain why in Section 4 🙈). The header doesn't list anything it obsoletes.

---

Status of This Memo 📜

This document describes an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements. For the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈.

Copyright Notice ©️

Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract ✨

Right now, adding a new Resource Record (RR) type to the DNS means changing name server software 😭. This document lays out the changes needed so future DNS implementations can handle new RR types transparently 🦋.

1. Introduction 🌸

The DNS is built to be extensible, so it can support new services by adding new resource record (RR) types 💅. In practice though, deploying a new RR type means updating the name server software everywhere: not only on the authoritative DNS server providing the new info and the client using it, but also on all slave servers for the zone that holds it, and in some cases on caching name servers and forwarders the client uses too 💀.

Deploying new server software is slow and expensive, so the DNS has never really hit its full potential for new services 😤. This memo proposes changes to name servers, plus new procedures for defining RR types, to make deploying new RR types way easier later on 🫶.

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. Definition 🧚

An "RR of unknown type" is an RR whose RDATA format the DNS implementation doesn't know, and whose type isn't an assigned QTYPE or Meta-TYPE from [RFC 2929] (section 3.1). It also isn't in the range that section reserves for assignment only to QTYPEs and Meta-TYPEs. An RR like this can't be converted to a type-specific text format, compressed, or handled in any other type-specific way 🙈.

For a type whose RDATA format depends on the class, an RR counts as unknown type when the RDATA format for that particular combination of type and class isn't known 🍓.

3. Transparency 🔮

So new RR types can be deployed without server changes, name servers and resolvers MUST handle RRs of unknown type transparently 🦋. In other words, they have to treat the RDATA section of these RRs as unstructured binary data, storing and transmitting it without changing it [RFC1123] 💜.

Here's the tricky bit ✨. When an RR type is known to some servers but not others, equality comparison (section 6) and the DNSSEC canonical form (section 7) only keep working correctly if the RDATA is preserved exactly. So servers MUST also exactly preserve the RDATA of RRs of known type. The one exception is changes from compression or decompression that section 4 of this memo allows. Specifically, the character case of domain names that aren't subject to compression MUST be preserved 🫶.

4. Domain Name Compression 🗜️

RRs with compression pointers in their RDATA can't be treated transparently 😭. Compression pointers only make sense inside a particular DNS message. If you copied the RDATA into a new DNS message, the pointers would point at the same offsets in the new message, which now hold totally unrelated data 💀. That would corrupt the compressed name.

To avoid that corruption, servers MUST NOT compress domain names embedded in the RDATA of types that are class-specific or not well-known 🙅‍♀️. [RFC1123] stated this requirement but never defined "well-known", so this document settles it: only the RR types defined in [RFC1035] count as "well-known" 🎀.

A few existing RR types explicitly allowed compression, which goes against this spec. [RFC2163] said compression applies to the PX RR, and [RFC2535] allowed compression in SIG and NXT RRs. Since this specification disallows compression in those cases, it's an update to [RFC2163] (section 4) and [RFC2535] (sections 4.1.7 and 5.2). That's the update I mentioned at the top 💅.

Receiving servers MUST decompress domain names in RRs of well-known type 📦. They SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX, NXT, NAPTR, and SRV. The SRV note is a plot twist 🍿: [RFC2782] currently prohibits compression for SRV, but [RFC2052] mandated it, and some servers still running that earlier spec are out there ⭐.

Future specs for new RR types that contain domain names in their RDATA MUST NOT allow compression for those names 🚫. They SHOULD also explicitly state that the embedded domain names MUST NOT be compressed 📝.

As [RFC1123] noted, the owner name of an RR is always eligible for compression 🏷️.

---

To be continued in Part 2 🧚‍♀️ (Section 5 onward, with the Text Representation examples, Equality Comparison, DNSSEC Canonical Form, Additional Section Processing, IANA Considerations and Security Considerations).

11. Normative References ✨

okay bestie, these are the docs this whole RFC leans on, so you need them 📚

• [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987. 🧠
• [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specifications", STD 13, RFC 1035, November 1987. 🛠️
• [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989. 🖥️
• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔑 this is the one that makes the capital-letter words mean something
• [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. 🔐
• [RFC2163] Allocchio, C., "Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM)", RFC 2163, January 1998. 🗺️
• [RFC2929] Eastlake, D., Brunner-Williams, E. and B. Manning, "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929, September 2000. 📋

12. Informative References 💡

these ones are more like bonus reading, not required to implement anything 🧚

• [RFC1876] Davis, C., Vixie, P., Goodwin, T. and I. Dickinson, "A Means for Expressing Location Information in the Domain Name System", RFC 1876, January 1996. 📍
• [RFC2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996. 🌐
• [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. 🔄
• [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. 🛰️

13. Intellectual Property Statement 🔏

okay so the IETF is not picking a side here 🙅‍♀️ it takes no position on whether any intellectual property or other rights tied to the tech in this doc are valid or how far they reach, and it doesn't claim it went looking for any of them either. if you want the IETF's rules on rights for standards-track and standards-related docs, check BCP-11. copies of rights claims that were made available for publication, plus any promised licenses, or the results of trying to get a general license or permission for proprietary rights, can all be requested from the IETF Secretariat 📬

the IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to practice this standard. send that info to the IETF Executive Director 💌

14. Author's Address 📮

Andreas Gustafsson
Nominum, Inc.
2385 Bay Rd
Redwood City, CA 94063
USA

Phone: +1 650 381 6004
EMail: gson@nominum.com

15. Full Copyright Statement 💜

Copyright (C) The Internet Society (2003). All Rights Reserved.

okay the legal part, but make it cute 🎀 anyone can copy this doc and share it with others, and make derivative works that comment on or explain it or help with implementing it. you can prepare, copy, publish, and distribute those, in whole or in part, with no restrictions of any kind, as long as the copyright notice and this paragraph stay on every copy and derivative work. the doc itself, though, may not be modified in any way, like removing the copyright notice or references to the Internet Society or other Internet organizations. the exceptions are when you need it to develop Internet standards (then the Internet Standards process copyright procedures must be followed) or when you translate it into languages other than English 🌍

the limited permissions above are perpetual and the Internet Society or its successors or assignees won't revoke them ✨

and the disclaimer, which is a must-read: this document and the information in it 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. 🙈

Acknowledgement 🫶

funding for the RFC Editor function is currently provided by the Internet Society 🌸