In message <d19c2f53.c0a7%edward.le...@icann.org>, Edward Lewis writes: > > On 6/9/15, 3:12, "Kevin Chen" <kc...@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: ma...@isc.org _______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
