About and Frequent Asked Questions

What is LocalRoot all about?

Our LocalRoot service allows you to:

Why would I want to deploy LocalRoot?

The RFC8806 specification, defined within the DNSop working grop within the IETF defines a way to serve locally pre-cached root zone data to your local network. As RFC8806 states, the reason for doing this is typically to support lower latency requests for root-zone data. This is mostly beliveed to be of highest benefit over reduced bandwidth or high latency connections.

Is it a good idea?

There have been a lot of debates on this subject, with many different opinions. Generally, the motivations outlined in RFC8806 clearly explain the reasons why it might be beneficial. For LocalRoot itself, please do see the text at the bottom of this page about our commitments to the service. It is also worth noting that a number of major DNS providers and organizations do have RFC8806 support turned on internall, including (we believe) Google public DNS and Facebook.

How does LocalRoot work?

LocalRoot works by adding a local, up-to-date, copy of the root and other zone data to your recursive resolver(s). This is also known as being a local slave of the root and other zones. Your copy of the data is always up to date through the use of DNS notifies sent from LocalRoot servers to your resolver when root zone updates occur.

Does LocalRoot serve traffic outside my network ?

No. The LocalRoot service is only for you to use internal to your network. It is intended to allow you to serve zone data to only networks that already make use of your resolver. Specifically, you will not be an authoritative service for any zone outside your local network.

I'm in! How do I get started

Please see the Getting Started Page for instructions on how to deploy a LocalRoot copy in your network.

LocalRoot Security

How do I know that my copy of the root data is secure (authenticated)?

Two different methods exist to ensure the data you receive is secure from modification by external parties (e.g. a man-in-the-middle).

  1. The zone data itself is protected by DNSSEC, ensuring that the only authorized entity that can modify the data contents is the zone owner(in the case of the root zone, this is IANA).
  2. All transactions between the LocalRoot servers and your recursive resolvers are protected by TSIG DNS keys as well. This ensures you recieve notifications from or talk to unauthorized sources and destinations. This feature is unique to LocalRoot at this time

It is worth noting that because NS and address glue records are not signed, the use of TSIG is important to protect the transfer.

Deployment Questions

What if I'm using split-views?

If you are using views (eg, internal recursive and external authoratative), the configuration for the root zone copy will need to be put inside the internal view (i.e., inside any view where recursion is turned on).

How do I test that is working?

There are a number of things you can do, including studying the traffic with tools like tcpdump and wireshark. You can try this simple test on your recursive resolver as well to ensure the aa bit is set in the output: 

         # dig @localhost . SOA
         [... lots of other output deleted ...]
         ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 27

Additionally, you can see how fast the server responds when you send it a query for a non-existant TLD name that it would normally have to go query the real root servers for. It should answer with a very small query time:

         # dig @localhost notarealname ns
            [... lots of other output deleted ...]
            ;; Query time: 0 msec

Can I run a LocalRoot Server behind a firewall or NATed?

You can certainly run it in these scenerios, but to get the benefit of the update notifications, you'll need to allow incoming DNS notifies through and to the system that your LocalRoot is running on. Because name servers perform routine SOA checks to their upstream servers in case of missing a NOTIFY, it is safe to run a LocalRoot instance even if it never gets a DNS notification of an update. Your server will still ensure it's up to date on a regular basis with only a minor delay.

LocalRoot Project Status

What happens to me if you turn the service off?

ISI is committed to this service, as we are committed to pushing the DNS protocol forward and in new directions. In the extremely unlikely case we turn the service off (it's more likely we'll simply stop developing new features):

  1. You will be notified via your registered E-Mail address if we decide there is not enough popularity to warrant it continued operation.
  2. You SHOULD disable configuration making use of the service. But...
  3. We have structured the configuration we generate for you so that even if the service turns off, it should not affect you operationally. We list multiple other upstream root servers that have always offered AXFR transfer support and have promised us they will continue to do so for the forseeable future. This means you will likely not even notice if the Localroot service goes offline.

What's planned for the future of LocalRoot?

We have a long list of features under development. Some of the near term features include:

We have a number of other features that will only be implemented if the service proves to be beneficial to people and may be subject to needing sponsorship as well:

Who's responsible for this service?

Wes Hardaker created this service to provide a new avenue for research into DNS operations at the root level. Please contact him for suggestions, desires, complaints or to offer support of this project in any way (we love it when other people give talks about LocalRoot!).