[dns-operations] DNSSEC DS record generation for DOT-US from NSEC3 signed-zone

Anthony Iliopoulos ailiop at lsu.edu
Sat Aug 14 23:49:27 UTC 2010

On Sat, Aug 14, 2010 at 09:22:02PM +0000, bmanning at vacation.karoshi.com wrote:
> 	Don't ask Neustar to support something they don't.


>       Tell folks that want to validate your delegation to use the
>       DS record you publish - you can self publish or use a
>       reputation service like the ISC DLV.

While I agree in part with you (I am aware of the earlier discussion
concerning key rings, and transitive trust etc.), this not how dnssec
is supposed to operate (at least not only in this way). There needs to
be a seamless chain mode where one does not necessarily have to 
distribute or self-publish the DS, based on reputation (and I really
don't mean to resurrect the debate about trusting IANA versus trusting
the reputation-based system). 

Otherwise one could just distribute TSIG keys for everyone that wants
to validate his replies (surely the symmetric crypto overhead could be
sustained, if there are just a handful of folks interested in secure
dns data from your zones), and avoid engaging in the complexities of
the dnssec protocol. Or just load up your validator with the 20MB
trust-anchor.conf from secspider, no need for secure delegation chains,
if you don't really care about the reputation/trustworthiness part of it.

There's really nothing _additional_ to support, as far as the parent
goes. We all know that's just a number field in the protocol and
there is no extra server-side processing associated with accepting
additional algorithm numbers for the parent. There's no restriction
for the key-tag id of the ds record (granted it is within a valid range),
why should the algorithm number field be restricted ?

At most, a registry could do a dynamic check, before pushing your DS
into production, verifying that there actually exists a corresponding
dnssec key in the child, that matches the provided details, but other
than that one should be able to sign his zones with whatever algorithm
he chooses to.

The educause/verisign folks, were kind enough to support all of the
available registered algorithms for .EDU, shortly after our request for
RSA-SHA256. I would expect all dnssec-supporting registries/registrars
to eventually support all of the officially IANA-registered dnssec
algorithms in due course.


More information about the dns-operations mailing list