[dns-operations] .edu domain algorithm recommendation
michael at rancid.berkeley.edu
Mon Aug 16 21:26:49 UTC 2010
On 08/16/10 14:00, Sue True wrote:
> I wonder what's the algorithm to use to generate keys? We have several
> top level .edu domains which are ready to get signed, I want to make
> sure the right algorithm is used, while check some of the singed .edu
> zones, the algorithms used are different, for example:
> internet2.edu: 7 RSASHA1-NSEC3-SHA1
> lsu.edu : 8 RSA/SHA-256
> penn.edu : 5 RSA/SHA-1
ucb.edu: 10 RSASHA512
ucberkeley.edu: 10 RSASHA512 (in the process of migrating)
berkeley.edu: will be 10 RSASHA512
> I am thinking to use Algorithm 7 to generate the keys, but on section
> 2.2 of this draft:
> 7 and 8 are both RECOMMENDED, only 5 is REQUIRED, is it safe to use just
> algorithm 7, and not 5?
> The Quickstart guide for .gov Zone seems to think that it's okay to use
> 7 alone.
First, you should make sure you fully understand the differences between
NSEC and NSEC3 and the implications thereof. It's probably a debatable
point, but NSEC3 is mainly useful for registries, where the opt-in
feature is important. If you want to prevent zone enumeration, you also
want NSEC3. I regard our DNS as a public database (like the phone
book), so I choose NSEC.
The other issue is the signing algorithm. Although there are
theoretical collisions in the SHA1 hash, actually exploiting these in a
DNSSEC environment would be sufficiently hard to make it not worth
The counterpoint is that algorithm rollovers are very, very tricky in
production, so you would want to make it less likely that you'll have to
roll over to a new algorithm, and start out with the most robust
algorithm that is implemented in a reasonable number of clients, *and*
is supported by the registrars and registry. EDUCAUSE is both the
registrar and registry for EDU and they support the following algorithms:
12:GOST R 34.10-2001
GOST is currently supported by fewer implementations, but algorithms 8
and 10 are supported by recent versions of BIND and unbound.
Further clouding the issue is that older versions of these DNS servers
may not support the algorithm and will treat your zone as insecure (but
not bogus, i.e. validation failure). In my case, I am actually okay
with only new clients being able to validate my zone as I put it into
production: It means fewer clients to break if there are any glitches as
we roll into production. That's probably hair-splitting, though.
Anyway, based on the logic above, I chose algorithm 10, but I suspect
there are plenty of alternative ways to look at it.
More information about the dns-operations