Conversation
| primary: "lr-e.b.isi.edu" | ||
| primary: "lr-w.b.isi.edu" | ||
| primary: "lr-lax.b.isi.edu" | ||
| primary: "b.root-servers.net" |
There was a problem hiding this comment.
In Appendix A of RFC8806:
It is possible that ICANN or some of the root server operators will turn off the AXFR capability on the servers listed above.
That means the only two reliable sources are:
There was a problem hiding this comment.
I'm unconvinced that's any more or less reliable, since it's possible that any of them will turn it off. As noted on https://localroot.isi.edu/about/, ISI and the listed root servers "have promised us they will continue to do so for the forseeable future". Regardless, with multiple sources and fallback enabled, breakage is highly unlikely. It will retrieve the zone from a different endpoint or, if all endpoints stop offering the service, fall back to normal queries. Meanwhile, an OPNsense update can improve the list if that became necessary.
| zonefile: "/var/unbound/local_root.zone" | ||
|
|
||
| auth-zone: | ||
| name: "arpa." |
There was a problem hiding this comment.
Technically that zone exists here:
https://www.dns.icann.org/services/axfr/
But the RFC8806 only recommends caching the root zone (.) itself.
There are also additional zones available that this does not configure, so either it should be generic and people can choose which of the available AXFR sources they want to cache locally, or it should be as close as possible to the RFC recommendation (only root zone).
There was a problem hiding this comment.
This is true, the root zone is the largest of these. These are the three zones recommended by ISI, but only doing the root zone would be fine, too.
| @@ -0,0 +1,62 @@ | |||
| {% if not helpers.empty('OPNsense.unboundplus.advanced.hyperlocalroot') %} | |||
| auth-zone: | |||
There was a problem hiding this comment.
If auth-zone's are the feature we want to offer, auth-zone is likely the option we should add. lists of currently known addresses are usually not a great idea as it obscures intentions and is quite inflexible.
Over time we slowly tried to move away from static "magic" values with simple checkboxes, unbound might still have some which we would gladly like to remove in that case.
There was a problem hiding this comment.
This is true as when comparing it to the RFC quite some shift has already happened. A generic auth-zone implementation would be the way to go.
There was a problem hiding this comment.
That seems reasonable -- and then perhaps documentation on using that feature to configure hyperlocal roots in the UI?
There was a problem hiding this comment.
Yeah that would be the best approach. Here is an example how implementing a new UI page usually goes, it's mostly boilerplate:
3 participants
RFC 8806 recommends running a local replica of the root zone (and localroot.isi.edu advocates additional zones) in order to provide improved performance and privacy for users of a recursive resolver. By fetching the full zone once (via AXFR) and periodically updating it (via IXFR), recursives generate less load on the root servers and satisfy their own queries more quickly.
This adds a checkbox in the Advanced section of the Unbound config that, if checked, injects the appropriate config to host local copies of
.,.arpa., and.root-servers.net..