One of the problems with DNSSEC is that most Internet Service Providers (ISP) do not yet perform validation, and even if they did, you’d most likely (or rather: hopefully) not trust them to validate for you. For this reason, we need a validating DNS resolver as close as possible to our applications (i.e. Web browser, telnet, XMPP client, etc.) and one very suitable program which implements those features is Unbound.

Unbound is a validating, caching DNS server which was released in May 2008. I’ve spoken of Unbound quite frequently because it runs on multiple platforms (yes, Windows also), is very stable and performs very well. The configuration file supplied with Unbound contains very sensible defaults so that, if at all, just tiny tweaks are required to get it running on your workstation, i.e. on address 127.0.0.1 and/or ::1.

As a road warrior, i.e. somebody who moves between different network locations, things start getting tricky:

• I arrive in an environment that doesn’t let my computer access the public DNS servers (think corporate environment with private root servers).
• A hotel’s wireless hot spot (groan) might be filtering port 53 or doing other nasty stuff such as not allowing port 53 at all.

If this happens, I have to change the configuration of Unbound on my workstation and reload it or use unbound-control to set forwarders. Not difficult, but it is a bit of a PITA to have to remember to do this several times a week.

Wouter Wijngaards of NLnetLabs, the creator of Unbound, has written DNSSEC-trigger, a program that enables my computer (Windows, Linux, Mac OS/X) to automatically reconfigure a local Unbound instance on the fly as soon as it detects a change in the computer’s network configuration.

DNSSEC-trigger probes the DNS servers assigned to my computer via DHCP and attempts to determine whether they are DNSSEC-capable. If they are, it instructs my local Unbound to use them, which means I’ll be profiting from those existing caching servers (scenario A). Another possibility is to tell Unbound to use the root name servers as a starting point, which is what recursive DNS caches usually do (scenario B). This places a higher load on the public DNS which is why it is second choice.

One of DNSSEC-trigger’s last resorts is to attempt to use Unbound servers provided by NLnetLabs (scenario C). These listen on port 53 (DNS), 80 (HTTP) and 443 (HTTPS), hoping that my computer will be able to access one of those ports transparently. In all cases, DNSSEC-trigger modifies the computer’s network configuration, adjusting the DNS servers (resolvers) to point to Unbound on the local host.

For the first time in a while, I thought I’d show you a bit of Windows. The DNSSEC-trigger setup package for Windows bundles its own Unbound so with a bit of luck you won’t have to do anything other than a few clicks. At this point, a big thanks to Wouter for fixing a few glitches so that I can actually show you this working in Windows XP. I’m using the (as yet unreleased) 0.7 version.

On Windows, when the installer finishes, it launches the DNSSEC-trigger service and Unbound, and you should see a new icon on the task bar.

From this, we can see how successful DNSSEC-trigger has been: it shows us what it has probed.

I see my computer is configured to use two DNS servers; it obtained these addresses via DHCP. One of the servers hasn’t as yet responded (error timeout), which is correct: I had disabled the caching server on 192.168.1.4, and DNSSEC-trigger has identified it is down, so Unbound will use 192.168.1.20 as a cache.

Let me now show you the command line tools. Let’s check the status again, and we see nothing has changed.

C:\> dnssec-trigger-control.exe status
at 2011-10-21 15:09:50
cache 192.168.1.4: error timeout
cache 192.168.1.20: OK
state: cache secure

I’ll start up the dead DNS server on 192.168.1.4, and force DNSSEC-trigger to probe again:

C:\> dnssec-trigger-control.exe reprobe

C:\> dnssec-trigger-control.exe status
at 2011-10-21 15:15:30
cache 192.168.1.20: OK
cache 192.168.1.4: OK
state: cache secure

“cache secure” means that Unbound on my computer is validating, i.e. I have DNSSEC. I can also try using a Web browser and pointing it to http://dnssectest.sidn.nl/

If I pull the network cable on this machine and check the status, I see:

C:\> dnssec-trigger-control.exe status
at 2011-10-21 17:43:50
no cache: no DNS servers have been supplied via DHCP
state: disconnected secure

We are offline.

I plugged in a Huawei USB modem like I might do when in a hotel. The device gives my computer network configuration via DHCP, but its built-in DNS forwarder isn’t DNSSEC capable, because it truncates any reply larger than 512 bytes. DNSSEC-trigger works around this by telling Unbound to use the root DNS as anchor. (192.5.5.241 is an address of the F root server.)

C:\> dnssec-trigger-control.exe status
at 2011-10-21 17:54:31
probe is in progress
state: disconnected secure

C:\> dnssec-trigger-control.exe status
at 2011-10-21 17:54:39
authority 192.5.5.241: OK
cache 192.168.2.1: error no RRSIGs in reply
cache 192.168.2.1: error no RRSIGs in reply
state: auth secure

3G reception in my office is lousy so I moved away after dinner, but disconnected the modem by mistake. Upon plugging it in a bit later I saw this warning box:

The status is

C:\> dnssec-trigger-control.exe status
at 2011-10-21 19:39:27
authority 192.228.79.201: error timeout
cache 192.168.2.1: error no RRSIGs in reply
cache 192.168.2.1: error no RRSIGs in reply
state: nodnssec secure

I forced a re-probe, and all was well: my Web browser passed the test.

DNSSEC-trigger is a work in progress, and there are very many scenarios I haven’t yet been able to test, but in the ones I have tested, DNSSEC-trigger works beautifully. I strongly recommend you try the program, read its documentation, and subscribe to the DNSSEC-trigger mailing list, where you are sure to find help.

Stéphane Bortzmeyer has written a very extensive article on the use of DNSSEC-trigger in French, which I recommend you read (English translation), and a few words on DNSSEC-trigger on Mac OS/X.