Differences between revisions 36 and 37
Revision 36 as of 2014-05-13 20:54:35
Size: 6857
Editor: ?JanoJohnAkimFranke
Comment: Test DNSSEC/Command line: shortening output
Revision 37 as of 2014-08-30 15:31:59
Size: 7241
Editor: ?RalfJung
Comment: mention dnssec-trigger
Deletions are marked like this. Additions are marked like this.
Line 143: Line 143:
== dnssec-trigger ==

DebianPkg:dnssec-trigger automatically sets up a local DebianPkg:unbound resolver. If possible, it uses the DNS provided via DHCP (to leverage caching), and falls back to full recursive resolving otherwise. This makes it a great fit for DNSSEC on (mobile) end-user devices.

=== Installing dnssec-trigger ===

apt-get install dnssec-trigger

Translation(s): none

What is DNSSEC

DNSSEC — Domain Name System Security Extensions.

DNSSEC enables users with security aware DNS resolvers to securely retrieve information from the domain name system such as IP addresses, or for those who have shell accounts on debian.org machines SSH host key fingerprints. Any tampering with DNS replies would be replaced with a SERVFAIL reply by an intermediate resolver or detected by the resolver on the user's local machine.

DNSSEC is an important step in securing the Internet's name resolution infrastructure.

Domain registry

If you run your own nameserver, your domain registry typically needs to support DS records, in addition to the NS records that point at your zone.

Name servers that host your domain (authoritative servers)

If you host your domain operate on your own name server, some configuration tasks are needed to enable DNSSEC. falko provides a nice HOWTO for squeeze, almost all of it is valid for wheezy too.

If your domain is hosted on an ISPs nameserver, they will need to make all necessary configuration for you.

Recursive/Caching/intermediate nameservers

Nameservers that serve you/your users (e.g. in a router or local site server) can perform DNSSEC validation and if configured to do so, will filter out responses that fail DNSSEC validation. Clients (regardless of DNSSEC support) will just get a SERVFAIL response.

DNS client code

The DNS client code is part of the normal libraries installed on a Linux system. Some special purpose DNS client libraries also exist (e.g. ARES).

It is possible but not essential for the client library code to support DNSSEC records - for example, client code that doesn't support DNSSEC will still work. If the client does support DNSSEC, then it may be possible to turn on such support in such a way that it benefits all applications on the system.

End user applications

Applications don't necessarily need DNSSEC support to benefit from it. If the local nameserver is configured to make DNSSEC mandatory, then the applications will receive a SERVFAIL error trying to access any domain that is DNSSEC enabled if the signature data isn't valid.

For extra security or flexibility, DNSSEC-aware applications can insist on ONLY using DNSSEC authenticated responses. In this case, the application would be unable to access domains that have not implemented DNSSEC on their master nameserver. Applications typically don't enforce this policy by default.

Some applications use the DNSSEC support in other system libraries (e.g. to request signature records). Some applications may have built-in code for implementing DNS client functionality and not have any dependency on the system libraries.

DNSSEC support in Debian 6 (squeeze), 7 (wheezy) and beyond


Change from prior release

Nameserver (master) support

Nameserver (caching/intermediate) support

Client libraries

Applications of interest



Yes, must be enabled manually, make sure latest packages are used from security.debian.org


bind9 recursive nameserver enables DNSSEC by default


Yes, enabled by default in bind9


Once you have enabled DNSSEC you will want to confirm that your configuration changes have worked. We recommend running the following test both before and after.

Command line

$ dig org. SOA +dnssec

; <<>> DiG 9.7.3 <<>> org. SOA +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31736
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 1


;; Query time: 597 msec
;; WHEN: Thu May 12 21:44:43 2011
;; MSG SIZE  rcvd: 536

In the flags you should see ad.


$ dig +short test.dnssec-or-not.net TXT | tail -1
"Yes, you are using DNSSEC"

You will either see Yes, you are using DNSSEC or No, you are not using DNSSEC.

$ dig +noall +comments dnssec-failed.org
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 57099
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

You should see status: SERVFAIL, since this domain is deliberately configured broken.


Or visit one of these test pages: http://dnssectest.sidn.nl/ (informative) or http://test.dnssec-or-not.org/ (fun) ;-)


If DNSSEC doesn't work (you don't get answers from your caching DNS server) then there is possibly a problem in your firewall. Contact your system administrator and ask about this. Maybe some rules indirectly denied DNSSEC.

How to benefit from DNSSEC

To take advantage of DNSSEC you need a security aware resolver — a resolver that understands the DNS security extensions.

For this purpose you can use unbound or bind9. See the following sections.


unbound is a lightweight and easy to configure validating, recursive, and caching DNS resolver.

It also has built-in list of root servers in its root.hints file.

See also the unbound howto webpage http://www.unbound.net/documentation/howto_anchor.html.

Installing Unbound

apt-get install unbound


bind9 is widely used for both authoritative domain name serving as well as resolving for local networks.

Installing BIND

$ apt-get install bind9

These instructions work for bind9 9.8 or later.

Debian 7 "Wheezy" or later is fine as the package includes the root key and enables DNSSEC by default.


dnssec-trigger automatically sets up a local unbound resolver. If possible, it uses the DNS provided via DHCP (to leverage caching), and falls back to full recursive resolving otherwise. This makes it a great fit for DNSSEC on (mobile) end-user devices.

Installing dnssec-trigger

apt-get install dnssec-trigger

Set system DNS resolver to use local caching DNS server

Modify your /etc/resolv.conf to use loopback interface as nameserver.


Now you will use your local resolver (Unbound or BIND9) as a caching DNS server. All requests will go to it, and if it doesn't have a cached answer it will query root DNS servers.

If you use DHCP and your dhclient overwrites your /etc/resolv.conf then you should remove domain-name-servers from the request statement in the file /etc/dhcp/dhclient.conf.


If I enable DNSSEC on my local nameserver, does that mean I am 100% safe?

No, you are only protected when accessing websites that have chosen to enable DNSSEC on the server side.

If server side DNSSEC is not implemented for a particular domain, you may still receive tampered DNS responses for that domain.