Hi John, > 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.
With bind, I am a novice. However with ansible, I would put myself closer to an expert as I have written a couple of my own modules for the lack of it being it in the included in the base modules of ansible. I am well aware of all of the under the hood components and have reviewed this entire role for exactly what it does under the hood, so no worries there. Any defaults that are not wanted/needed will be over ridden with exactly what we want. > 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? We are starting to automate everything in our network that makes sense to automate. Ansible was chosen because I have reviewed the source code for most of it as it was written in python which is something I understand. We have also test driven it for all of our network infrastructure ( originally a network architect ), linux server instances, and hypervisor clusters. It works well, is very extendable, and also has a very good active developer community being Red Hat folks maintain it. > 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? They have been good for the organization so far which is why we are staying with bind. The problem is that they are running on Centos 5/6 which is no longer maintained. And bind itself on each server is 9.(9-11) which are also EoL so we need to get these up to date and spec. > 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. I honestly couldn’t tell you either way as I have not even begun to start to dive into DNSSEC. > 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. Ansible does work and has been proven in our environment over the course of several months use starting in the lab and then moved to production. It has not once done anything we have not told it to do on any platform we have tested it on, plain and simple. 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. > 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). This is what we were currently planning on as the current setup does not have the master in the zone itself. > 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. My past experience with BlueCat has been less than stellar. We spoke with Infoblox about an IPAM system as well. Their prices are way too high for simply tracking IPs/Prefixes in a database which as all we really need it for. We settled on netbox for our IPAM solution instead since it’s free, open source so we can review the code, and is written in python which is something I understand very well. It also has an ansible module that can be used to maintain it. I understand you are seemingly anti-automation by your comments, but I would have to argue that we have personally vetted ansible over the course of several months. Again, it has not one time done anything we have not told it to do. I suspect many that learn ansible/insert automation platform name here/etc, then trust the modules and only take the elements they need and put them in the “playbooks” without fully reading the entire scope of the module taking the defaults into account. We fully understand every line of code we put into our playbooks as well as all of the options in the modules, test it first hand against something in the lab, and only then roll it out to production. The process 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 <john.b...@rrcic.com> 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.) > > <grin> > > John > > Sent from Nine <http://www.9folders.com/> > From: "N. Max Pierson" <nmaxpier...@gmail.com> > 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 > <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 > <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
_______________________________________________ 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
