Intro

If you have ever worked on website performance you will be familiar with the term “time to first byte” (TTFB).

TTFB is from the moment you have a website in your URL bar and hit enter to how long does it take for the first piece of page content to be received.

TTFB is a good indicator of website performance. It will not show you the impact of any resource loading that happens once the page is loaded.

A large part of the time incurred while connecting to a website is during DNS resolution. The other is establishing a TLS connection.

We can speed up DNS resolution time.

What

We are going to setup Unbound as a recursive caching DNS server that runs on your local network.

There will be many devices querying this DNS server which will build up the cache and keep it hot.

Prefetching is enabled so any entry in our DNS cache which is about to expire will be queried for again by Unbound.

TLDR of what you will get

1. QNAME minimisation (privacy)

2. Aggressive caching (performance)

3. Prefetching (performance)

4. Stale caching (resilience)

5. DNSSEC validation (security)

6. No query logging. (privacy)

7. Access control to only answer queries sent from RFC1918 addresses. (security)

8. Control of your DNS data. (privacy)

This is the unbound configuration being used.

How

Assumptions

You are familiar with Linux. You have Systemd installed.

Caveats

This will disable systemd-resolverd. This will replace the symlink for /etc/resolv.conf that is managed by systemd with a static file.

Unbound setup

Apt-get based systems

sudo apt-get install git -y

git clone https://github.com/buggysolid/unbound-install

cd unbound-install

sudo ./install-apt-get.sh

Yum/dnf based systems

sudo yum install git -y

git clone https://github.com/buggysolid/unbound-install

cd unbound-install

sudo ./install-yum.sh

Verify installation

dig @localhost ns google.com +short

sudo unbound-control status

You should expect to see output like.

root@ubuntu-s-4vcpu-8gb-intel-ams3-01:~# dig @localhost ns google.com +short

ns4.google.com.

ns2.google.com.

ns3.google.com.

ns1.google.com.

root@ubuntu-s-4vcpu-8gb-intel-ams3-01:~# sudo unbound-control status

version: 1.16.0

verbosity: 0

threads: 2

modules: 2 [ validator iterator ]

uptime: 166 seconds

options: reuseport control(ssl)

unbound (pid 24204) is running...

root@ubuntu-s-4vcpu-8gb-intel-ams3-01:~#

Let’s do a reboot to be sure, you would be very surprised how many services depend on having DNS resolution to reboot.

I have seen not having DNS resolution preventing machines from coming back up on the network after a reboot

That is when you hope you have an out of band access method.

sudo shutdown -r now

Network setup

Assuming your host came back up after the reboot.

You will want to find out the IP address of the machine you setup Unbound on as this will be the IP you are vending to devices on your LAN via DHCP.

Before assigning the IP in a DHCP lease you should set a single device to use your local DNS server to verify everything is working.

Generally updating your DHCP settings is done via your router. I will leave that as an adventure for the reader.

Tests

With your new fancy DNS resolver configured you can use this test from DNS OARC to see how well you score.

You should get an A to B result depending on how much your ISP plays with your traffic and their network architecture.

Other testing links you may want to use.

DNS leak test DNSSEC Resolver Test

Outro

Before I started writing this post, I thought I had uncovered a bug in Unbound.

It turns out it is expected behaviour that is not documented.

If you read the unbound.conf documentation for the verbosity argument. There is no mention of invoking unbound -v taking precedance over what is defined in unbound.conf.

It also doesn’t specify that a verbosity level of -1 will be treated as zero in Unbound. The Enum structure for that setting doesn’t define a -1 level.

Thankfully the folks over at NLNetLabs have triaged the report and agreed the docs could do with a bit of an update.