<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Thanks to all who responded, just the kind of info I was interested
in...<br>
<br>
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.<br>
<br>
So, one last question. I know this may just be a personal
preference, but...<br>
<br>
Do most of you use the root hints or forwarders?<br>
<br>
I currently use the following, in order:<br>
<br>
1.1.1.1<br>
9.9.9.9<br>
8.8.8.8<br>
<br>
Thanks again!<br>
<br>
Charles<br>
<br>
<br>
<div class="moz-cite-prefix">On 9/2/2021 7:45 AM, Chriztoffer Hansen
via Unbound-users wrote<br>
</div>
<blockquote type="cite"
cite="mid:CA+cYV6sF9EzE05JOTjuXud-_-C-uu-od3Kx5BJ9chY6CWKzs3w@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">On Thu, 2 Sept 2021 at 13:23, Joe Abley wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Agreed. Monitoring is always essential.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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?)
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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]: <a class="moz-txt-link-freetext" href="https://knot-resolver.readthedocs.io/en/stable/modules-predict.html">https://knot-resolver.readthedocs.io/en/stable/modules-predict.html</a>
</pre>
</blockquote>
<br>
</body>
</html>