Ansible Role for BIND

calendar Feb 8, 2020 · 3 min read · isc bind copr redhat ansible role centos  ·
Share on: linkedin copy

I've been playing around with the pre-packaged version of BIND that ISC trialled in the COPR project last year. I often deal with organisations that heavily rely on pre-canned packages. ISC's official packages allow these organisations to maintain parity with the current state of BIND without changing the way they manage their infrastructure. So this initiative was very promising.

Empty Config

For some reason ISC in their wisdom have chosen to provide an empty or nearly empty config file for this packaged version of BIND. I think there was a post explaining their reasoning, which I skimmed and quickly forgot about. The baked in defaults are actually pretty good these days, so you're left with a server that will provide basic functionality. But it's still a bit of a shock and you will need to do a lot of updating to meet your goals.

Where'd That Conf File Go?

The packaged versions do have a few quirks. Here's some highlights:

  1. The package is called isc-bind not named or bind as you might expect. The service is called isc-bind-named.
  2. The configuration file is located at:
1/etc/opt/isc/isc-bind/named.conf # RHEL/CentOS 6/7
2/etc/opt/isc/scls/isc-bind/named.conf #  RHEL/CentOS 8, Fedora
  1. The standard utilities installed with BIND are only available in your shell after you run: scl enable isc-bind bash

These details and more information is all documented on ISC's COPR page.

I Just Want to Get Stuff Done

Ok, so there's some quirks and an empty config file. So how do we get a useful install of BIND that doesn't require an artists hand to configure? There's a few DNS related roles in Ansible Galaxy and if you're already familiar with them, you might update their source of package to use the COPR repositories. Those roles tend to be OS agnostic to some extent (maybe distro agnostic). For my purposes I just wanted to focus on the Redhat ecosystem and the official ISC packages. My ISC-BIND role focuses on sensible defaults. I've deliberately avoided re-creating the configuration options via Ansible variables.

What Kind of DNS Server Do I Need?

There's three rough server roles I'll be building.

I've deliberately made them exclusive per install, this is generally considered best practice. Here's the server roles I plan to automate:

  1. recursive: The most basic configuration with some simple default logging, AS112 zone file to prevent leaking private queries and stubs for RPZ subscriptions. I've also included rules to prevent DNS re-binding attacks. A typical home user will want to turn those rules off.
  2. primary: An idempotent configuration for a primary server that will sign its zones.
  3. secondary: A configuration to act as secondary server.

Role Repository

isc-bind If you follow the README the role is designed to be upgradeable without disrupting your running configuration.