Details About the DNSSEC Configuration Issue.

Published: 2011-11-11
Last Updated: 2011-11-11 16:17:25 UTC
by Johannes Ullrich (Version: 1)
2 comment(s)

We got a number of comments regarding the DNSSEC issue, which I think warrant explaining some of the DNSSEC details in a bit more detail.

First of all: the domain is fine, the issue does not appear to be attack related and is a very common configuration problem with DNSSEC (yes... our domain had similar issues in the past which is why I am somewhat familiar with how this can happen)

First a very brief DNSSEC primer:

DNSSEC means that for each DNS record, your zone will include a signature. The signature is generated using a "zone signing key". Like any good signature, the signature has a limited lifetime. Commonly, the lifetime is in the range of a couple of weeks.

The result is, that the signatures need to be re-created before the lifetime expires. In the case of

$ dig A +dnssec +short @
CNAME 7 3 300 20111110173726 20110812173726 58969 

The signature was created Aug. 12 2011 and expired earlier today (Nov 11 2011).

Other DNS servers, resolving the domain, do not HAVE to check DNSSEC. If they don't the domain will continue to resolve just fine. However, if your DNS server happens to verify DNSSEC signatures, the verification will fail and as a result, DNS resolution will fail.

Comcast and OpenDNS for example will verify DNSSEC and if you are using either for your dns resolution, you will no longer be able to reach .

If you are using DNSSEC yourself, or if you are interested in checking for another site if DNSSEC is configured correctly, I recommend you check or Verisign's DNSSEc debugger at . They are an excellent resource to debug DNSSEC issues.

DNSSEC isn't exactly a simple configuration change. We discussed it in the past in diaries and webcasts. Please make sure you understand its implications before enabling it. I do recommend you enable it as it does provide a meaningful protection against DNS spoofing which is a precursor to various man-in-the-middle attack. DNSSEC does not encrypt anything. It only authenticates the DNS response. Enabllng DSNSEC on your resolver on the other hand is pretty straight forward and protects users of your resolver from spoofed DNS responses (the path from your resolver to the client may of course still be subject to spoofing, unless the client does its own validation)

Johannes B. Ullrich, Ph.D.
SANS Technology Institute

Keywords: dnssec
2 comment(s)


Now I see new RRSIGs valid from 2011-11-11T18-06-40Z, so presumably there was a 25-hour period during which DNSSEC-enabled resolvers couldn't get an authenticated response.

So I guess this issue probably wasn't related to the outages rumoured among transit providers early today. Unless they normally proxy their customers' traffic via, ho ho ho.

two (more) observations:
1. is a CNAME pointing at a non DNSSEC secured name : !
--> a malicious hacker would first spoof the IP address of that destination and then wait for that caching name server to resolve

Moral : all names used - *including* CNAME's - should be protected by DNSSEC.

2. You claim OpenDNS is verifying DNSSEC !? Do you mean ? Because I don't see the AD bit set for properly setup DNSSEC'd domains ...

Kind regards,

Marc Lampo
Security Officer

Diary Archives