Subject: Handling of Unknown DNS RR Types

From: Edward Lewis <[email-masked]>
Date: Fri, 25 Oct 2002 10:45:16 -0400

In section 4 and section 7 the subject of domain name treatment in 
the RDATA pops up.  In the section 4 the context is message 
compression, in section 7 the context is DNSSEC processing.

The two paragraphs treat the list of considered types differently. 
In Section 4, there's a reference to 1035-defined types plus a list 
of newer ones.  In section 7, the entire list is explicit.  The lists 
aren't the same - e.g., A6 and DNAME are in section 7 and not 4. 
(Perhaps for good reason.)  HINFO appears in the section 7 list twice.

Is there a need to mention which types are class agnostic and which 
are class "IN" only?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: [email-masked] (Andreas Gustafsson)
Date: Fri, 25 Oct 2002 11:24:10 -0700 (PDT)

Edward Lewis writes:
> (Perhaps for good reason.)

Yes, this is deliberate and stems from the fact that the
interoperability issues of compression and DNSSEC canonicalization are
fundamentally different.

With compression, you can take a "be conservative in what you send and
liberal in what you receive" approach, since there is no harm in the
receiving party supporting decompression of more record types than the
sending party will compress.  The draft takes advantage of this to
maximize interoperability, by allowing compression only of record
types that existing servers are known to be able to decompress, and by
recommending that servers be capable of decompressing all types that
existing servers are known to compress (whether that compression is
considered correct or not).

In DNSSEC processing, on the other hand, the two parties must agree
exactly on which types are subject to downcasing and which are not;
anything else will cause signature validation to fail.  This means
there has to be a flag day, and to maximize interoperability, that
flag day should be such that the downcasing rules for RR types that
have already been deployed do not change.  Therefore, the draft makes
the set of RR types subject to downcasing as large as possible given
the state of standardization at the time of the draft's initial
publication, using RFC2931 as the flag day.

> HINFO appears in the section 7 list twice.

That's a typo - thanks for pointing it out.

> Is there a need to mention which types are class agnostic and which 

I don't think the unknown-rrs draft is the right place to do that.
This is already part of the specification of each individual RR type,
which an implementor must already be familiar with to correctly
implement the type, and duplicating this information in the
unknown-rrs draft would introduce a risk of inconsistency.
-- 
Andreas Gustafsson, [email-masked]