About and Frequent Asked Questions
What is LocalRoot all about?
Our beta-level LocalRoot service allows you to:
- Keep a securely-obtained and locally-cached copy of the root zone in your resolvers
- Help distribute the root-zone's records within your network
- Locally implement a caching technology (like, but not equal to, RFC7706)
- Receive DNS notifications when the root zone changes
- Perform research about the DNS root zone
Why would I want to deploy LocalRoot?
The RFC7706 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 RFC7706 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.
It is important to note that this implementation violates suggestions from RFC7706 in a few ways, because RFC7706 recommends against actually slaving zones "Because of the significant operational risks described in this document, [...]. You should properly understand how to run a DNS recursive resolver before using the localRoot service.implementing this mechansims unless you have a valid need and
How does LocalRoot work?
LocalRoot works by adding a local, up-to-date, copy of the root zone data to your recursive resolver(s). This is also known as being a local slave of the root zone. 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 root zone data to only networks that already make use of your resolver. Specifically, you will not be an authoratative service for the root 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.
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).
- The root zone data itself is protected by DNSSEC, ensuring that the only authorized entity that can modify the data contents is IANA.
- 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.
What is a manual AXFR and why do you require it first?
An AXFR is a DNS operation that transfers the entire zone to the requester. We require one ahead of actually sending you DNS notifications to ensure that you control the IP address that you're registering. You can perform a manual DNS AXFR using the dig command line tool from your recursive resolver:
# dig @localroot.isi.edu . AXFR
Once this has been done, the Active column for your server should turn from an orange X () to a green checkmark () indicating we've seen an AXFR and will begin serving notifications to you.
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
LocalRoot Project Status
Why isn't this listed as a production service?
At this time, the service is an beta-level service to test the popularity of the service. We may migrate the service toward a production quality service if we receive enough positive feedback from users that would like us to offer it as a permenent service (keep reading).
What happens to me if you turn the service off?
In the extremely unlikely case we turn the service off (it's more likely we'll simply stop developing new features):
- You will be notified via your registered E-Mail address if we decide there is not enough popularity to warrant it continued operation.
- You SHOULD disable configuration making use of the service. But...
- 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 3 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 number of features and improvements that we expect to implement shortly:
- IXFR support -- for reducing bandwidth requirements
- Deletion support -- delete servers once they're no longer needed
- Last transfer seen -- display of the last transfer LocalRoot saw from your server(s).
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:
- Different notification levels: Only receive notifies when real zone data changes, or signature lifetimes need updating. This will let participants pull data only when needed.
- Mirroring of other TLDs -- A number of people have wanted caching of other critical zones too. Some TLD operators have been interested in adding their zones to the service.
- A REST API
- Group Ownership -- the ability for multiple accounts to edit the details of a server.
- Configuration snippets or instructions for other resolver software.
- Additional Upstream Servers -- right now there is only a single LocalRoot upstream server, but a longer term goal will be to add a number for redundancy.
How can I help this service become a production-level service?
- Give us positive feedback about the benifits of the service.
- If you wish to sponsor this project, we would gladly take donations to make the service permenently available and with features you wish to see implemented
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.