Unbound is a secure, lightweight and high performance validating, recursive, and caching DNS resolver. It performs DNSSEC validation and it is also really easy to configure. Although it cannot act as a full fledged authoritative server, you may take a look at NSD, which is, on the contrary, authoritative only. For a nice tutorial about unbound configuration, see this post.

Today I discovered local_unbound on FreeBSD. This script generates a configuration suitable for running unbound as a forwarding resolver. It also uses resolveconf to update the list of forwarders. This means that it is automatically configured with the name servers provided by the DHCP offer.

By default, unbound is configured to withheld the reply from the client when the validation fails. Unfortunately most of the name servers provided by home routers and ISPs do not support DNSSEC. Even worse, some ISPs redirect all queries to their own name servers which of course do not support DNSSEC either. You can check if it is the case with this command:

dig @8.8.8.8 +short test.dnssec-or-not.net TXT

As Google public DNS support DNSSEC. If it does not show you anything, it is OK. If instead it says something like: “Nope!  DO bit not set in your query” then your query has been forwarded to a server which is not DNSSEC capable.

Because of this, you often end up with a nice caching forwarding resolver which does not seem to resolve anything (at least on the client side) because of bogus validations.

You have two solutions to overcome this. First you can force your forwarders to DNSSEC capable servers such as Google public DNS (8.8.8.8 / 8.8.4.4). However, as mentioned above this does not work when your ISP redirect all queries to its own server. The second solution is to configure unbound into permissive mode (/etc/unbound/unbound.conf):

server:
    (...)
    val-permissive-mode: yes

In that case, replies to queries that did not pass validation are not longer withheld from the client but the Authenticated Data bit is not set in the reply.