Sunday, July 25, 2021

Running A Root Server Locally On Your DNS Resolver


A DNS recursive resolver is typically primed with a list of Root Servers which it uses to resolve queries. When the recursive resolver receives a query, it queries to one of the root servers to get back a list of top level domain (TLD) name servers. It then queries those TLD name servers to get back another list of name servers hosting the domain name. This process is done recursively until the an answer for the query is resolved.

The DNS recursive resolver maintains a cache to avoid frequent queries and thus improving its performance. However, when the cache expires or is flushed, the recursive resolution process is performed again.

During the recursive resolution process, there is a possibility that the response from root server is delayed due to network issues or other events like the root server being under a Denial of Service (DoS) attack. There could also be passive monitoring of DNS requests going to root servers by an on path actor compromising privacy.

To prevent these issues and to improve resiliency there is a good option to run a Root Server locally on your DNS resolver.

There are several advantages of running a Root Server locally:

  • The Root zone contains all the TLD name servers and their IP addresses. This allows the DNS resolver to skip the initial query to the Root Server and directly query to the TLD name servers saving time.
  • Since the Root zone is running locally, queries for non existent top level domain (TLD) names are resolved locally.
  • This also improves resiliency since the Root zone is local and thus there is no immediate dependency on the Root Servers for recursive resolution.

There are a few disadvantages too:

  • If there are any updates to the Root zone, it will take slightly longer for those changes to sync to your local Root zone. Though there wont be much of a noticeable issue.
  • If your local Root zone is not updating due to any reason and it was not detected, then the local Root zone will expire after 7 days (as per Root SOA Expiry). This may cause some DNS resolvers to fail to resolve any queries when cache expires. Technitium DNS Server however will fall back to root hints in such a case.

Considering both the advantages and disadvantages, its good to have a Root zone locally for a recursive resolver.

Sourcing The Root Zone

The root zone is available from ICANN DNS servers via zone transfer (AXFR-over-TCP):

  • (, 2620:0:2830:202::132)
  • (, 2620:0:2d0:202::132)

The following Root Servers also support zone transfer (AXFR-over-TCP):

  • (, 2001:500:200::b)
  • (, 2001:500:2::c)
  • (, 2001:500:2d::d)
  • (, 2001:500:2f::f)
  • (, 2001:500:12::d0d)
  • (, 2001:7fd::1)

It is recommended to have DNSSEC enabled on your DNS resolver. Use recursive ACL to make sure that your DNS resolver accepts queries only from known clients to protect from DNS amplification attacks.


To configure your DNS server, you just have to create a secondary zone for "." domain name which is a fully qualified domain name (FQDN) for the Root zone.

On Technitium DNS Server, configure the secondary zone as shown in the screenshot below:

Configuring Local Secondary Root Zone

Once you have the secondary zone created, wait for a few seconds for the DNS server to perform the zone transfer. The Root zone meanwhile will show as expired. If its taking a lot of time, do check the DNS server logs to see if there are any errors being logged.

After the secondary zone is synced, you will see all the root zone records. There are thousands of records and it may take a couple of seconds for the DNS panel to list all of them. Here is what you should see on the DNS panel:

Local Secondary Root Zone

Note: Having a locally configured Root zone will be always prefered over forwarders by the DNS server and thus any forwarders that are configured in Settings will be ignored.


If you have any queries do write in the comments section below or send an email to


  1. hello there, dear dev.
    i have a problem with technitium server on dhcp scope.
    windows client can't connect to my server because it can't get the ip address.
    i have tried with different devices and get the same result, not getting ip.

    but, the server is sending a DHCPOFFER to client and the client keep sending requests.
    it is as if the windows client didn't see the offer.

    it work okay with android phone and linux tho.

    is there way to fix this? is it a client problem or the dhcp server problem?

    thanks in advance and sorry for my messy english.

    1. Thanks for asking. It could be some config issue. Since linux and android clients are working so it seems you have configured windows firewall to allow udp 67 port. Do send a screenshot of you DHCP scope settings and your network adapter details to to get help.

  2. I really wish there was a way to delete stale DHCP leases. I just reserved IP's on a scope and technetium does not respect the IP you set in the reservation menu until the old lease has expired.

    I think that's ridiculous.

    Anyway, is there any plan to implement this feature? Maybe in an "advanced user" menu? Because every other DHCP server allows you to remove leases. Thanks.

    1. Thanks for the comment. I will try to add an option in next release.

  3. Is configuring TDNSS like this potentially more of a privacy issue? I use TDNSS for all devices on my local network (via DHCP). TDNSS then does DNS forwarding over DNS-over-TLS to Google and Quad9 so that DNS traffic doesn't leak out to my ISP and beyond.

    1. Thanks for asking. Threat model for each person or organization depends on whom they want to protect against. So, option in this blog post may suit for some scenarios while using encrypted DNS will suit for others.

      If your scenario is to protect privacy from your ISP then using encrypted DNS is a option for this. However, in such case your privacy is not safe from public DNS providers too.

      For protecting your privacy from both your ISP and public DNS providers, you can host your own encrypted DNS server using a cheap Linux hosting and then use that service as your encrypted DNS forwarder on your locally running DNS server.

      Another option is to use Tor and forward your traffic to public DNS providers but then its much better to use Tor for complete web browsing using Tor Browser.

      So make a choice as per your own privacy needs.

  4. Hi there,

    Does this technique can be applied to unbound as well?

    Also, do technitium folks have plans for an OpenWRT package of technitium dns? (I really hope so)


    1. Thanks for asking. You can run a root server locally using any DNS server software that supports hosting secondary zones. Unbound is recursive resolver with only limited support to host zones so I am not sure if it can host secondary zones.

      I don't have any device running OpenWRT to do any tests. Also I am not sure if it can run dotnet since the DNS server runs on it. It also depends on what ARM CPU version the device has since dotnet supports only v7 and above versions.