draft-ietf-dnsext-unknown-rrs-03.txt   draft-ietf-dnsext-unknown-rrs-04.txt 
INTERNET-DRAFT Andreas Gustafsson INTERNET-DRAFT Andreas Gustafsson
draft-ietf-dnsext-unknown-rrs-03.txt Nominum Inc. draft-ietf-dnsext-unknown-rrs-04.txt Nominum Inc.
June 2002 September 2002
Handling of Unknown DNS RR Types Handling of Unknown DNS RR Types
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 33 skipping to change at page 2, line 33
combination of type and class is not known. combination of type and class is not known.
3. Transparency 3. Transparency
To enable new RR types to be deployed without server changes, name To enable new RR types to be deployed without server changes, name
servers and resolvers MUST handle RRs of unknown type transparently. servers and resolvers MUST handle RRs of unknown type transparently.
That is, they must treat the RDATA section of such RRs as That is, they must treat the RDATA section of such RRs as
unstructured binary data, storing and transmitting it without change unstructured binary data, storing and transmitting it without change
[RFC1123]. [RFC1123].
To ensure the correct operation of equality comparison (section 6)
and of the DNSSEC canonical form (section 7) when an RR type is known
to some but not all of the servers involved, servers MUST also
exactly preserve the RDATA of RRs of known type, except for changes
due to compression or decompression where allowed by section 4 of
this memo. In particular, the character case of domain names that
are not subject to compression MUST be preserved.
4. Domain Name Compression 4. Domain Name Compression
RRs containing compression pointers in the RDATA part cannot be RRs containing compression pointers in the RDATA part cannot be
treated transparently, as the compression pointers are only treated transparently, as the compression pointers are only
meaningful within the context of a DNS message. Transparently meaningful within the context of a DNS message. Transparently
copying the RDATA into a new DNS message would cause the compression copying the RDATA into a new DNS message would cause the compression
pointers to point at the corresponding location in the new message, pointers to point at the corresponding location in the new message,
which now contains unrelated data. This would cause the compressed which now contains unrelated data. This would cause the compressed
name to be corrupted. name to be corrupted.
skipping to change at page 5, line 6 skipping to change at page 5, line 15
7. DNSSEC Canonical Form and Ordering 7. DNSSEC Canonical Form and Ordering
DNSSEC [RFC2535] defines a canonical form and ordering for RRs. In DNSSEC [RFC2535] defines a canonical form and ordering for RRs. In
the canonical form, domain names embedded in the RDATA are converted the canonical form, domain names embedded in the RDATA are converted
to lower case. to lower case.
To ensure backwards compatibility, this canonical form remains To ensure backwards compatibility, this canonical form remains
unchanged for any RR types defined in RFC2931 or earlier. That is, 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, 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, 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 NAPTR, KX, SRV, DNAME, and A6 are converted to lower case according
other RR types, the canonical form is hereby changed such that no to the DNS rules for character comparisons.
downcasing of embedded domain names takes place. The owner name is
still set 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 always set to lower case according to the DNS rules for
character comparisons, regardless of the RR type.
The canonical ordering is as specified in RFC2535 section 8.3, where The canonical ordering is as specified in RFC2535 section 8.3, where
the octet sequence is the canonical form as revised by this the octet sequence is the canonical form as revised by this
specification. specification.
8. Additional Section Processing 8. Additional Section Processing
Unknown RR types cause no additional section processing. Future RR Unknown RR types cause no additional section processing. Future RR
type specifications MAY specify type-specific additional section type specifications MAY specify type-specific additional section
processing rules, but any such processing MUST be optional as it can processing rules, but any such processing MUST be optional as it can
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/