Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt

[Rob Austein <sra+namedroppers@hactrn.net>]

At 02 Jul 2002 13:42:26 -0400, Greg Hudson wrote:
> 
> I don't think application keys in DNS is "core DNSSEC functionality." 
> The core DNSSEC functionality is protecting existing DNS data (most
> importantly, name-to-address and address-to-name mappings).

Bingo.

> I have doubts that APPKEY is practical, by itself.  It seems that if you
> have many applications with keys at the same domain name, you will
> quickly exceed the EDNS0 UDP packet size limit and eventually exceed the
> hard 64K limit.

This is the so-called "subtyping problem".  In brief: conceptually, an
RRset is named by TYPE + NAME + CLASS, where "+" denotes (conceptual)
concatenation.  When such an RRset gets too big and all the RRs in
such an RRset are (conceptually) related, there's not much one can do
about it (this is part of the reason why MG RRs never caught on), but
when the RRs that make up such an RRset make up two or more
conceptually distinct groups that can only be identified by fetching
and examing the whole RRset (and, most likely, discarding the
irrelevant portions), it's the subtyping problem.

All the known ways of getting out of the subtyping problem involve
breaking the big RRset up into seperate RRsets by changing the
conceptual name (somehow).  The two common ways are either to use
separate TYPE codes or to use magic labels at the least significant
end of the NAME.  Which solution one prefers depends on how easy one
believes it is to add new TYPE codes to the DNS (opinions vary) and
how much one wishes to avoid using magic labels (opinions vary).

My understanding is that most (all?) of the folks proposing to use a
single APPKEY TYPE also propose to use the magic label approach.

--
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/>