If you perform DNSSEC validation on your resolver you may have noticed lots of validation failures for the .us top-level domain since yesterday or early today (depending on the content of your cache). You’re probably wondering why this happens and what you can do about. Here’s a short explanation.

The maintainers of the .us domain seem to be working on an algorithm rollover from RSASHA1 to RSASHA256 (the signing algorithm used to sign resource records in the zone). To that end, they have introduced a new KSK yesterday with algorithm 8 (RSASHA256).

So far so good, right? Or is it? Well, it turns out that introducing this key has an unexpected side-effect. Section 2.2 of RFC 4035 states :

‘There MUST be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset itself MUST be signed by each algorithm appearing in the DS RRset located at the delegating parent (if any).‘.

Now what does this complicated statement mean?

Well, in effect, it means that all RRsets must be signed using all algorithms available in the DNSKEY RRset. Furthermore, the DNSKEY RRset itself must be signed by all the algorithms specified in the DS set in the parent zone.

The result is that if you want to perform an algorithm rollover you need to be very careful. Luckily, the folks at the IETF have provided an RFC with DNSSEC best practices that describes how to do all these difficult things: RFC 4641bis (still in draft).

One final word: not all resolvers handle this issue strictly. Unbound treats zones that fail to do this correctly as insecure whereas BIND accepts zones despite this error. So your mileage may vary…