Details About the fbi.gov DNSSEC Configuration Issue.
Last Updated: 2011-11-11 16:17:25 UTC
by Johannes Ullrich (Version: 1)
We got a number of comments regarding the FBI.gov DNSSEC issue, which I think warrant explaining some of the DNSSEC details in a bit more detail.
First of all: the fbi.gov domain is fine, the issue does not appear to be attack related and is a very common configuration problem with DNSSEC (yes... our dshield.org 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 fbi.gov:
$ dig A www.fbi.gov +dnssec +short @220.127.116.11 www.fbi.gov.c.footprint.net. CNAME 7 3 300 20111110173726 20110812173726 58969 fbi.gov.
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 fbi.gov .
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 dnsviz.net or Verisign's DNSSEc debugger at http://dnssec-debugger.verisignlabs.com . 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
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 fbi.gov, ho ho ho.
Nov 12th 2011
1 decade ago
two (more) observations:
1. www.fbi.gov. is a CNAME pointing at a non DNSSEC secured name : www.fbi.gov.c.footprint.net. !
--> a malicious hacker would first spoof the IP address of that destination and then wait for that caching name server to resolve www.fbi.gov.
Moral : all names used - *including* CNAME's - should be protected by DNSSEC.
2. You claim OpenDNS is verifying DNSSEC !? Do you mean 18.104.22.168 ? Because I don't see the AD bit set for properly setup DNSSEC'd domains ...
Nov 14th 2011
1 decade ago