Home / Blogs

DNS Clients Do Request DNSSEC Today

Daniel Karrenberg

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

By Daniel Karrenberg, Chief Scientist at the RIPE NCC
Follow CircleID on
SHARE THIS POST

If you are pressed for time ...

... this is for you. More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Vinton Cerf, Co-designer of the TCP/IP Protocols & the Architecture of the Internet

Share your comments

Yes but no Stephane Bortzmeyer  –  Sep 06, 2010 1:10 PM PDT

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.)

Wrong thing to look at. David Conrad  –  Sep 06, 2010 4:35 PM PDT

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 Phillip Hallam-Baker  –  Sep 06, 2010 9:31 PM PDT

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

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

Wrong Thing / Yes but No Daniel Karrenberg  –  Sep 07, 2010 1:35 AM PDT

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.

Is anyone brave enough to do validation? Paul Roberts  –  Sep 07, 2010 1:38 AM PDT

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

Practical issues Phillip Hallam-Baker  –  Sep 07, 2010 6:31 AM PDT

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 will validate David A. Ulevitch  –  Sep 07, 2010 1:21 PM PDT

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.

To post comments, please login or create an account.

Related

Topics

New TLDs

Sponsored byAfilias

DNS Security

Sponsored byAfilias

IP Addressing

Sponsored byAvenue4 LLC

Domain Names

Sponsored byVerisign

Cybersecurity

Sponsored byVerisign