Handling of Unknown DNS Resource Record (RR) Types
updated by
- rfc-4033 — DNS Security Introduction and Requirements
- rfc-4034 — Resource Records for the DNS Security Extensions
- rfc-4035 — Protocol Modifications for the DNS Security Extensions
- rfc-5395 — Domain Name System (DNS) IANA Considerations
- rfc-6195 — Domain Name System (DNS) IANA Considerations
- rfc-6895 — Domain Name System (DNS) IANA Considerations
updates
Extracted elements (20)
Deploying a new RR type previously required changes to authoritative servers, slave servers, caching resolvers, and forwarders. This memo addresses the slow and expensive nature of DNS server software deployment by enabling transparent handling of unknown types without server changes.
Restricting name compression to only RFC 1035 well-known types is necessary because compression pointers are only meaningful within the context of a single DNS message; transparently copying compressed RDATA into a new message corrupts the compressed names by making pointers reference unrelated data.
The generic '\#' text encoding was introduced so that unknown RR types could be represented in master files portably. The same encoding is optionally available for known types, useful when a type's text format depends on a version field for which no text format exists (e.g., a LOC RR with VERSION != 0).
The inability to downcase embedded domain names in the DNSSEC canonical form for unknown types (which is necessary for signature correctness when compression loses case distinctions) is why the canonical form rule is split: pre-RFC 3597 types retain downcasing, while all newer types use no downcasing. This preserves interoperability with existing implementations.
Because equality comparison for unknown RR types is bitwise and case-sensitive for embedded domain names, it is possible to have multiple RRs of the same owner name differing only in the character case of embedded domain names in new RR types — similar to the existing possibility with TXT records.
The complete set of pre-RFC 3597 RR types containing embedded domain names whose DNSSEC canonical form involves downcasing are: NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINFO, MX, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV, DNAME, and A6. Implementors should apply downcasing only to these types.
This specification updates RFC 2163 (section 4) and RFC 2535 (sections 4.1.7 and 5.2) by disallowing compression in PX, SIG, and NXT RRs, overriding those earlier specifications that explicitly permitted it.
Even though an RR of known type represented in the '\#' generic format is parsed as an unknown type, all further processing by the server MUST treat it as a known type and apply applicable type-specific rules regarding compression, canonicalization, etc.
For all RR types whose initial RFC publication was prior to RFC 3597, the DNSSEC canonical form remains unchanged (downcasing of embedded domain names applies). For all other RR types, the canonical form involves no downcasing of embedded domain names.
Future specifications for new RR types containing domain names within their RDATA MUST NOT allow name compression for those names, and SHOULD explicitly state that embedded domain names MUST NOT be compressed.
Name servers and resolvers MUST handle RRs of unknown type transparently, treating the RDATA section as unstructured binary data and storing and transmitting it without change.
Receiving servers MUST decompress domain names in RRs of well-known type (RFC 1035 types), and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX, NXT, NAPTR, and SRV.
Servers MUST exactly preserve the RDATA of RRs of known type (except for permitted compression/decompression changes) to ensure correct equality comparison and DNSSEC canonical form when an RR type is known to some but not all servers. In particular, the character case of domain names not subject to compression MUST be preserved.
Servers MUST NOT compress domain names embedded in the RDATA of types that are class-specific or not well-known. Only the RR types defined in RFC 1035 are considered 'well-known' for this purpose.
Specifications for new RR types MUST NOT specify type-specific comparison rules. Two RRs of the same unknown type are considered equal when their RDATA is bitwise equal, ensuring comparison outcome is identical whether or not the server knows the type.
The owner name of an RR is always set to lower case for DNSSEC canonical form regardless of RR type, while the DNSSEC canonical RR ordering follows RFC 2535 section 8.3 using the canonical form as revised by this specification.
Unknown RR types cause no additional section processing. Future RR type specifications MAY specify type-specific additional section processing rules, but any such processing MUST be optional since it can only be performed by servers that know the RR type.
An 'RR of unknown type' is an RR whose RDATA format is not known to the DNS implementation, and whose type is not an assigned QTYPE or Meta-TYPE per RFC 2929 section 3.1, nor within the range reserved for those. For class-specific RDATA formats, an RR is unknown when the combination of type and class is not known.
This specification is not believed to cause any new security problems, nor to solve any existing ones. The transparent handling of unknown RR types treats their RDATA as opaque binary data, which does not introduce new attack surfaces.
Unknown RR type text representation uses 'TYPE' immediately followed by the decimal type number (no whitespace) in the type field, and 'CLASS' followed by the decimal class number in the class field. The RDATA is encoded as the special token '\#', an unsigned decimal integer for the RDATA length in octets, and zero or more whitespace-separated hexadecimal words each with an even number of hex digits.