[dns-operations] DNSSEC issue - why?

[Mark Andrews]

In message <D19C2F53.C0A7%edward.lewis at icann.org>, Edward Lewis writes:
> 
> 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.

How could it be done "per key"?  keyid's don't identify a key.  They
identify a set of 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.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org