I am setting up bind this time around (just rebuilt my test machine via Kickstart) without chroot.
I have a fair number of includes for named.conf; I have two views and other odds and ends. My thoughts are to make a directory; /etc/named.d to put all these includes into instead of 'dirtying' up /etc. This way the only files I replace/add to /etc are named.conf and rndc.key (I would like to work the latter around to also be in named.d, but this impacts rndc itself).
Thoughts on this? Anyone else have a well segmented named.conf file?
On 02/15/2013 10:44 AM, Robert Moskowitz wrote:
I am setting up bind this time around (just rebuilt my test machine via Kickstart) without chroot.
I have a fair number of includes for named.conf; I have two views and other odds and ends. My thoughts are to make a directory; /etc/named.d to put all these includes into instead of 'dirtying' up /etc. This way the only files I replace/add to /etc are named.conf and rndc.key (I would like to work the latter around to also be in named.d, but this impacts rndc itself).
Thoughts on this? Anyone else have a well segmented named.conf file?
That's my line of thinking too. I normally have a pretty skeletal named.conf file, with all the heavy-lifting going on in files included from directory /etc/named.d. It seems to me that a more modular approach minimizes the impact of fat-fingering and generally makes it easier to change out chunks of configuration as needed. (named-checkconf is your friend!)
Just for reference, at my place of employment I'm running a "hidden master" server and two separate sets of slaves for internal and external access for about 60 separate forward and reverse zones. The named.conf file basically consists of a single "options" stanza followed by a series of include statements. The includes themselves have other files that they include, the tier depth is about four levels deep at most.
So far (knock on head) this has worked out fine for the last 8 years or so. Before that I was attempting to use a monolithic named.conf file and found it an absolute bear to maintain. Smaller pieces means smaller problems, once you've got the overall framework.
Just my $.02!
On 02/15/2013 12:31 PM, Jay Leafey wrote:
On 02/15/2013 10:44 AM, Robert Moskowitz wrote:
I am setting up bind this time around (just rebuilt my test machine via Kickstart) without chroot.
I have a fair number of includes for named.conf; I have two views and other odds and ends. My thoughts are to make a directory; /etc/named.d to put all these includes into instead of 'dirtying' up /etc. This way the only files I replace/add to /etc are named.conf and rndc.key (I would like to work the latter around to also be in named.d, but this impacts rndc itself).
Thoughts on this? Anyone else have a well segmented named.conf file?
That's my line of thinking too. I normally have a pretty skeletal named.conf file, with all the heavy-lifting going on in files included from directory /etc/named.d. It seems to me that a more modular approach minimizes the impact of fat-fingering and generally makes it easier to change out chunks of configuration as needed. (named-checkconf is your friend!)
I just completed setting it up and it is working. So far. Do have some things to clear up.
I do have a bit in my named.conf, like I have my views defined there with skeletal content (including root hints and rfc1912 for internal) and an include for the main view content. I suppose I could go more skeletal, but I am taking on enough new stuff right now.
Just for reference, at my place of employment I'm running a "hidden master" server and two separate sets of slaves for internal and external access for about 60 separate forward and reverse zones. The named.conf file basically consists of a single "options" stanza followed by a series of include statements. The includes themselves have other files that they include, the tier depth is about four levels deep at most.
So far (knock on head) this has worked out fine for the last 8 years or so. Before that I was attempting to use a monolithic named.conf file and found it an absolute bear to maintain. Smaller pieces means smaller problems, once you've got the overall framework.
Just my $.02!
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Fri, 2013-02-15 at 11:44 -0500, Robert Moskowitz wrote:
I am setting up bind this time around (just rebuilt my test machine via Kickstart) without chroot.
I have a fair number of includes for named.conf; I have two views and other odds and ends. My thoughts are to make a directory; /etc/named.d to put all these includes into instead of 'dirtying' up /etc. This way the only files I replace/add to /etc are named.conf and rndc.key (I would like to work the latter around to also be in named.d, but this impacts rndc itself).
There is an /etc/named directory included in the bind package, I assume that it is meant for this purpose... I just changed my config to use that (with the chroot package) as it get bind mount from the standard startup script Louis
On 02/15/2013 02:27 PM, Louis Lagendijk wrote:
On Fri, 2013-02-15 at 11:44 -0500, Robert Moskowitz wrote:
I am setting up bind this time around (just rebuilt my test machine via Kickstart) without chroot.
I have a fair number of includes for named.conf; I have two views and other odds and ends. My thoughts are to make a directory; /etc/named.d to put all these includes into instead of 'dirtying' up /etc. This way the only files I replace/add to /etc are named.conf and rndc.key (I would like to work the latter around to also be in named.d, but this impacts rndc itself).
There is an /etc/named directory included in the bind package, I assume that it is meant for this purpose...
It is for your zone files, not necessarily for your named.conf includes. Bind can write to this, and if your includes are there, in theory, more zones could be added to your domain.
I just changed my config to use that (with the chroot package) as it get bind mount from the standard startup script
The lastest part of this thread is me getting 'current' and moving from relying on chroot and following Redhat/NSA recommendation to just use selinux protection.
On Fri, Feb 15, 2013 at 2:47 PM, Robert Moskowitz rgm@htt-consult.comwrote:
On 02/15/2013 02:27 PM, Louis Lagendijk wrote:
On Fri, 2013-02-15 at 11:44 -0500, Robert Moskowitz wrote:
I am setting up bind this time around (just rebuilt my test machine via Kickstart) without chroot.
I have a fair number of includes for named.conf; I have two views and other odds and ends. My thoughts are to make a directory; /etc/named.d to put all these includes into instead of 'dirtying' up /etc. This way the only files I replace/add to /etc are named.conf and rndc.key (I would like to work the latter around to also be in named.d, but this impacts rndc itself).
There is an /etc/named directory included in the bind package, I assume that it is meant for this purpose...
It is for your zone files, not necessarily for your named.conf includes. Bind can write to this, and if your includes are there, in theory, more zones could be added to your domain.
The opposite.
named.conf resides in /etc/ I don't use /etc/named/ ... it isn't present on my CentOS 5 Bind DNS server. /etc/named/ is present since CentOS 6 came out. Zones in /var/named - old [0], newer [1], newest [2]
[0] http://centos.org/docs/2/rhl-rg-en-7.2/s1-bind-configuration.html [1] http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-bind-zone.html [2] https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/5/ht...
I just changed my config to use that (with the chroot package) as it get bind mount from the standard startup script
The lastest part of this thread is me getting 'current' and moving from relying on chroot and following Redhat/NSA recommendation to just use selinux protection.
Of course using a chroot will require the modification of paths in your config file, but the directory structure is similar. /var/named/chroot/var/named/ [2]
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Yes. I had things a bit wrong here.
On 02/18/2013 12:46 PM, SilverTip257 wrote:
On Fri, Feb 15, 2013 at 2:47 PM, Robert Moskowitz rgm@htt-consult.comwrote:
On 02/15/2013 02:27 PM, Louis Lagendijk wrote:
On Fri, 2013-02-15 at 11:44 -0500, Robert Moskowitz wrote:
I am setting up bind this time around (just rebuilt my test machine via Kickstart) without chroot.
I have a fair number of includes for named.conf; I have two views and other odds and ends. My thoughts are to make a directory; /etc/named.d to put all these includes into instead of 'dirtying' up /etc. This way the only files I replace/add to /etc are named.conf and rndc.key (I would like to work the latter around to also be in named.d, but this impacts rndc itself).
There is an /etc/named directory included in the bind package, I assume that it is meant for this purpose...
It is for your zone files, not necessarily for your named.conf includes. Bind can write to this, and if your includes are there, in theory, more zones could be added to your domain.
The opposite.
named.conf resides in /etc/ I don't use /etc/named/ ... it isn't present on my CentOS 5 Bind DNS server. /etc/named/ is present since CentOS 6 came out. Zones in /var/named - old [0], newer [1], newest [2]
I put my zone files into /var/named with it having a subdir for slaves.
I am reshaping my conf includes to go into /etc/named, rather than what I created /etc/name.d
There is significant lack of consistancy as to where things are kept under /etc
It seems there should be a better way so you don't have to change /etc/named.conf, but add files as needed to /etc/named but how is beyond me.
This system is also my internal ntp server, and my notes from what I set up 3 years ago are too thin, plus now I have IPv6 to support. /etc/ntp.conf takes a lot of customization. This is definitely a week to pretend to be a wizard and stay up late. Or maybe that is my problem; staying up too late last week! (Us 60+ yearold guys need our sleep!)
[0] http://centos.org/docs/2/rhl-rg-en-7.2/s1-bind-configuration.html [1] http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-bind-zone.html [2] https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/5/ht...
I just changed my config to use that (with the chroot package) as it get bind mount from the standard startup script
The lastest part of this thread is me getting 'current' and moving from relying on chroot and following Redhat/NSA recommendation to just use selinux protection.
Of course using a chroot will require the modification of paths in your config file, but the directory structure is similar. /var/named/chroot/var/named/ [2]
I have dropped chroot; I am going to 'trust' selinux as better than chroot. Definitely stands the chance of being less complex.
-
Jay Leafey -
Louis Lagendijk -
Robert Moskowitz -
SilverTip257