Subject: Re: [Design] Re: the KEY debate

From: Rob Austein <[email-masked]>
Date: Mon, 05 Aug 2002 13:25:58 -0400

At Sun, 04 Aug 2002 23:58:04 -0400, Michael Richardson wrote:
> 
>     Rob> Sorry, wrong.  (a) it removes the need for DNSSEC-aware resolvers to
>     Rob> sift through RRsets picking out individual keys by subtype codes, and
>     Rob> (b) it reduces the chances that KEY RRsets will be large enough to
>     Rob> trigger DNS message truncation and fallback to TCP.
> 
>   This argument is valid for KEYs at zone APEX only. 
>   DNSSEC only ever cares about KEYs that that point anyway.
> 
>   As I have said several times, there is likely little reason to ever have
> non-DNSSEC keys there. The only use is seeminly web servers, and the
> limitations on HTTPS for virtual hosting means that a single IP can not
> serve both both https://www.example.com and https://example.com. 
>   As such, it is very unlikely that such a KEY record would be placed.

Your analysis depends on simplifying assumptions about the location of
the zone cuts.  Not everyone agrees with your assumptions.

>   If we introduce a new RR for each use, then we can also solve the problem.
>   I prefer to introduce a new RR for each use. 

Oddly enough, we are in agreement on this.  I've been advocating using
separate RR types for this purpose for years now.  The usual
counter-argument is that it takes too long to deploy new RR types.  In
theory the recent work on how DNS implementations should handle
unrecognized RR types helps here; in practice, well, we'll see.

I don't have any particular attachment to the current KEY RR type
either, and strictly from a protocol standpoint I suspect that it'd be
better to dump it and use a new RR type for DNSSEC's own keys as well,
with (at least) the subtype field removed from the RDATA of the new
type (fields that don't exist doesn't have to be checked, and can't
turn into the sort of mess that ECN did).  From a practical
standpoint, I don't think it's worth delaying DNSSEC deployment just
for this change, which is why I haven't made noise about it.

--
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: Dan Massey <[email-masked]>
Date: Mon, 05 Aug 2002 14:16:44 -0400

> for this change, which is why I haven't made noise about it.

This is a good point.  In the restrict key form, the KEY record has a
protocol octet that must be 3.  In addition, there are 2 flag octets where
only bit 7 is used.   This is a somewhat odd structure at best.and
someone starting from scratch would clearly not do this.

But it accomplishes the objective with minimal changes and without
creating any compatability problems for existing zone keys.  In my view,
the practical issues of making minimal compatible changes and not futher
delaying DNSSEC trumps the desire to further optimize structure.

Dan