Re: draft-ietf-dnsext-unknown-rrs-04.txt

[gson@nominum.com (Andreas Gustafsson)]

Erik Nordmark writes:
> > Yes.  RFC2065 explicitly allowed compression of names in SIG and NXT
> > records, and this is no longer allowed per the unknown-RRs draft.
> 
> But this isn't consistent with draft-ietf-dnsext-dnssec-records-02.txt
> which allows compression of SIG and NXT.

Right.  draft-ietf-dnsext-dnssec-records needs to be fixed.

> > >    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.
> > > 
> > > It would be useful to explicitly list the RR types to which this change
> > > applies.
> > 
> > That's not really practical since there is more than 65000 of them.
> > While you could attempt to list the currently allocated post-RFC2915
> > types, such a list would soon become inaccurate as additional types
> > are allocated.
> 
> I wasn't asking about listing all current and potential future RRs.
> I'm asking about a specification of what "hereby changed" actually
> means for an implementor. Being able to list the RRs which are subject
> to this change seems like a requirement. If you don't have the list
> how can we guage the impact of this change?

An implementor can construct this list for any given implementation by
finding all RR types the implementation knows about and determining
which ones were defined in an RFC later than RFC2931 (the "2915" in
the quoted text above is a typo and should be "2931" as in the draft).
This will always yield a complete and up-to-date list, unlike any
fixed list that could be embedded in the draft.

Assuming the list of RR type assignments at
<http://www.iana.org/assignments/dns-parameters> is complete, there is
currently exactly one post-RFC2931 RR type, the APL record defined in
RFC3123, but the APL RR does not contain any embedded domain names and
is therefore unaffected by the canonicalization change.  In other
words, the impact of this change on existing implementations is zero.
-- 
Andreas Gustafsson, gson@nominum.com

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