Automatic key verification / CERT in DNS / RFC4398 (Was: [Announce] GnuPG 1.4.3 released)

[Jeroen Massar]

On Wed, 2006-04-05 at 10:58 -0400, Ólafur Guðmundsson /DNSEXT co-chair
wrote:
> At 07:57 05/04/2006, Jeroen Massar wrote:
> >On Wed, 2006-04-05 at 02:17 -0500, Brad Knowles wrote:
> > > At 10:28 PM -0400 2006-04-04, Danny Mayer wrote:
> 
> Please remove namedroppers from future postings on this tread.
> I'm not approving any messages as the discussion is about possible
> DNS operational issues, not DNS protocol issues.

The discussion which led from it is indeed, but my original question,
though at the bottom of the mail was:

8<--------------------------------------------
This all though leads to a concern on the placing of the CERTS. Having a
large user base would mean that one has say 600k records or more in the
main zone for a domain, which gets reloaded every now and then when one
needs to update it. It would IMHO be better to be able to off load those
records to say _cert.example.org. Which has several benefits, one can
then run their normal DNS adminstration and delegate the CERT records to
a dedicated DNS server set which can handle the updates easier or simply
runs out of a DNSBackend. This will also be easier management wise with
DNSSEC I expect and remove the strain from the main boxes, which
currently might have maybe upto 100 RR's on average in a zone,
especially in the case of webhosting farms where one only specifies the
www.example.org and nothing else.
------------------------------------------->8

Altough this is also more or less an operational question, the question
is very related to dnsext as the CERT record has been defined here and
RFC4398 defines that person CERT's can be found under
<user>.example.org.

This was the point I wanted to clear up, that, indeed for ops purposes,
one rather have a subzone. This is again a protocol related thing as
when one sticks all the CERTs in the main zone, this will grow and you
will have to take into account keyrotation for DNSSEC...

If I am totally of base, then simply drop the discussion of course.

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: This is a digitally signed message part
Url : /pipermail/attachments/20060405/de4e2de7/attachment.pgp