Paranoid Penguin - DNS Cache Poisoning, Part II: DNSSEC Validation
Back on your caching nameserver, all you need to do to add DNSSEC validation is add three lines in the options{} section of your /etc/bind/named.conf.options file, plus a new managed-keys{} section, as shown in Listing 3.
Listing 3. DNSSEC-Enabled named.conf.local
acl mynetworks { 192.168.100.0/24; 10.10.0.0/16; };
options {
directory "/var/cache/bind";
allow-query { mynetworks; };
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { none; };
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
};
managed-keys {
"." initial-key 257 3 8 "
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ
bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh
/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA
JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp
oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3
LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO
Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc
LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= ";
};
The first two new lines in Listing 3, dnssec-enable yes; and dnssec-validation yes;, enable DNSSEC on your caching nameserver. This is actually a redundant setting, because “yes” is the default value for both these settings in BIND versions 9.5 and later, but it doesn't hurt to specify them.
The third new line, dnssec-lookaside auto;, tells BIND/named to use DLV automatically any time it can't validate a complete chain of trust from a given Resource Record all the way from root (.) downward. See the DNSSEC Overview section earlier in this article if you've forgotten how DLV works.
As I mentioned in that section, recent versions of BIND are preconfigured to find isc.org's DLV repositories. All you have to do to take advantage of this is set “dnssec-lookaside” to “auto”, and BIND will do the rest. As more and more TLDs are signed, this feature will become less important.
And, that brings me to the last new element in the named.conf.options file: the managed-keys{} section. This specifies a key for the DNS “root” domain, which is the top of any chain of DNSSEC trust.
You don't necessarily need to specify any keys “lower” in the DNS hierarchy than root; if you start out knowing the root key, you can trust signed replies from root nameservers. That trust flows downward to signed data from TLDs (.gov, .us, .net and so on) and so forth. “Gaps” in the downward chain of validation hopefully will be handled by DLV.
For heaven's sake, do not simply copy Listing 3's key entry for “.” verbatim! Tony Finch has written a quick-and-easy procedure on checking and validating the (initial) root certificate (see Resources). Summarized, this procedure consists of the following steps.
1) Use the following dig command to obtain the current root certificate and save it to the file root-dnskey:
bash-$ dig +multi +noall +answer DNSKEY . >root-dnskey
2) Create a hash of this certificate and save it to the file root-ds with this command:
bash-$ $ dnssec-dsfromkey -f root-dnskey . >root-ds
3) Pull the official root certificate's hash from https://data.iana.org/root-anchors/root-anchors.xml, and compare it to the root-ds file you just created. For extra paranoia, you can use PGP to check the signature of root-anchors.xml (see Tony Finch's article).
4) If the hashes match, copy the key (the long one, number 257) from root-dnskey into your managed-keys statement, as shown in Listing 3. The first line of this block (after the managed-keys { line) should be the same as in Listing 3.
As with your previous changes, after you save named.conf.options, you should check it with named-checkconf, and then load it with rndc reload.
Finally, to test DNSSEC validation, test some known-signed record, such as www.isc.org, using dig. Be sure to use the +dnssec flag, like this:
mick@someotherhost:/home/mick$ dig @192.168.100.253 ↪www.isc.org +dnssec
If everything is working, dig's output should indicate that the “ad” (authenticated data) flag is set. Listing 4 shows the first part of what a successful reply to our example dig command would look like. Note the line that begins ;; flags: qr rd ra ad;.
Listing 4. dig Output for Successful DNSSEC Validation
; <<>> DiG 9.6.0-APPLE-P2 <<>> @192.168.100.253 www.isc.org +dnssec ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62704 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 13
Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
| Trying to Tame the Tablet | May 08, 2013 |
| Dart: a New Web Programming Experience | May 07, 2013 |
- RSS Feeds
- New Products
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Home, My Backup Data Center
- New Products
- Paranoid Penguin - Building a Secure Squid Web Proxy, Part IV
- Developer Poll
- Trying to Tame the Tablet
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.




23 sec ago
4 hours 14 min ago
6 hours 46 min ago
11 hours 25 min ago
13 hours 48 min ago
1 day 6 hours ago
1 day 9 hours ago
1 day 10 hours ago
1 day 11 hours ago
1 day 11 hours ago