The NSD Authoritative DNS Server: What, why, and how
In a previous blog post, I explained how to setup unbound
, a recursive resolving DNS server. I demonstrated how to setup a simple split-horizon DNS setup, and forward DNS requests to an upstream DNS server - potentially over DNS-over-TLS.
Recently, for reasons that are rather complicated, I found myself in an awkward situation which required an authoritative DNS server - and given my love of explaining complicated and rather niche concepts here on my blog, I thought this would be a fabulous opportunity to write a 2-part series :P
In this post, I'm going to outline the difference between a recursive resolver and an authoritative DNS server, and explain why you'd want one and how to set one up. I'll explain how it fits as a part of a wider system.
Go grab your snacks - you'll be learning more about DNS than you ever wanted to know....
DNS in a (small) nutshell
As I'm sure you know if you're reading this, DNS stands for the Domain Name System. It translates domain names (e.g. starbeamrainbowlabs.com.
) into IP addresses (e.g. 5.196.73.75
, or 2001:41d0:e:74b::1
). Every network-connected system will make use of a DNS server at one point or another.
DNS functions on records. These define how a given domain name should be resolved to it's corresponding IP address (or vice verse, but that's out-of-scope of this post). While there are many different types of DNS record, here's a quick reference for the most common one's you'll encounter when reading this post.
A
: As simple as it gets. AnA
record defines the corresponding IPv4 address for a domain name.AAAA
: Like anA
record, but for IPv6.CNAME
: An alias, like a symlink in a filesystem [Linux] or a directory junction [Windows]NS
: Specifies the domain name of the authoritative DNS server that holds DNS records for this domain. See more on this below.
A tale of 2 (DNS) servers
Consider your laptop, desktop, phone, or other device you're reading this on right now. Normally (if you are using DHCP, which is a story for another time), your router (which usually acts as the DHCP server on most home networks) will tell you what DNS server(s) to use.
These servers that your device talks to is what's known as a recursive resolving DNS server. These DNS servers do not have any DNS records themselves: their entire purpose is to ask other DNS servers to resolve queries for them.
At first this seems rather counterintuitive. Why bother when you can have a server that actually hosts the DNS records themselves and just ask that every time instead?
Given the size of the Internet today, this is unfortunately not possible. If we all used the same DNS server that hosted all DNS records, it would be drowned in DNS queries that even the best Internet connection would not be abel to handle. It would also be a single point of failure - bringing the entire Internet crashing down every time maintenance was required.
To this end, a more scaleable system was developed. By having multiple DNS servers between users and the authoritative DNS servers that actually hold the real DNS records, we can ensure the system scales virtually infinitely.
The next question that probably comes to mind is where the name recursive resolvers DNS server comes from. This name comes from the way that these recursive DNS servers ask other DNS servers for the answer to a query, instead of answering based on records they hold locally (though most recursive resolving DNS servers also have a cache for performance, but this is also a tale for another time).
Some recursive resolving DNS servers - such as the one built into your home router - simply asks 1 or 2 upstream DNS servers - usually either provided by your ISP or manually set by you (I recommend 1.1.1.1
/1.0.0.1
), but others are truly recursive.
Take peppermint.mooncarrot.space.
for example. If we had absolutely no idea where to start resolving this domain, we would first ask a DNS root server for help. Domain names are hierarchical in nature - sub.example.com.
is a subdomain of example.com.
. The same goes then that mooncarrot.space.
is a subdomain of space.
, which is itself a subdomain of .
, the DNS root zone. It is no accident that all the domain names in this blog post have a dot at the end of them (try entering starbeamrainbowlabs.com.
into your browser, and watch as your browser auto-hides the trailing dot .
).
In this way, if we know the IP address of a DNS root server (e.g. 193.0.14.129
, or 2001:7fd::1
), we can recurse through this hierarchical tree to discover the IP address associated with a domain name we want to resolve
First, we'd ask a root server to tell us the authoritative DNS server for the space.
domain name. We do this by asking it for the NS
record for the space.
domain.
Once we know the address of the authoritative DNS server for space.
, we can ask it to give us the NS
record for mooncarrot.space.
for us. We may repeat this process a number of times - I'll omit the specific details of this for brevity (if anyone's interested, I can write a full deep dive post into this, how it works, and how it's kept secure - comment below) - and then we can finally ask the authoritative DNS server we've tracked down to resolve the domain name peppermint.mooncarrot.space.
to an IP address for us (e.g. by asking for the associated A
or AAAA
record).
Authoritative DNS servers
With this in mind, we can now move on to the main purpose of this post: setting up an authoritative DNS server. As you might have guessed by now, the purpose of an authoritative DNS server is to hold records about 1 or more domain names.
While most of the time the authoritative DNS server for your domain name will be either your registrar or someone like Cloudflare, there are a number of circumstances in which it can be useful to run your own authoritative DNS server(s) and not rely on your registrar:
- If you need more control over the DNS records served for your domain than your registrar provides
- Serving complex DNS records for a domain name on an internal network (split-horizon DNS)
- Setting up your own dynamic DNS system (i.e. where you dynamically update the IP address(es) that a domain name resolves to via an API call)
Other situations certainly exist, but these are 2 that come to mind at the moment (comment below if you have any other uses for authoritative DNS servers).
The specific situation I found myself was a combination of the latter 2 points here, so that's the context in which I'll be talking.
To set one up, we first need some software to do this. There are a number of DNS servers out there:
- Bind9 [recursive; authoritative]
- Unbound [recursive; not really authoritative; my favourite]
- Dnsmasq [recursive]
- systemd-resolved [recursive; it always breaks for me so I don't use it]
As mentioned Unbound is my favourite, so for this post I'll be showing you how to use it's equally cool sibling, nsd
(Name Server Daemon).
The Name Server Daemon
Now that I've explained what an authoritative DNS server is and why it's important, I'll show you how to install and configure one, and then convince another recursive resolving DNS server that's under your control to ask your new authoritative DNS server instead of it's default upstream to resolve DNS queries for a given domain name.
It goes without saying that I'll be using Linux here. If you haven't already, I strongly recommend using Linux for hosting a DNS server (or any other kind of server). You'll have a bad day if you don't.
I will also be assuming that you have a level of familiarity with the Linux terminal. If you don't learn your terminal and then come back here.
nsd
is available in all major distributions of Linux in the default repositories. Adjust as appropriate for your distribution:
sudo apt install nsd
nsd
has 2 configuration files that are important. First is /etc/nsd/nsd.conf
, which configures the nsd
daemon itself. Let's do this one first. If there's an existing config file here, move it aside and then paste in something like this:
server:
port: 5353
server-count: 1
username: nsd
logfile: "/var/log/nsd.log"
pidfile: "/run/nsd.pid"
# The zonefile directive(s) below is prefixed by this path
zonesdir: /etc/nsd/zones
zone:
name: example.com
zonefile: example.com.zone
...replace example.com
with the domain name that you want the authoritative DNS server to serve DNS records for. You can also have multiple zone:
blocks for different (sub)domains - even if those domain names are subdomains of others.
For example, I could have a zone:
block for both example.com
and dyn.example.com
. This can be useful if you want to run your own dynamic DNS server, which will write out a full DNS zone file (a file that contains DNS records) without regard to any other DNS records that might have been in that DNS zone.
Replace also 5353
with the port you want nsd
to listen on. In my case I have my authoritative DNS server running on the same box as the regular recursive resolver, so I've had to move the authoritative DNS server aside to a different port as dnsmasq
(the recursive DNS server I have running on this particular box) has already taken port 53
.
Next up, create the directory /etc/nsd/zones
, and then open up example.com.zone
for editing inside that new directory. In here, we will put the actual DNS records we want nsd
to serve.
The format of this file is governed by RFC1035 section 5 and RFC1034 section 3.6.1, but the nsd docs provide a simpler example. See also the wikipedia page on DNS zone files.
Here's an example:
; example.com.
$TTL 300
example.com. IN SOA a.root-servers.net. admin.example.com. (
2022090501 ; Serial
3H ; refresh after 3 hours
1H ; retry after 1 hour
1W ; expire after 1 week
1D) ; minimum TTL of 1 day
; Name Server
IN NS dns.example.com.
@ IN A 5.196.73.75
example.com. IN AAAA 2001:41d0:e:74b::1
www IN CNAME @
ci IN CNAME @
Some notes about the format to help you understand it:
- Make sure ALL your fully-qualified domain names have the trailing dot at the end otherwise you'll have a bad day.
$TTL 300
specifies the default TTL (Time To Live, or the time DNS records can be cached for) in seconds for all subsequent DNS records.- Replace
example.com.
with your domain name. admin.example.com.
should be the email address of the person responsible for the DNS zone file, with the@
replaced with adot
instead.dns.example.com.
in theNS
record must be set to the domain name of the authoritative DNS server serving the zone file.@ IN A 5.196.73.75
is the format for defining an A record (see the introduction to this blog post) forexample.com.
-@
is automatically replaced with the domain name in question - in this caseexample.com.
- When declaring a record, if you don't add the trailing dot then it is assumed you're referring to a subdomain of the domain this DNS zone file is for - e.g. if you put
www
it assumes you meanwww.example.com.
Once you're done, all that's left for configuring nsd
is to start it up for the first time (and on boot). Do that like so:
sudo systemctl restart nsd
sudo systemctl enable nsd
Now, you should be able to query it to test it. I like to use dig
for this:
dig -p 5353 +short @dns.example.com example.com
...this should return a result based on the DNS zone file you defined above. Replace 5353
with the port number your authoritative DNS server is running on, or omit -p 5353
altogether if it's running on port 53
.
Try it out by updating your DNS zone file and reloading nsd
: sudo systemctl reload nsd
Congratulations! You now have an authoritative DNS server under your control! This does not mean that it will be queried by any other DNS servers on your network though - read on.....
Integration with the rest of your network
The final part of this post will cover integrating an authoritative DNS server with another DNS server on your network - usually a recursive one. How you do this will vary depending on the target DNS server you want to convince to talk to your authoritative DNS server.
For Unbound:
I've actually covered this in a previous blog post. Simply update /etc/unbound/unbound.conf
with a new block like this:
forward-zone:
name: "example.com."
forward-addr: 127.0.0.1@5353
...where example.com.
is the domain name to forward for (WITH THE TRAILING DOT; and all subdomains thereof), 127.0.0.1
is the IP address of the authoritative DNS server, and 5353
is the port number of the authoritative DNS server.
Then, restart Unbound like so:
sudo systemctl restart unbound
For dnsmasq:
Dnsmasq's main config file is located at /etc/dnsmasq.conf
, but there may be other config files located in /etc/dnsmasq.d/
that might interfere. Either way, update dnsmasq
's config file with this directive:
server=/example.com./127.0.0.1#5353
...where example.com.
is the domain name to forward for (WITH THE TRAILING DOT; and all subdomains thereof), 127.0.0.1
is the IP address of the authoritative DNS server, and 5353
is the port number of the authoritative DNS server.
If there's another server=/example.com./...
directive elsewhere in your dnsmasq config, it may override your new definition.
Then, restart dnsmasq
like so:
sudo systemctl restart dnsmasq
If there's another DNS server that I haven't included here that you use, please leave a comment on how to reconfigure it to forward a specific domain name to a different DNS server.
Conclusion
In this post, I've talked about the difference between an authoritative DNS server and a recursive resolving DNS server. I've shown why authoritative DNS servers are useful, and alluded to reasons why running your own authoritative DNS server can be beneficial.
In the second post in this 2-part miniseries, I'm going to go into detail on dynamic DNS, why it's useful, and how to set up a dynamic dns server.
As always, this blog post is a starting point - not an ending point. DNS is a surprisingly deep subject: from DNS root hint files to mDNS (multicast DNS) to the various different DNS record types, there are many interesting and useful things to learn about it.
After all, it's always DNS..... especially when you don't think it is.
Sources and further reading
- Learn your terminal
- Cluster, Part 3: Laying groundwork with Unbound as a DNS server
- Root hints - a collection of operational and configuration FAQs
- DNS Root Servers - IANA
- What is a DNS record? - Cloudflare
- DNS cache poisoning - Cloudflare
- Multicast DNS
- DNS servers:
- Bind9 [complicated to configure]
- Unbound [my favourite; also known for being secure I think]
- nsd [my favourite; sibling of Unbound - they work very well together]
- dnsmasq [haven't had much experience with it, but great when it works]
- systemd-resolved [recursive; it always breaks for me so I don't use it]
- DNS Zone files:
- Wikipedia
nsd
docs- Official spec: RFC1035 section 5 and RFC1034 section 3.6.1