About and Frequent Asked Questions
What is LocalRoot all about?
Our 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, RFC8806)
- Receive DNS notifications when the root zone changes
- Perform research about the DNS root zone
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.
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 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).
- 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.
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):
- 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 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:
- Monitoring and E-Mail Notifications -- We will notify you when your instance is no longer transferring data from us.
- Mirroring of other zones -- Right now our LocalRoot service allows you to mirror the root zone, arpa, root-servers.net and dnssec-tools.org. A number of people have wanted caching of other critical zones too. If you believe you have a small-to-medium sized zone that you would like your clients to be able to mirror through the localroot service, please contact us.
- A REST API
- Group Ownership -- the ability for multiple accounts to edit the details of a server.
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.
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!).