Thanks so much for the response.
This machine does not have any reasons to do recursive queries to
the Internet, and it is not allowed in the firewall.
Looks like the article quoted is the guidance I was looking for. This
server has "notify no", AND all of the name servers are in the
authoritative
zones anyway. And it has no need to ever do DNSSEC validation. I wonder
if
the traffic I was seeing was solely due to trust anchor maintenance. If
I
turn off dnssec-validation, will that traffic go away without having to
become master for root? I'll give that a try.
None of the other cases in the article apply. All zones are "secondary"
(except the fake root if I need to keep that). The DNSSEC arguments seem
kind of circular. You need to allow recursive behavior to support
DNSSEC,
and DNSSEC is needed to support recursive behavior.
Interesting that you bring up the case of non-Internet root. We do have
networks like that too. The authoritative-only DNS servers there should
have analogous configuration. We shouldn't need to put that network's
root in the authoritative-only servers or enable DNSSEC...
Although this did remind me of one reason to enable dnssec-validation
for totally non-technical reasons. Compliance. For when the auditors
come
around. It's easier to just have dnssec-validation enabled rather than
deal
with getting security exceptions or adverse findings. It's
(unfortunately)
a _really_ good reason to enable it even if it is technically
unnecessary.
On 2024-03-28 01:04, Greg Choules wrote:
Hi cjc.
My answers would be:
- Leave `dnssec-validation` alone (auto) and ensure your server has a
path
to the Internet to make queries.
- 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.
- 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.
As for why authoritative servers need to make queries at all, please
take a
look at this article.
https://kb.isc.org/docs/why-does-my-authoritative-server-make-recursive-queries
Hope that helps.
Greg
On Thu, 28 Mar 2024 at 06:15, Crist Clark <cjc+bind-us...@pumpky.net>
wrote:
I am upgrading and redeploying some authoritative-only BIND servers.
Two
questions about some fine points:
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?
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,
zone "." {
type primary;
file "primary/empty-zone.db";
allow-query { none; };
};
Which seems to do the trick, but is that the cleanest way? Any
problems
with that approach that I haven't considered?
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?
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support
subscriptions. Contact us at https://www.isc.org/contact/ for more
information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
