Table of Contents
Activate DNSSEC check with Unbound
Unbound is an excellent DNS resolver that can very quickly act as a resolver for you entire network. This is actually pretty straightforward on Debian:
# aptitude install unbound
And then edit the configuration file /etc/unbound/unbound.conf to make it listen on your LAN interface (instead of 127.0.0.1 by default):
server: verbosity: 1 interface: 192.168.1.1 port: 53 do-daemonize: yes access-control: 192.168.1.0/24 allow
DNSSEC
As of 2010, most of the Root DNS servers now sign their records with a DNS Key. Therefore, when you query one of those server, you can obtain the signature of the record and verify it.
As stated in the documentation, you need to install the trust anchor for the root zone in a file that unbound can read and write.
# echo ". IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5" > /etc/unbound/dnssec_root.key # chown unbound /etc/unbound/dnssec_root.key # chmod 700 /etc/unbound/dnssec_root.key
Next, edit the configuration file /etc/unbound/unbound.conf to specify the path to the anchor:
auto-trust-anchor-file: "/etc/unbound/dnssec_root.key"
<note>Obviously, if you are running unbound in a chroot (not by default), you need to put this file in the chroot.</note>
Finally, restart unbound and test the resolution with dig. The /etc/unbound/dnssec_root.key file will be overwritten according to the rollover of the key.
Using dig, we can query a root and verify that the response is valid (checking its authenticity and integrity). The query is not very different from a regular DNS resolution, except that there is an additionnal validation step inside unbound.
Steps are:
- [1] Dig send a query to its local resolver (unbound) asking for the nameserver of the root “gov.”
$ dig gov. +dnssec NS @192.168.1.1
- [2] Unbound does not have this record in its cache, so it contact the nameserver in charge of gov
- [3] USAGOV returns a full answer contaning a RRSIG record (see appendix)
- [4] Unbound validate the signature using the public keys chain it knows about and return the answer to Dig
- [5] Dig receives a valid answer and thus display it to the user and add a ad flag. This flag means :
+[no]adflag
Set [do not set] the AD (authentic data) bit in the query.
This requests the server to return whether all of the answer
and authority sections have all been validated as secure according
to the security policy of the server. AD=1 indicates that all
records have been validated as secure and the answer is not from a
OPT-OUT range. AD=0 indicate that some part of the answer was
insecure or not validated.
Here is the answer that dig displays:
$ dig gov. +dnssec +adflag NS @192.168.1.1 ; <<>> DiG 9.7.2-P3 <<>> gov. +dnssec +adflag NS @192.168.1.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49906 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;gov. IN NS ;; ANSWER SECTION: gov. 258532 IN NS C.USADOTGOV.NET. gov. 258532 IN NS F.USADOTGOV.NET. gov. 258532 IN NS A.USADOTGOV.NET. gov. 258532 IN NS G.USADOTGOV.NET. gov. 258532 IN NS B.USADOTGOV.NET. gov. 258532 IN NS E.USADOTGOV.NET. gov. 258532 IN NS D.USADOTGOV.NET. gov. 258532 IN RRSIG NS 7 1 259200 20110105231704 20101231231704 23239 gov. BbeIUZmWyFsiAuRDa39qe9KWxiewXR9BYN9X0vtH1TnZQhluqKZ0gVJK Rmin/FvCZ8Xz1CQVsjOAd6wzb/wawro9Bapolz2gO83HMUF8RKOdBvxH cDHIauN9fpyPBVkzpOF9bJZiKN5b0SQanl9nYucy+6C5HcFsA6pDhgTW QvLzEBw02wDu8e2TEHKDiNq2avXVcgt2L3LqZcEdGdP0cxphrI9k03Ff FMVztOKzjegqGROXBWI7NDmuYCzUWorh3739FdzhZYSsdYtRihc3z4Lt 2cTMg8ShCoe6YIr7JPBCtEzqfzCKmI3Ua0W0yQwy5XDvHG0sL6Ax2MNR qfMLTQ== ;; Query time: 0 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Sat Jan 1 11:39:49 2011 ;; MSG SIZE rcvd: 448
Appendix: DNSSEC signature response
When querying a root such as “nl.”, the root name server will return the DNSSEC signature of the record.
Query
$ dig nl. SOA +dnssec @192.168.1.1
Response
