<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Also authoritative servers lookup information.  This includes addresses of nameservers to send NOTIFY messages. DS queries as part of DNSSEC key management. DNSKEY queries as part of DNSSEC trust anchor management.  Plus whatever else is required to resolve those queries. <br><br><div dir="ltr">-- <div>Mark Andrews</div></div><div dir="ltr"><br><blockquote type="cite">On 28 Mar 2024, at 19:04, Greg Choules via bind-users <bind-users@lists.isc.org> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr">Hi cjc.<div>My answers would be:</div><div><br></div><div>- Leave `dnssec-validation` alone (auto) and ensure your server has a path to the Internet to make queries.</div><div><br></div><div>- Don't mess with root hints. The only time anyone should need to do this is when running a completely captive server living in a custom namespace that is NOT the Internet.</div><div><br></div><div>- I don't know if "none" and "!all" work out to be the same thing in code terms, but my preference would be "none" anyway because 1) that's what's in the documentation and would be the obvious choice, and 2) why deliberately create a negated expression that is harder to parse, mentally? Glancing through a config and seeing "...!all..." you may not notice the "!" and just see the "all". Even if you do see the pling, a statement containing it reads something like "I would like to permit not all", which requires some thinking about the intent. Whereas "I would like to permit none" (for me anyway) is clearer and less ambiguous.</div><div><br></div><div>As for why authoritative servers need to make queries at all, please take a look at this article. <a href="https://kb.isc.org/docs/why-does-my-authoritative-server-make-recursive-queries">https://kb.isc.org/docs/why-does-my-authoritative-server-make-recursive-queries</a></div><div><br></div><div>Hope that helps.</div><div>Greg</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 28 Mar 2024 at 06:15, Crist Clark <<a href="mailto:cjc%2Bbind-users@pumpky.net">cjc+bind-users@pumpky.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I am upgrading and redeploying some authoritative-only BIND servers. Two questions about some fine points:<div><br></div><div>What to set 'dnssec-validation'? Just let it default to 'auto?' There is no need or opportunity for an authoritative-only server to validate (right?). Should we actively switch it off, set it to 'no?' For example, does setting it to 'no' reduce any resource use or reduce the security vulnerability space?</div><div><br></div><div>This is bordering on aesthetic (maybe the first one is too), but what to do about the compiled-in root hints? Even on my authoritative-only server with "recursion no," every forty-five minutes or so, it's trying to go to the root servers and retrieve the NS and DNSKEY RRs for the root. It's blocked since there is no reason for this server to do outbound DNS, except to its hidden masters, so it just keeps trying and cluttering the firewall logs. What's the best way to stop this behavior? Is there a configuration option? I did this,</div><div><br></div><div>zone "." {</div><div>    type primary;</div><div>    file "primary/empty-zone.db";</div><div>    allow-query { none; };</div><div>};</div><div><br></div><div>Which seems to do the trick, but is that the cleanest way? Any problems with that approach that I haven't considered?</div><div><br></div><div>Oh, one final bonus question, is there any difference between specifying 'none' and '!all' in a server list, ACL, etc.? I prefer 'none', but the old configurations used '!all'. Can I change those without worrying?</div></div>
-- <br>
Visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
<br>
ISC funds the development of this software with paid support subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer" target="_blank">https://www.isc.org/contact/</a> for more information.<br>
<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote></div>
<span>-- </span><br><span>Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list</span><br><span></span><br><span>ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.</span><br><span></span><br><span></span><br><span>bind-users mailing list</span><br><span>bind-users@lists.isc.org</span><br><span>https://lists.isc.org/mailman/listinfo/bind-users</span><br></div></blockquote></body></html>