|
After the DNS root zone was finally signed and a number of Top-Level Domains (TLDs) began signing their zones, we were curious to see how many clients actually request DNSSEC information. We looked at the RIPE NCC server that provides secondary service to several country code top-level domains (ccTLDs).
This server answers around 5,000 queries per second on average. In the image below you can see the percentage of those queries that requested DNSSEC information during August 2010:
More than 50% of all queries request DNSSEC information from this server. This is very encouraging and shows that DNSSEC is being deployed.
Here are some guidelines for configuring your caching resolvers to use the root zone DNSSEC key:
BIND: https://dnssec.surfnet.nl/?p=402
Unbound: https://dnssec.surfnet.nl/?p=212
For more details on this topic, please refer to RIPE Labs:
https://labs.ripe.net/Members/dfk/dns-clients-do-request-dnssec-today
Sponsored byWhoisXML API
Sponsored byRadix
Sponsored byVerisign
Sponsored byVerisign
Sponsored byCSC
Sponsored byDNIB.com
Sponsored byIPv4.Global
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.
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
One of the things that gives me considerable anxiety where DNSSEC is concerned is that time after time I asked what appears to me to be a very reasonable question and got back the response 'that is someone else's problem'. This is the type of question that should have been asked at the start of the DNSSEC process, not the end. What is rather more worrying is that there were many simpler ways to fix the Kamninsky bug that were ignored in favor of using it as a pretext to drive deployment of DNSSEC.
People, businesses and ISPs will validate for a limited period until a major site is inaccessible and then they'll turn it off. Look how users interact with SSL certs for an example. Nobody cares if it doesn't validate, they just want the warning to go away. If someone's ISP is validating and rejecting invalid responses, it will be a support nightmare. At least with SSL the control is in the hands of the end-user. At the end of the day, the only way for DNSSEC to succeed is if every end-user is running a full-blown validating resolver. This is entirely reasonable, but it's a long long road.