unbound and root.key

The topic of this post is much more narrow than any I’ve done before, but I think it’s a good idea to publish this collection of keywords and pointers regarding a tricky configuration problem I encountered.

Background: Launching a Resolver

As most of my readers would know, the Domain Name System (DNS) is the distributed system that converts Internet hostnames such as http://www.google.com into IP addresses such as, so that it’s possible to route traffic from your host to the desired destination (e.g., a search engine site).

A resolver is the software component that submits queries to DNS on behalf of a user’s app or other programs.  I am working with an excellent open source resolver called unbound.

The problem I ran into was that unbound would shutdown immediately after starting.  A look at the log messages showed the following:

May  9 17:54:11 foo.bar.org unbound: [3482:0] error: failed to read /root.key
May  9 17:54:11 foo.bar.org unbound: [3482:0] error: error reading auto-trust-anchor-file: /var/unbound/root.key
May  9 17:54:11 foo.bar.org unbound: [3482:0] error: validator: error in trustanchors config
May  9 17:54:11 foo.bar.org unbound: [3482:0] error: validator: could not apply configuration settings.
May  9 17:54:11 foo.bar.org unbound: [3482:0] error: module init for module validator failed

Root.key? Trust anchor??

Diagnosis and Treatment

Hitting Google shows that a corrupted root key is a common affliction for unbound, see this forum article.  Unsurprisingly, the cure is to replace the trashed root.key file with a good one, as suggested here.  But how?

Answer: the tool, unbound-anchor!  Run

sudo unbound-anchor

…and a legit root.key will be created, allowing unbound to start.

No rest for the weary

This solved my problem, which was getting unbound to start on a test system.  But the purpose of the root.key is to support the optional DNSSEC feature of unbound — the ability for DNS message content to be selectively “signed” by cryptographic hashes.  If you are deploying unbound on a production system, you have the obligation to verify that you are using an appropriate trust anchor.

Good hunting!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s