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

[Robert Elz <kre@munnari.OZ.AU>]

    Date:        Wed, 12 Dec 2001 16:51:54 -0500
    From:        Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>
    Message-ID:  <200112122151.fBCLptO00340@syn.hamachi.org>

  | One *could* use naming conventions like the ones used with SRV records
  | to move the keys away from the name uttered by the user..

One could, but one certainly should not.

It is becoming clear to me that putting application keys in the DNS
is simply the wrong solution.

Attempting to do it in the simple way causes packet size problems.

Attempts to avoid that by bending the namespace (aside from being obscene
to begin with) causes problems later if the desire is to have more that
one app share the same key - there's no way in the DNS for two different
names to have the same RDATA, short of duplication or CNAMES.   Duplication
(especially of large data that might need to be duplicated very many times)
causes zone size blowout, and dramatically reduces the effectiveness of
caching.  And I'm not sure I would want to rely an awful lot on a KEY that
was fetched from some random location after following a CNAME (and even
then, the CNAME is extra data to have to store and send around - even if
it would typically be much smaller than a key).

And it seems that no-one wants to propose a separate RR type for every
different application (which would have the same data size problems as
bending the namespace, if not the same mangling of the DNS namespace).

Just design a new protocol and be done with it - it doesn't need to be
very complex, it can start with security mandated in it so the key
can really be trusted ...   By all means define a new DNS RR (or use the
SRV RR) to allow apps to locate the key server for a domain (and note:
a domain includes any DNS label).

Just keep anything other than the keys needed for the DNS itself out
of the DNS (and I'm not sure even those shouldn't be moved).

kre



to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.