Configuration management of BIND .conf

[John Thurston]

Thirty years ago, we had a pretty simple DNS configuration; a couple of 
AIX servers configured as dual-purpose authorities and resolvers. Once 
it was set, the configuration didn't change much. But when it did, with 
two hosts, it was simple to rlogin to each and make similar mods to the 
config on each.

Today, we have many servers (currently on flavors of linux), offering 
split-horizon DNS for many zones through several views, across several 
networks. We've been doing fairly well keeping the configuration files 
clean and consistent, but 'private dns' is driving us to the breaking 
point. I'm looking for some way to to make this simpler and safer.

The issue is 'stub' and 'forward' zones. We are inundated with requests 
from developers who have created solutions which rely on us being able 
to resolve secret names (which can not be found from the roots), or to 
receive special values for public names (by querying specific, secret 
servers). I won't mention names, but one of the big offenders has the 
initials "Microsoft".

We can use catalog-zones to define secondary zones on our authorities. 
But AFAIK, catalog-zones can not define 'stub' or 'forward' zones on our 
resolvers, and must be defined in the .conf. There has got to be a safe 
and effective way to define a stub/forward zones across several resolvers.

I'm looking for your ideas. What works? What doesn't work?

Are you leveraging your existing configuration management tools (e.g. 
Puppet, Ansible, Chef)?

Have you rolled your own using git or rync?

Do you have a script to base64 an 'included' .conf into a TXT record, so 
it can be consumed elsewhere?


-- 
--
Do things because you should, not just because you can.

John Thurston    907-465-8591
John.Thurston at alaska.gov
Department of Administration
State of Alaska
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240924/6d392487/attachment.htm>