More or less the same numbers on .FR authoritative name servers. But the reader may misunderstand these numbers: most resolvers which send queries with the ‘DNSSEC OK’ bit do not validate at all and therefore it is misleading to say that “DNSSEC is deployed”. (Setting the ‘DNSSEC OK’ bit is simply BIND’s default behavior.)

Daniel,

The more than 50% has remained somewhat constant since long before the root was signed.  As Stephane points out, most resolvers turn on the DO bit by default, even if no trust anchor has been configured.  The end result is simply a waste of bandwidth since the resolvers will drop the DNSSEC stuff onto the floor.  All your graph shows is that more than 50% of the resolvers assert that they can understand DNSSEC, not that they will actually validate the response.

The more interesting graph to look at is the growth in actual DNSSEC queries (DS, DNSKEY, etc) as this would indicate actual DNSSEC usage.  I suspect you’ll find it far less than 2500 queries per second.

Signing the zones and validating the results is the easy part.

What does a client do when the signatures do not validate?

The referenced RIPE Labs article acknowledges that we do not know what resolvers actually do with the DNSSEC information they request. That part was snipped off when the article was shortened for publication here. I agree with Stephane and David that looking at DNSSEC queries is worthwhile and we will be doing that and report here when we have results.

What does a client do when the signatures do not validate?

I think you have hit the nail on the head. At the moment, I don’t believe the resolver in Windows 7 will do validation, so validation has to be done on the “nearest” DNS server on behalf of the client.

But if the signature does not validate, the server will just send “SERVFAIL” to the client, so the client has no idea what happened and just bombs out. Not very pretty. I know this was done to maintain compatibility with non-DNSSEC aware clients, but you could spend loads of time troubleshooting what went wrong. The validation failure could have been due to an expired signature, or there could have been a problem obtaining the RRSIG records (maybe EDNS0 or TCP queries didn’t work). Or maybe there’s a key rollover or TTL issue. Or a trust anchor problem (is your DLV key up to date?). Or a DS record problem in the parent zone. Or… or…. or….! I sometimes feel that the whole DNSSEC design is too fragile and there are too many places where it can break.

Your average Cisco guy working in your average IT department in your average corporate is not going to be able to troubleshoot this. So when golfballsrus.com start doing DNSSEC and the CEO asks why he can’t buy new golf balls, the poor IT guy is going to get a ton of crap coming down onto him from high above! :-)

Paul