Adding root servers as local secondary zone to local caching server

Charles Sharp charles at cocosolutions.com
Thu Sep 2 13:27:30 UTC 2021


Thanks to all who responded, just the kind of info I was interested in...

So, sounds like, while it will work, and as long as reasonable
precautions are taken (that I would always take anyway, like making sure
the FS doesn't fill up, that would be a total noob mistake), it should
be fine, the benefits are minuscule for any system that has a decent
connection.

So, one last question. I know this may just be a personal preference, but...

Do most of you use the root hints or forwarders?

I currently use the following, in order:

1.1.1.1
9.9.9.9
8.8.8.8

Thanks again!

Charles


On 9/2/2021 7:45 AM, Chriztoffer Hansen via Unbound-users wrote
> On Thu, 2 Sept 2021 at 13:23, Joe Abley wrote:
>> Both of these aspects are known to suffer from operational problems from time to time.
>>
>> Filesystems can fill up, permissions can be changed accidentally, and other things can cause files not to be able to written to disk in a way that is not always obvious to notice, since DNS resolver software is often capable of running just fine without write access to filesystems.
> Agreed. Monitoring is always essential.
>
>> The ability to perform a zone transfer from a particular destination can also fail in ways that will not be obvious for long periods of time. There are no sources of the root zone by AXFR that are specified by the IETF and those that are available are often attached to anycast addresses that are not the best architectural choice for stateful transactions. The use of other protocols to transfer the root zone is also somewhat operationally novel.
> The availability is there, and never likely to get included in a BCP /
> RFC document. (Maybe into a draft, thou not likely a draft adopted by
> a WG?)
>
>> Note that in many cases this is an insignificant optimisation. The round-trip penalty to obtain a referral to the NL servers (your example) is often amortised over many billions of subsequent queries and quickly trends towards zero. The ability to avoid looking up names which result in NXDOMAIN responses from the root zone can be optimised using aggressive NSEC caching in a way that avoids the operational risks alluded to above.
>>
>> To me, even though the risks of failure through caching a local copy of the root zone are low, the benefits are lower, and it is not something I would choose to do. This risk assessment belongs in the hands of the operator, though, and it's certainly legitimate for other people to find a different balance.
> It the operators choice, indeed.
>
> If ones resolver is recently well connected to well-connected
> upstreams/transit/ixp's. The benefits are indeed very very low. And
> the benefits are negligible down to non-existent.
>
> If one is hanging on a single upstream which is not well connected or
> ones upstreams are of varying consistency/quality resulting in poor
> user experience due to "significant" load time consumed by DNS
> lookups. "Some" improvement could be gained by caching zone
> information locally.
> Thou, likely a DNS resolver which does speculative lookups on the most
> popular DNS names ahead of the resolvers internal cache entry expering
> might be a better choice. [0]
>
> [0]: https://knot-resolver.readthedocs.io/en/stable/modules-predict.html
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20210902/0148364c/attachment.htm>


More information about the Unbound-users mailing list