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