My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

.GOV zones may not resolve due to DNSSEC problems.

Published: 2013-08-14. Last Updated: 2013-08-14 16:25:39 UTC
by Johannes Ullrich (Version: 1)
2 comment(s)

Update: looks like this has been fixed now. Of course bad cached data may cause this issue to persist for a while.

Currently, many users are reporting that .gov domain names (e.g. fbi.gov) will not resolve. The problem appears to be related to an error in the DNSSEC configuration of the .gov zone.

According to a quick check with dnsviz.net, it appears that there is no DS record for the current .gov KSK deposited with the root zone.

dnsviz.net Screen Shot

(excerpt from: http://dnsviz.net/d/fbi.gov/dnssec/) 

DNSSEC relies on two types of keys each zone uses:

- A "key signing key" (KSK) and
- A "zone signing key" (ZSK)

The KSK  is usually long and its hash is deposited with the parent zone as a "DS" (Digital Signing) record. This KSK is then used to sign shorter ZSKs which are then used to sign the actual records in the zone file. This way, the long key signing key doesn't have to be changed too often, and the DS record with the parent zone doesn't require too frequent updates. On the other hand, most of the "crypto work" is done using shorter ZSKs, which in turns improves DNSSEC performance.

I am guessing that the .gov zone recently rotated it's KSK, but didn't update the corresponding DS record witht he root zone. 

This will affect pretty much all .gov domains as .gov domains have to be signed using DNSSEC. You will only experience problems if your name server (or your ISP's name server) verifies DNSSEC signatures.

 

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

Keywords: dnssec gov
2 comment(s)
My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Comments

I wrote this hack of a script (I'm not a coder, I'm a sysadmin), but it gets the job done. This has helped speed up DNSSEC resolution with no work from the sysadmins (we don't have to flush DNS any more). Help Desk knows how to look up problems at DNSVIZ.net, so as long as there is a problem, we won't be resolving a zone. But once it is fixed, within 2 mintues we'll have the new data:

#!/bin/bash

# DNSSEC misconfigurations occur because dns admins don't properly manage keys
# or sign records properly. This script doesn't fix this problem, but it
# flushes out these bad records so that they can be re-learned. This helps
# speed up learning the non-broken recods after the dns admin has fixed the
# problem).

# call this script from cron with a job to run every 2 minutes:
# */2 * * * * /root/cron/bin/dnssec-flush.sh

# look during the last 3 minutes for DNSSEC validating errors, produce a list of just domains, sort them and produce a unique list of domains
cat /var/log/messages | grep validating | grep -iv 'in-addr\.arpa\|ip6\.arpa\|no valid signature found' | grep "`date --date='now' +'%b %_d %R'`\|`date --date='1 minutes ago' +'%b %_d %R'`\|`date --date='2 minutes ago' +'%b %_d %R'`" | awk '{ print tolower($8)}'|sort|uniq|grep -v '^.$' > /tmp/dnssec-flush

# keep a history of each flush list
cat /tmp/dnssec-flush >> /root/cron/logs/dnssec-flush.his

# create a working file with a leading # which is needed for sed to not skip first line
echo \#> /tmp/dnssec-flush.work
cat /tmp/dnssec-flush >> /tmp/dnssec-flush.work

# convert each newline into adding the following after the newline: "rndc flushname " (prepended just before the domain name)
cat /tmp/dnssec-flush.work | sed ':a;N;$!ba;s/\n/ \
\/usr\/sbin\/rndc flushname /g' > /tmp/dnssec-flush.work2

# run the new script, flushing bad DNSSEC domains from cache
bash /tmp/dnssec-flush.work2
Hmmm didn't they mess this up last year as well?

Diary Archives