[dns-operations] DNSSEC issue - why?

Edward Lewis edward.lewis at icann.org
Tue Jun 9 09:55:58 UTC 2015


On 6/9/15, 3:12, "Kevin Chen" <kchen at mit.edu> wrote:

>>
>>which looks quite simple, however the KSK DNSKEY from hollington.ca is
>> part of the DS set. The only notable part of the DS set is that it
>> contains 4 keys, among which is an older (?) with a longer hash.
>
>RFC 4509 says:
>
>    Implementations MUST support the use of the SHA-256 algorithm in DS
>    RRs.  Validator implementations SHOULD ignore DS RRs containing SHA-1
>    digests if DS RRs with SHA-256 digests are present in the DS RRset.
>
>I assume the various resolvers are making different choices with regard
>to SHOULD.

Hmmm, I would have never interpreted that requirement that way.  I always
had in mind "per key."  FWIW, my provided recursive server (i.e., without
prodding I don't know the 'brand' of code) SERVFAILs when asked for keys.

For a long time I've been critical of how this RFC handles transitioning
from hash 1 to hash 2.  I've measured a selection of zones and their
choices, in particular whether they are hash 1, hash 2 or both.  At some
point the IETF ought to provide more guidance on whether hash 1 ought to
be abandoned by operators.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4604 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20150609/87a00dff/attachment.bin>


More information about the dns-operations mailing list