Building an Authoritative DNS Infrastructure with Knot DNS
In this guide, we will build a highly available authoritative DNS infrastructure using Knot DNS, a high-performance authoritative DNS server developed by CZ.NIC.
Before diving into the deployment, it is worth understanding what an authoritative DNS server is and how it fits into the DNS ecosystem.
What Is an Authoritative DNS Server?
DNS servers generally fall into three categories:
- Authoritative servers
- Recursive resolvers
- Forwarders
An authoritative DNS server stores the DNS records for one or more zones and serves as the source of truth for those zones. Whenever a client requests a DNS record, the final answer ultimately comes from an authoritative server.
Today, there are roughly 380 to 390 million registered domain names on the Internet. When subdomains are included, the total number of DNS zones is even larger. Clearly, it would be impractical for every Internet-connected device to maintain a complete database of all existing zones and their authoritative name servers.
To solve this scalability problem, the Domain Name System relies on a hierarchical architecture.
At the top of the hierarchy sits the root zone (.), which delegates authority to Top-Level Domains (TLDs) such as .com, .net, .org, or country-code TLDs like .fr. Each TLD is further divided into individual domains, which may themselves contain subdomains.
Every DNS zone contains NS (Name Server) records that delegate authority for its child zones to other authoritative name servers. Rather than answering every possible query, each level of the hierarchy simply directs clients toward the next authoritative server responsible for the requested name.
Today, the root zone is served by 13 logical root server identifiers (A through M). Although only 13 identifiers exist, each one is deployed globally using Anycast, resulting in hundreds of physical servers distributed around the world. The root zone is publicly available and contains every Internet TLD along with the authoritative name servers responsible for each of them.
Most TLDs are managed by organizations known as registries. For example, in France, AFNIC manages the .fr TLD as well as several other French extensions such as .paris and .re. The registry's authoritative servers store the NS delegations for every domain registered under their respective TLD.
These NS records usually point to DNS servers operated by a registrar or a managed DNS provider. However, nothing prevents you from operating your own authoritative DNS servers and delegating your domain directly to them.
How DNS Resolution Works
The resolution process for the domain example.com can be summarized as follows:
You can observe this delegation chain yourself using:
dig example.com +trace
In practice, end-user devices rarely perform this iterative resolution themselves. Instead, they query a recursive resolver, which walks the DNS hierarchy on their behalf. Once the answer has been obtained, the resolver temporarily stores it in its cache so that future requests can be answered much faster.
The lifetime of a cached record is determined by its TTL (Time To Live), expressed in seconds.
Finally, another type of DNS server commonly encountered is the forwarder. Unlike a recursive resolver, a forwarder does not perform the resolution process itself. Instead, it simply forwards DNS queries to one or more upstream DNS servers and returns the responses to the client.
Forwarders are commonly deployed in enterprise environments. A typical configuration forwards requests for internal domains to the organization's authoritative DNS servers while sending all other queries to a public or internal recursive resolver. This approach allows internal DNS namespaces to coexist seamlessly with the public Internet.
Installing Knot DNS
Knot DNS can be installed directly from the official CZ.NIC package repositories. Installation instructions for all supported Linux distributions are available on the project's documentation website.
Before starting the installation, ensure that no other service is already listening on port 53. On Debian and Ubuntu systems, this typically means disabling systemd-resolved, which binds to the DNS port by default.
If you encounter a port conflict, you can identify the process currently using port 53 with:
ss -tunlp | grep :53
Once identified, stop or disable the conflicting service using systemctl or, if necessary, terminate it with pkill.
Configuring Knot DNS
In this example, we will deploy two authoritative DNS servers:
ns1 : 192.0.2.1
ns2 : 192.0.2.2
The main Knot configuration file is located at:
/etc/knot/knot.conf
The following configuration provides a minimal but functional starting point for both servers.
server:
rundir: "/run/knot"
user: knot:knot
automatic-acl: on
listen: [ 0.0.0.0@53, ::@53 ]
database:
storage: "/var/lib/knot"
template:
- id: default
storage: "/var/lib/knot"
file: "%s.zone"
log:
- target: syslog
any: info
This configuration instructs Knot to:
- listen on both IPv4 and IPv6,
- store zone files under /var/lib/knot,
- use a default template for all zones,
- and send operational logs to syslog.
Next, declare the DNS zones that the server will host. In this example, we will create a single authoritative zone named homelab.it.
zone:
- domain: homelab.it
The corresponding zone file can then be created in /var/lib/knot/homelab.it.zone.
@ 3600 IN SOA ns1.homelab.it. admin.homelab.it. 2026053000 1800 900 604800 60
@ 60 IN NS ns1.homelab.it.
@ 60 IN NS ns2.homelab.it.
ns1 60 IN A 192.0.2.1
ns2 60 IN A 192.0.2.2
The zone currently contains only the records required for a functional authoritative DNS service:
- an SOA (Start of Authority) record describing the zone,
- two NS records identifying the authoritative name servers,
- and one A record for each name server.
After creating the zone file, reload the Knot configuration.
knotc reload
At this point, both DNS servers are fully authoritative for homelab.it. However, any future modification would have to be performed manually on both servers, which quickly becomes difficult to maintain.
In the next section, we will configure automatic master–slave synchronization using AXFR, allowing all zone changes to be performed on a single server while the secondary server stays synchronized automatically.
Configuring Master–Slave Replication
The configuration we have built so far works correctly, but it has one major drawback: every zone modification must be applied manually on both DNS servers.
As the number of zones or authoritative servers grows, this approach quickly becomes difficult to maintain.
Fortunately, DNS provides a standardized mechanism for synchronizing zones between authoritative servers: AXFR (Authoritative Zone Transfer), defined in RFC 5936.
An AXFR transfer allows a secondary DNS server to retrieve the complete contents of a zone from its primary server. In our deployment, ns1 will act as the primary server, while ns2 will automatically synchronize its copy of the homelab.it zone.
A zone transfer can be initiated in two ways:
- The secondary server periodically checks whether the zone has changed by issuing a refresh request.
- The primary server sends a DNS NOTIFY message whenever the zone is updated, prompting the secondary server to perform an immediate synchronization.
The second approach provides much faster propagation of zone updates and is the one used throughout this guide.
Configuring the Primary Server (ns1)
Begin by creating a TSIG key that will authenticate zone transfers.
key:
- id: tsig-transfer
algorithm: hmac-sha256
secret: "abcd" # Generate with: openssl rand -base64 32
Next, create an ACL allowing ns2 to request zone transfers using this key.
acl:
- id: ns2-sync
address: 192.0.2.2
key: tsig-transfer
Declare the secondary server as a remote peer.
remote:
- id: ns2
address: 192.0.2.2
key: tsig-transfer
Finally, enable notifications and authorize zone transfers for the homelab.it zone.
zone:
- domain: homelab.it
acl: ns2-sync
notify: ns2
Whenever the zone is modified, ns1 will automatically send a DNS NOTIFY message to ns2, informing it that a newer version of the zone is available.
Configuring the Secondary Server (ns2)
The secondary server uses the same TSIG secret to authenticate the primary server before accepting zone transfers.
key:
- id: tsig-transfer
algorithm: hmac-sha256
secret: "abcd"
Declare the primary server as a remote.
remote:
- id: ns1
address: 192.0.2.1
key: tsig-transfer
Finally, configure the homelab.it zone as a slave of ns1.
zone:
- domain: homelab.it
master: ns1
Once the configuration has been updated, reload Knot on both servers.
knotc reload
Testing Zone Synchronization
To verify that replication is working correctly, add a new record to the zone file on ns1.
toto IN A 1.2.3.4
However, simply adding a record is not enough.
Before a secondary server performs a zone transfer, it compares the SOA serial number of its local copy with the serial advertised by the primary server. A transfer is triggered only if the serial number has increased.
The serial number is the first numeric field of the SOA record:
@ IN SOA ns1.homelab.it. admin.homelab.it. 2026053000 1800 900 604800 60
After modifying the zone, increment the serial number.
@ IN SOA ns1.homelab.it. admin.homelab.it. 2026053001 1800 900 604800 60
Reload Knot on the primary server.
knotc reload
Within a few seconds, ns2 should receive the notification and automatically start an AXFR transfer.
You can monitor this process by following the Knot logs on the secondary server.
journalctl -u knot -f
A successful synchronization produces messages similar to:
May 30 18:12:28 ns2 knotd[468792]: info: [homelab.it.] notify, incoming, remote 192.0.2.1@38950, serial 2026053001
May 30 18:12:28 ns2 knotd[468792]: info: [homelab.it.] refresh, remote 192.0.2.1@53, remote serial 2026053001, zone is outdated
Finally, verify that the new record has been replicated by querying the secondary server directly.
dig toto.homelab.it @192.0.2.2
If the synchronization completed successfully, the secondary server should return the newly created record.
At this stage, ns2 is no longer managed manually. Every modification made on ns1 is automatically propagated through authenticated AXFR transfers, ensuring that both authoritative servers always serve an identical copy of the zone.
Going Further
Although this guide uses a private DNS zone for demonstration purposes, the exact same architecture can be deployed on the public Internet.
If you own a registered domain name, you can deploy two lightweight VPS instances, install Knot DNS on both servers, and configure them as your domain's authoritative name servers. Once the infrastructure is in place, simply update the NS records at your domain registrar to point to your own servers.
This gives you full control over your DNS infrastructure while eliminating the need to rely on a managed DNS provider.
From there, several improvements can be made depending on your requirements:
- DNSSEC to provide cryptographic authentication of DNS responses.
- Dynamic DNS (RFC 2136) for automated record management.
- IPv6 support for both authoritative servers.
- Anycast to distribute the same DNS service across multiple geographic locations.
- Observability using Prometheus and Grafana to monitor query rates, latency, and server health.
- Hidden primary architectures, where the primary server is never exposed publicly and only the secondary servers answer client queries.
Together, these features allow you to build a highly available, secure, and scalable authoritative DNS infrastructure suitable for both homelab environments and production deployments.
