Re: Some Authoritative-Only BCPs

2024-04-02 Thread Greg Choules via bind-users
Hi Crist.
Firstly, DNS servers do not make recursive queries, unless they have been
configured to forward.
Secondly, please start a packet capture on your server (save to disc, so
you can analyse it later in Wireshark) then start BIND and make some test
queries to your server. Look at what your server is doing as it starts and
as you make queries to it. It *will* need Internet access and you should
permit this in your firewall - port 53, both UDP and TCP.

As for the question of DNSSEC validation - yes or no? There is more DNSSEC
around these days than there used to be and choosing to NOT do validation
will hurt you in future, or maybe even right now. My advice would be to
enable it, look at packet captures, ask questions and understand it, rather
than disable it because you don't think you need it.

Cheers, Greg.

On Sun, 31 Mar 2024 at 08:07, Crist Clark  wrote:

> 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 
> > 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";
> >>   

Re: Some Authoritative-Only BCPs

2024-03-31 Thread Crist Clark

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  
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


Re: Some Authoritative-Only BCPs

2024-03-28 Thread Mark Andrews
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. 

-- 
Mark Andrews

> On 28 Mar 2024, at 19:04, Greg Choules via bind-users 
>  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  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
-- 
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


Re: Some Authoritative-Only BCPs

2024-03-28 Thread Greg Choules via bind-users
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  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


Some Authoritative-Only BCPs

2024-03-28 Thread Crist Clark
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