Translation(s): none

TODO: Criticism from should be included in the page. Please remove this comment once you have done so.

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 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


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 +noall +comments
;; 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.

Web-based (informative)


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

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.