Re: securing bind in todays hostile environment

[Tony Finch]

Grant Taylor via bind-users  wrote:
> On 1/20/20 9:06 AM, N. Max Pierson wrote:
>
> > I was not aware there was anything built in that would let you
> > add/remove/change the zone itself from the master.
>
> Yes, Catalog Zones.  I think it's only a few years old.

Catalog zones are for automatic configuration of secondaries. There is
also the older rndc addzone/modzone/delzone feature which can manage
masters as well as secondaries.

The newzone feature either stores the dynamic config in a text file
(a named.conf fragment) or if you have lots of zones it can use LMDB.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Humber, Thames, Dover: Variable 2 to 4. Smooth or slight. Fog patches.
Moderate or good, occasionally very poor.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: securing bind in todays hostile environment

[Grant Taylor via bind-users]

On 1/20/20 9:06 AM, N. Max Pierson wrote:
My terminology seems to be the issue here, so let me try and 
rephrase/elaborate : )


;-)

I was not aware there was anything built in that would let you 
add/remove/change the zone itself from the master.


Yes, Catalog Zones.  I think it's only a few years old.

Is this feature basically some sort of named.conf synchronization 
utility?


No.  It's actually quit a bit nicer than that.

Catalog Zones are a way for a BIND slave server to read a zone and learn 
what zones it should be a slave for and where the master servers are 
along with other related metadata.


You add a new zone as a (series of) record(s) to the catalog zone, which 
is a standard zone used for the catalog purpose.  The slave uses 
standard zone transfers from the master(s), reads the catalog zone, and 
then dynamically re-configures itself to add / remove zone(s) as necessary.


The current setup needs to be touched should a new zone need to be added 
or removed today.


No config files get updated.  Obviously, the typical slave zone files 
will get created / written to as you would expect.


It’s certainly not required and not really wanted personally but 
having the master with a public IP (doing a no nat for that host in the 
FW policy) on the inside would be a snowflake as everything else has 
RFC1918 on it behind the firewall (IPv4 that is). Not that that’s a 
deal breaker, I just would have to get sign-off from others. The reason I 
had for having it in the DMZ is so that one would have to penetrate the 
FW to get to the master for any changes to be made.


That makes sense.

And this FW would next-gen with for high level of scrutiny which IPtables 
can’t give.


I question that statement, because that's the type of person that I am 
and the type of thing I question.  (More what you have been told, than 
questioning you as the messenger.)


So all of the slaves would be answering for public/external domains. No 
internal will exist on them nor the master. Very simple setup without 
any views currently, so the slaves are copies of the master. Forward 
and reverse would be treated the same, sorry if I mis-spoke.


ACK

See previous. I think what I meant to say was that the recursive servers 
be locked down via ACL at 2 different layers. Not the authoritative, 
again my apologies.


That makes more sense.  Thank you for clarifying.

Thanks for the quick and dirty on RPZ. I knew what it was and how it works 
somewhat but was not aware the scope of the vars and functions that act 
upon them to be so flexible. The functions allow me to return/manipulate 
the response at what seems like a pretty granular level. I need to read 
up on exactly what each response does in totality but I get a good guess 
from their name/description.


:-)

Again I appreciate the detail in your response. It makes me feel a little 
better about managing our own instances versus handing it off to some 
other cloud provider.


:-D



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: securing bind in todays hostile environment

[N. Max Pierson]

Ah, allow me to apologize then. Since I did not see any mention as to why you 
possibly didn’t think ansible would serve us well for this job I had wrongly 
assumed you to had maybe demo’d or just got handed the task of automating in 
your organization and didn’t have time to research or test it before go live, 
causing a bad experience from it possibly. 

The idea for ansible in this case would be to simply manage the zones for us on 
record changes which allowed me to come up with a front end so our customers 
would have self service for the ones that do not pay us to manage their zone 
for them. Trying not to have to re-invent the wheel and write some sort of API 
that did some sort of regex nightmare in shell against the zones, etc for 
simple changes. I can much more easily write a form that generates YML I need 
with the data. The next step is to actually interface with ansible at the API 
level to remove the having to generate YML and run cli commands all together, 
but I’m only one person and coding isn’t even more area of expertise, so in 
time lol.

Yes I have been a part of that same boat a few times myself elsewhere but 
fortunately where I am now, they seem to understand if I make them more money, 
it has to work both ways. They agreed so the arrangement is working quite well 
and I appreciate the remark. 

regards,
m

> On Jan 19, 2020, at 2:01 PM, John W. Blue  wrote:
> 
> Since it sounds like you have not had much experience with, I urge you to 
> check it out should you have anything in your environment that could benefit 
> from automation. Simply telling someone to chunk it and not have any 
> experience with it is a little misguided IMO.
>  
> We pay multiple different teams to play in the ansible, docker, kubernetes et 
> al sandbox so, yeah, I admittedly do *need* to have much experience.  My 
> comments are not an indictment against ansible itself because I observe it 
> being used to create basic servers on a regular basis.  It does a fantastic 
> job.  Rather I was questioning the use of ansible to specifically deploy DNS 
> servers.
> 
> Since you updated your comments to mention that you all are selling DNS 
> services, the choice of ansible now makes more sense.
> 
> I've worked in the MSP space in the past and my general observation is that 
> it is a sweat shop with no loyalty in a race to the bottom of how low of a 
> salary they can get away with paying.  I genuinely hope your experience will 
> be different.
> 
> John
> 
> Sent from Nine 
> 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: securing bind in todays hostile environment

[N. Max Pierson]

My terminology seems to be the issue here, so let me try and rephrase/elaborate 
: )

> I'm sure that you can get Ansible to add / remove / modify the list of zones 
> on the slave servers.  But is that the best solution when BIND has something 
> built in for doing the same thing?

I was not aware there was anything built in that would let you 
add/remove/change the zone itself from the master. Is this feature basically 
some sort of named.conf synchronization utility? The current setup needs to be 
touched should a new zone need to be added or removed today.

> At least I would evaluate if it's reasonably possible to do. Is the added 
> complexity of NAT /required/ -> /needed/ -> /desired/?

It’s certainly not required and not really wanted personally but having the 
master with a public IP (doing a no nat for that host in the FW policy) on the 
inside would be a snowflake as everything else has RFC1918 on it behind the 
firewall (IPv4 that is). Not that that’s a deal breaker, I just would have to 
get sign-off from others. The reason I had for having it in the DMZ is so that 
one would have to penetrate the FW to get to the master for any changes to be 
made. And this FW would next-gen with for high level of scrutiny which IPtables 
can’t give. 

> I'm failing to understand why the /reverse/ zones have more security than 
> /other/ zones.

So all of the slaves would be answering for public/external domains. No 
internal will exist on them nor the master. Very simple setup without any views 
currently, so the slaves are copies of the master. Forward and reverse would be 
treated the same, sorry if I mis-spoke.

> I would still expect the scope of access to be the same for forward and 
> reverse zones.

See previous. I think what I meant to say was that the recursive servers be 
locked down via ACL at 2 different layers. Not the authoritative, again my 
apologies.

Thanks for the quick and dirty on RPZ. I knew what it was and how it works 
somewhat but was not aware the scope of the vars and functions that act upon 
them to be so flexible. The functions allow me to return/manipulate the 
response at what seems like a pretty granular level. I need to read up on 
exactly what each response does in totality but I get a good guess from their 
name/description. 

Again I appreciate the detail in your response. It makes me feel a little 
better about managing our own instances versus handing it off to some other 
cloud provider. 

Regards,
m

> On Jan 19, 2020, at 11:23 AM, Grant Taylor via bind-users 
>  wrote:
> 
> On 1/19/20 3:25 AM, N. Max Pierson wrote:
>> Hi Grant,
> 
> Hi,
> 
>> I should have been a little more descriptive in the scenario by giving the 
>> purpose of these name servers. They are basically being deployed as a 
>> managed DNS service that we offer. We are a MSP for the most part and the 
>> DNS infrastructure was not being very well maintained when I got here. 
>> Knowing that and the fact we sell this as a service, it needs more attention 
>> that it has gotten in the past plus someone with more knowledge than the 
>> ones that originally set them up. Having that said, I have my work cut out 
>> for me.
> 
> Fair enough.
> 
> With that in mind, I'm speculating that the list of zones (in scope) will be 
> somewhat dynamic.  As such, I *STRONGLY* encourage you to take a look at 
> catalog zones.
> 
> I'm sure that you can get Ansible to add / remove / modify the list of zones 
> on the slave servers.  But is that the best solution when BIND has something 
> built in for doing the same thing?
> 
>> We do not use dynamic entries and as far as the hidden/shadow master, I do 
>> not have an issue with the master being on the public segment and part of 
>> the NS records. I was thinking of simply poking a hole in the firewall to a 
>> static NAT for the master (restricted by the slave IPs) so that it could be 
>> contacted from the outside. I would have the master in the DMZ. Since this 
>> isn’t being used for any internal name services, I guess it may not make 
>> much sense to have it in the DMZ.
> 
> If the master is functionally identical to the slaves, save for the master vs 
> slave configuration, then it probably can live with the slaves.  However, if 
> the master has any other data / configuration / internal DB access / etc, I 
> would recommend that it be separated.
> 
> I like to think of slave servers in the DMZ as a line of defense for the 
> master.  Sometimes it's appropriate, sometimes it isn't.
> 
> I don't know your network topology.  But I'd be tempted to see if I could use 
> standard routing in lieu of NAT between the slaves and the master.  At least 
> I would evaluate if it's reasonably possible to do. Is the added complexity 
> of NAT /required/ -> /needed/ -> /desired/?  The same questions should be 
> asked about routing, and chose the appropriate answer.
> 
>> Paranoia I guess lol.
> 
> Hum.
> 
> I'm failing to understand why the /reverse/ zones have more security 

Re: securing bind in todays hostile environment

[John W. Blue]

Since it sounds like you have not had much experience with, I urge you to check 
it out should you have anything in your environment that could benefit from 
automation. Simply telling someone to chunk it and not have any experience with 
it is a little misguided IMO.



We pay multiple different teams to play in the ansible, docker, kubernetes et 
al sandbox so, yeah, I admittedly do *need* to have much experience.  My 
comments are not an indictment against ansible itself because I observe it 
being used to create basic servers on a regular basis.  It does a fantastic 
job.  Rather I was questioning the use of ansible to specifically deploy DNS 
servers.

Since you updated your comments to mention that you all are selling DNS 
services, the choice of ansible now makes more sense.

I've worked in the MSP space in the past and my general observation is that it 
is a sweat shop with no loyalty in a race to the bottom of how low of a salary 
they can get away with paying.  I genuinely hope your experience will be 
different.

John

Sent from Nine



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: securing bind in todays hostile environment

[Grant Taylor via bind-users]

On 1/19/20 4:01 AM, N. Max Pierson wrote:
I honestly couldn’t tell you either way as I have not even begun 
to start to dive into DNSSEC.


I can recommend the following book from Michael W. Lucas / @mwlauthor 
and say that it provides a good, actionable, introduction to DNSSEC.


Link - DNSSEC Mastery: Securing the Domain Name Service with BIND (ebook)
 - 
https://www.tiltedwindmillpress.com/product/dnssec-mastery-securing-the-domain-name-service-with-bind-ebook/


Disclaimer:  I'm not associated with Michael.  We do pester each other 
on Twitter.  I have tech reviewed some of his other book.


I've found all of his Mastery books to be packed with actionable 
information and well worth the price (< $20).


I prefer to buy the books directly from Michael's site, Tilted Windmill 
Press, to avoid the overhead & fees with thee other typical outlets.


Word to the wise:  Be mindful of the recent SHA1 chosen prefix attacks 
when starting with DNSSEC.  This mostly means that you just choose 
other, newer, algorithms to use when deploying DNSSEC.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: securing bind in todays hostile environment

[Grant Taylor via bind-users]

On 1/19/20 3:25 AM, N. Max Pierson wrote:

Hi Grant,


Hi,

I should have been a little more descriptive in the scenario by giving 
the purpose of these name servers. They are basically being deployed 
as a managed DNS service that we offer. We are a MSP for the most 
part and the DNS infrastructure was not being very well maintained 
when I got here. Knowing that and the fact we sell this as a service, 
it needs more attention that it has gotten in the past plus someone 
with more knowledge than the ones that originally set them up. Having 
that said, I have my work cut out for me.


Fair enough.

With that in mind, I'm speculating that the list of zones (in scope) 
will be somewhat dynamic.  As such, I *STRONGLY* encourage you to take a 
look at catalog zones.


I'm sure that you can get Ansible to add / remove / modify the list of 
zones on the slave servers.  But is that the best solution when BIND has 
something built in for doing the same thing?


We do not use dynamic entries and as far as the hidden/shadow master, 
I do not have an issue with the master being on the public segment 
and part of the NS records. I was thinking of simply poking a hole in 
the firewall to a static NAT for the master (restricted by the slave 
IPs) so that it could be contacted from the outside. I would have the 
master in the DMZ. Since this isn’t being used for any internal name 
services, I guess it may not make much sense to have it in the DMZ.


If the master is functionally identical to the slaves, save for the 
master vs slave configuration, then it probably can live with the 
slaves.  However, if the master has any other data / configuration / 
internal DB access / etc, I would recommend that it be separated.


I like to think of slave servers in the DMZ as a line of defense for the 
master.  Sometimes it's appropriate, sometimes it isn't.


I don't know your network topology.  But I'd be tempted to see if I 
could use standard routing in lieu of NAT between the slaves and the 
master.  At least I would evaluate if it's reasonably possible to do. 
Is the added complexity of NAT /required/ -> /needed/ -> /desired/?  The 
same questions should be asked about routing, and chose the appropriate 
answer.



Paranoia I guess lol.


Hum.

I'm failing to understand why the /reverse/ zones have more security 
than /other/ zones.


I guess I should mention that I'm assuming that you're talking about 
in-addr.arpa zones for reverse DNS of globally routed IPs.  As such, I 
would think that (at least the slave) servers should be accessible for 
the world to query.


I should have mentioned said servers will have proper IPtables 
configured but will not have a formal next-gen firewall appliance in 
front of it. Even though we do implement some sort of packet filter 
for access to the services, I also tell bind to only respond to 
certain sources as well. Possibly overkill and more administrative 
work but I always go back to the “security in layers” train off 
thought. And since we use ansible for management, the second argument 
is sort of moot.


Sure.  Multiple levels of defense is a good thing.  I'm an advocate for 
closing and latching every picket fence gate.


I'm still pondering if the zones are public or private and what the 
scope of access /should/ be.


I would still expect the scope of access to be the same for forward and 
reverse zones.


Your strategy for putting the old resolver IPs as loopbacks on the 
new servers is a spiffy idea that I had not thought of before. That 
would make life easier as it could be queried by the interface IP for 
new users should we want to use the new IP and the old users would 
still just work because of the loopback. And we actually have each 
server on it’s own /29 or /64 (due to VRRP) so the actual IPs are 
very easily movable.


:-)

As or the RPZ, I understood how it works at a high level but have never 
had the experience in using it. I was not aware the blackhole mechanism 
was also provided by it ( i had assumed they could send responses to 
something like /dev/null which Im guessing is now wrong ), so I do 
need to correct my self and state that we will need them because I 
intend on implementing filtering at that level since it is available.


Ah.  Response Policy Zones are — in my (not so) humble opinion — wonderful!

Depending on the version of BIND in question, you can do (at least) the 
following:


 · Return an NXDOMAIN for a QUNAME with ".".
 · Return a NODATA for a QNAME with "*.".
 · Return the response unmodified with "rpz-passthru.".
 · Drop the response with "rpz-drop.".
 · Truncate the response with "rpz-tcp-only.".
 · Replace the response with local data.

You can trigger the above actions based on (at least) the following 
criteria:


 · QNAME
 · IP in response
 · Client IP
 · Name Server Name
 · Name Server IP

The following page on Zytrax's site is one of my favorites for RPZ info. 
 I actually quite like Zytrax's site for all things BIND related.


Link 

Re: securing bind in todays hostile environment

[N. Max Pierson]

cess has been proven and repeated many times over again saving the 
organization a ton of money by not having to hire additional help for my group 
as well as other groups (not to mention a little increase in my pay, but not 
really relevant to the conversation). 

Quite simply, it works if you deploy and utilize it correctly.

Thanks for the response!

Regards,
m



> On Jan 18, 2020, at 8:53 PM, John W. Blue  wrote:
> 
> Some things to think about ..
> 
> 1.  What is your/teams plan B to fix this type of ansible environment should 
> it get horked up?  There is a ton of stuff that is being configured for you 
> all under the hood and by your own admission your a novice.  The laws of 
> unintended consequences apply.
> 
> 2.  Why is the decision being made to go with a "solution" using ansible?  Is 
> it because software devs are being asked to do double duty as DDI admins?  I 
> know that "devops" is what all the cool kids are talking about these days but 
> are you all honestly willing to trust a core infrastructure to automation?
> 
> 3.  (slightly different phrasing) What problem does this plan solve?  
> Assuming the existing DNS servers are doing the job for the organization and 
> running the current BIND release why change?
> 
> 4.  When I read that they called DNSSEC an authentication method I checked 
> out.  They dont know what they are talking about.  DNSSEC is  a validation 
> method.
> 
> In the absence of more detailed design goals I would recommend that you all 
> chunk the ansible  plan and go with what works and is proven.
> 
> Using a hidden master either for external or internal or both is a good plan 
> to defend against cache poisoning (we do) but only enable DNSSEC on your 
> external zone(s).
> 
> If you use a split horizon consider naming your servers in such a manner so 
> that it obvious which is which when you all drive off into the 
> troubleshooting weeds.
> 
> Depending on the size of your organization, editing zone files to add remove 
> resource records by hand is a painful existence if there is daily changes.  
> Do yourself and everyone that comes after you a favor and invest in a legit 
> IPAM solution from either Infoblox or Bluecat.  I prefer Infoblox but both 
> can administrate BIND and Microsoft DNS servers.  Plus you get the ability to 
> tag up metadata which is good to recall why something was done.
> 
> Final word:  no way in the world would I ever sign off on a system that 
> leaves me/my team holding the email-is-down bag due to a DNS outage caused by 
> a poorly designed system.
> 
> Been there .. done that.  No bueno.
> 
> (final, final word: if you still want to live in ansible  I would suggest 
> that you add another NIC to each server and assume the IPs of the old servers 
> so you dont bring cruft forward into your new world order.)
> 
> 
> 
> John
> 
> Sent from Nine <http://www.9folders.com/>
> From: "N. Max Pierson" 
> Sent: Saturday, January 18, 2020 8:08 AM
> To: bind-users@lists.isc.org
> Subject: securing bind in todays hostile environment
> 
> Hi List,
> 
> First off, I should note that I am a novice with administering Bind, so 
> please bear with me. 
> 
> We are looking to be more pro-active and security minded in our network in 
> general and while we are getting ready to completely replace/upgrade our 
> current instances of Bind, I would like to hear of opinions of the following 
> ansible role that would install, setup, configure, etc our instances taking 
> security into account. I have read some of the common best practices on this 
> very list over time but wanted to ensure what was in this role wasn't missing 
> anything in terms of securing the deployment. 
> 
> So I am aware it’s preferred to split recursive and authoritative services 
> across different instances. I also understand it’s preferred to use one of 
> the “out of zone” (apologies for not knowing the proper terminology) master 
> methods (such as hidden or shadow master). It’s also a very good idea to 
> deploy TSIG for transaction signing. And of course, ACL recursive lookups as 
> well as AXFRs. Beyond that, what other best practices should be considered 
> when making a deployment such as the following scenario ….
> 
> ns1 - ns4: authoritative name servers - slaves
> ns0 - hidden/shadow master
> 
> old ns1- ns4: will be used as recursive as these were deployed doing both 
> authoritative and recursive many years ago and policy routing for these old 
> IPs is very ugly, so we would like to keep them there after an upgrade as 
> opposed to try and figure out who’s still using them to notify we’re changing 
> the IPs
> 
> 
> The ansible role can be seen here at https:

Re: securing bind in todays hostile environment

[N. Max Pierson]

Hi Grant,

A couple of things ….

I should have been a little more descriptive in the scenario by giving the 
purpose of these name servers. They are basically being deployed as a managed 
DNS service that we offer. We are a MSP for the most part and the DNS 
infrastructure was not being very well maintained when I got here. Knowing that 
and the fact we sell this as a service, it needs more attention that it has 
gotten in the past plus someone with more knowledge than the ones that 
originally set them up. Having that said, I have my work cut out for me.

> One thing that I couldn't tell from your description is if you need to 
> support dynamic updates from clients. 


We do not use dynamic entries and as far as the hidden/shadow master, I do not 
have an issue with the master being on the public segment and part of the NS 
records. I was thinking of simply poking a hole in the firewall to a static NAT 
for the master (restricted by the slave IPs) so that it could be contacted from 
the outside. I would have the master in the DMZ. Since this isn’t being used 
for any internal name services, I guess it may not make much sense to have it 
in the DMZ.

> Why do you want to ACL /recursive/ lookups? 

Paranoia I guess lol. I should have mentioned said servers will have proper 
IPtables configured but will not have a formal next-gen firewall appliance in 
front of it. Even though we do implement some sort of packet filter for access 
to the services, I also tell bind to only respond to certain sources as well. 
Possibly overkill and more administrative work but I always go back to the 
“security in layers” train off thought. And since we use ansible for 
management, the second argument is sort of moot.

> Another option to avoid PBR and mass client changes is to use traditional 
> routing to get to the ns1–ns4 IPs.


Your strategy for putting the old resolver IPs as loopbacks on the new servers 
is a spiffy idea that I had not thought of before. That would make life easier 
as it could be queried by the interface IP for new users should we want to use 
the new IP and the old users would still just work because of the loopback. And 
we actually have each server on it’s own /29 or /64 (due to VRRP) so the actual 
IPs are very easily movable.

> How are you doing the black hole if not with RPZ?


As or the RPZ, I understood how it works at a high level but have never had the 
experience in using it. I was not aware the blackhole mechanism was also 
provided by it ( i had assumed they could send responses to something like 
/dev/null which Im guessing is now wrong ), so I do need to correct my self and 
state that we will need them because I intend on implementing filtering at that 
level since it is available. 

As for the rest, some of them would not apply since these are public servicing 
name servers and not internal. The rest of the suggestions will certainly be 
researched more so that I can fully understand how to implement them should 
they apply to our deployment. 

Thanks for the lengthy and descriptive response. It gives me several things to 
think about and research.

Regards,
m


> On Jan 18, 2020, at 11:59 AM, Grant Taylor via bind-users 
>  wrote:
> 
> On 1/18/20 7:06 AM, N. Max Pierson wrote:
>> Hi List,
> 
> Hi M,
> 
>> First off, I should note that I am a novice with administering Bind, so 
>> please bear with me.
> 
> We all started somewhere.  Hopefully we all continue to learn new things.  ;-)
> 
>> We are looking to be more pro-active and security minded in our network in 
>> general and while we are getting ready to completely replace/upgrade our 
>> current instances of Bind, I would like to hear of opinions of the following 
>> ansible role that would install, setup, configure, etc our instances taking 
>> security into account. I have read some of the common best practices on this 
>> very list over time but wanted to ensure what was in this role wasn't 
>> missing anything in terms of securing the deployment.
> 
> «hat tip»
> 
>> So I am aware it’s preferred to split recursive and authoritative services 
>> across different instances.
> 
> Yes, that's the ideal design.  Unfortunately that doesn't always scale down 
> to where some people need it.  It quickly starts to be more complexity for 
> smaller networks, particularly SOHO networks.  :-/
> 
> My current understanding is that if the server is accessible from the 
> Internet, then it probably really should have the recursive and authoritative 
> roles separated.  If it's not accessible from the Internet, then it's more up 
> to your discretion of what makes sense for your network.
> 
> My preference for smaller networks that may have multiple servers but don't 
> warrant separate servers is to have multiple recursive servers slave internal 
> zones off of the internal authoritative master.
> 
>> I also understand it’s preferred to use one of the “out of zone” (apologies 
>> for not knowing the proper terminology) master methods 

Re: securing bind in todays hostile environment

[John W. Blue]

Some things to think about ..

1.  What is your/teams plan B to fix this type of ansible environment should it 
get horked up?  There is a ton of stuff that is being configured for you all 
under the hood and by your own admission your a novice.  The laws of unintended 
consequences apply.

2.  Why is the decision being made to go with a "solution" using ansible?  Is 
it because software devs are being asked to do double duty as DDI admins?  I 
know that "devops" is what all the cool kids are talking about these days but 
are you all honestly willing to trust a core infrastructure to automation?

3.  (slightly different phrasing) What problem does this plan solve?  Assuming 
the existing DNS servers are doing the job for the organization and running the 
current BIND release why change?

4.  When I read that they called DNSSEC an authentication method I checked out. 
 They dont know what they are talking about.  DNSSEC is  a validation method.

In the absence of more detailed design goals I would recommend that you all 
chunk the ansible  plan and go with what works and is proven.

Using a hidden master either for external or internal or both is a good plan to 
defend against cache poisoning (we do) but only enable DNSSEC on your external 
zone(s).

If you use a split horizon consider naming your servers in such a manner so 
that it obvious which is which when you all drive off into the troubleshooting 
weeds.

Depending on the size of your organization, editing zone files to add remove 
resource records by hand is a painful existence if there is daily changes.  Do 
yourself and everyone that comes after you a favor and invest in a legit IPAM 
solution from either Infoblox or Bluecat.  I prefer Infoblox but both can 
administrate BIND and Microsoft DNS servers.  Plus you get the ability to tag 
up metadata which is good to recall why something was done.

Final word:  no way in the world would I ever sign off on a system that leaves 
me/my team holding the email-is-down bag due to a DNS outage caused by a poorly 
designed system.

Been there .. done that.  No bueno.

(final, final word: if you still want to live in ansible  I would suggest that 
you add another NIC to each server and assume the IPs of the old servers so you 
dont bring cruft forward into your new world order.)



John

Sent from Nine<http://www.9folders.com/>

From: "N. Max Pierson" 
Sent: Saturday, January 18, 2020 8:08 AM
To: bind-users@lists.isc.org
Subject: securing bind in todays hostile environment

Hi List,

First off, I should note that I am a novice with administering Bind, so please 
bear with me.

We are looking to be more pro-active and security minded in our network in 
general and while we are getting ready to completely replace/upgrade our 
current instances of Bind, I would like to hear of opinions of the following 
ansible role that would install, setup, configure, etc our instances taking 
security into account. I have read some of the common best practices on this 
very list over time but wanted to ensure what was in this role wasn't missing 
anything in terms of securing the deployment.

So I am aware it's preferred to split recursive and authoritative services 
across different instances. I also understand it's preferred to use one of the 
"out of zone" (apologies for not knowing the proper terminology) master methods 
(such as hidden or shadow master). It's also a very good idea to deploy TSIG 
for transaction signing. And of course, ACL recursive lookups as well as AXFRs. 
Beyond that, what other best practices should be considered when making a 
deployment such as the following scenario 

ns1 - ns4: authoritative name servers - slaves
ns0 - hidden/shadow master

old ns1- ns4: will be used as recursive as these were deployed doing both 
authoritative and recursive many years ago and policy routing for these old IPs 
is very ugly, so we would like to keep them there after an upgrade as opposed 
to try and figure out who's still using them to notify we're changing the IPs


The ansible role can be seen here at https://github.com/juju4/ansible-bind . So 
you don't have to click on the link, what this role does to secure bind in 
summary is as follows:

- Secure template from Team Cymru template 
(http://www.cymru.com/Documents/secure-bind-template.html). Please note than 
separated internal/external views are not implemented currently.
- DNSSEC for authentication,
- RPZ to whitelist/blacklist entries
- Malware domains list blackholed
- Eventual integration with MISP RPZ export
- Authoritative DNS (mostly for internal zones) Mostly as cache/forwarder but 
could be other roles.

Taking into consideration what I have already learned plus the few things above 
mentioned on GitHub (mainly the security template and malware domain blackhole 
as we do not use RPZ or Views), is there anything else that should be 
considered/added/changed/remove

Re: securing bind in todays hostile environment

[Grant Taylor via bind-users]

On 1/18/20 7:06 AM, N. Max Pierson wrote:

Hi List,


Hi M,

First off, I should note that I am a novice with administering Bind, so 
please bear with me.


We all started somewhere.  Hopefully we all continue to learn new 
things.  ;-)


We are looking to be more pro-active and security minded in our network 
in general and while we are getting ready to completely replace/upgrade 
our current instances of Bind, I would like to hear of opinions of the 
following ansible role that would install, setup, configure, etc our 
instances taking security into account. I have read some of the common 
best practices on this very list over time but wanted to ensure what was 
in this role wasn't missing anything in terms of securing the deployment.


«hat tip»

So I am aware it’s preferred to split recursive and authoritative 
services across different instances.


Yes, that's the ideal design.  Unfortunately that doesn't always scale 
down to where some people need it.  It quickly starts to be more 
complexity for smaller networks, particularly SOHO networks.  :-/


My current understanding is that if the server is accessible from the 
Internet, then it probably really should have the recursive and 
authoritative roles separated.  If it's not accessible from the 
Internet, then it's more up to your discretion of what makes sense for 
your network.


My preference for smaller networks that may have multiple servers but 
don't warrant separate servers is to have multiple recursive servers 
slave internal zones off of the internal authoritative master.


I also understand it’s preferred to use one of the “out of zone” 
(apologies for not knowing the proper terminology) master methods (such 
as hidden or shadow master).


I do think it's a good idea to separate recursive servers for clients 
from the master server for the internal zones.  If this is possible in 
your network.  I don't have any reason to hide the master or prevent 
clients from being able to communicate with it.  In fact, clients may 
/need/ to communicate with the master.  I see no reason not to list the 
master as an additional NS record in the zone.


One thing that I couldn't tell from your description is if you need to 
support dynamic updates from clients.  I.e. Windows workstations 
updating DNS based on new DHCP lessees, et al.  This has some 
complications in that the last time I dealt with this, the workstations 
sent their DDNS updates to the master, thus needed to be able to 
communicate with the master.


It’s also a very good idea to deploy TSIG for transaction 
signing. And of course, ACL recursive lookups as well as AXFRs.


Why do you want to ACL /recursive/ lookups?  Why single out /recursive/ 
for additional protection?  I'd think that you would want to apply the 
same protection to all DNS server access.  Possibly with a belt and 
suspenders method with the BIND and host firewalls / routing.


Beyond that, what other best practices should be considered when 
making a deployment such as the following scenario ….


ns1 - ns4: authoritative name servers - slaves
ns0 - hidden/shadow master

old ns1- ns4: will be used as recursive as these were deployed doing 
both authoritative and recursive many years ago and policy routing for 
these old IPs is very ugly, so we would like to keep them there after an 
upgrade as opposed to try and figure out who’s still using them to 
notify we’re changing the IPs


Another option to avoid PBR and mass client changes is to use 
traditional routing to get to the ns1–ns4 IPs.  Bind said IPs to a 
loopback / dummy interface on the DNS servers and rely on the networking 
to route to these /32 / /128 IPs.  You effectively turn these IPs into 
Service / Virtual IPs that you can move around your network as you see 
fit.  Of course, this does rely on a routed L3 boundary between your 
clients and ns1–ns4 IPs.  But I'm guessing you already have that.


The ansible role can be seen here at 
https://github.com/juju4/ansible-bind . So you don’t have to click on 
the link, what this role does to secure bind in summary is as follows:


- Secure template from Team Cymru template 
(http://www.cymru.com/Documents/secure-bind-template.html). Please note 
than separated internal/external views are not implemented currently.

- DNSSEC for authentication,
- RPZ to whitelist/blacklist entries
- Malware domains list blackholed


How are you doing the black hole if not with RPZ?

Remember, you can have multiple RPZ zones, as well as RPZ white lists to 
override subsequent RPZ black lists.



- Eventual integration with MISP RPZ export


I would probably plan for this at deployment time.  Possibly with a stub 
empty (save for requisite zone metadata records) from the start.  Then 
you can simply replace that stub zone with actual MISP content when 
you're ready to do so.


- Authoritative DNS (mostly for internal zones) Mostly as 
cache/forwarder but could be other roles.


Taking into consideration what I have already learned 

securing bind in todays hostile environment

[N. Max Pierson]

Hi List,

First off, I should note that I am a novice with administering Bind, so please 
bear with me. 

We are looking to be more pro-active and security minded in our network in 
general and while we are getting ready to completely replace/upgrade our 
current instances of Bind, I would like to hear of opinions of the following 
ansible role that would install, setup, configure, etc our instances taking 
security into account. I have read some of the common best practices on this 
very list over time but wanted to ensure what was in this role wasn't missing 
anything in terms of securing the deployment. 

So I am aware it’s preferred to split recursive and authoritative services 
across different instances. I also understand it’s preferred to use one of the 
“out of zone” (apologies for not knowing the proper terminology) master methods 
(such as hidden or shadow master). It’s also a very good idea to deploy TSIG 
for transaction signing. And of course, ACL recursive lookups as well as AXFRs. 
Beyond that, what other best practices should be considered when making a 
deployment such as the following scenario ….

ns1 - ns4: authoritative name servers - slaves
ns0 - hidden/shadow master

old ns1- ns4: will be used as recursive as these were deployed doing both 
authoritative and recursive many years ago and policy routing for these old IPs 
is very ugly, so we would like to keep them there after an upgrade as opposed 
to try and figure out who’s still using them to notify we’re changing the IPs


The ansible role can be seen here at https://github.com/juju4/ansible-bind 
 . So you don’t have to click on the 
link, what this role does to secure bind in summary is as follows:

- Secure template from Team Cymru template 
(http://www.cymru.com/Documents/secure-bind-template.html). Please note than 
separated internal/external views are not implemented currently.
- DNSSEC for authentication,
- RPZ to whitelist/blacklist entries
- Malware domains list blackholed
- Eventual integration with MISP RPZ export
- Authoritative DNS (mostly for internal zones) Mostly as cache/forwarder but 
could be other roles.

Taking into consideration what I have already learned plus the few things above 
mentioned on GitHub (mainly the security template and malware domain blackhole 
as we do not use RPZ or Views), is there anything else that should be 
considered/added/changed/removed to/from the defaults of this role when we go 
to deploy the above scenario? 

TIA,
m___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users