FAQ
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?

Search Discussions

  • Jay Leafey at Feb 15, 2013 at 5:31 pm

    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!
    --
    Jay Leafey - jay.leafey at mindless.com
    Memphis, TN
  • Robert Moskowitz at Feb 15, 2013 at 5:44 pm

    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 at centos.org
    http://lists.centos.org/mailman/listinfo/centos
  • Louis Lagendijk at Feb 15, 2013 at 7:27 pm

    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
  • Robert Moskowitz at Feb 15, 2013 at 7:47 pm

    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.
  • SilverTip257 at Feb 18, 2013 at 5:46 pm
    On Fri, Feb 15, 2013 at 2:47 PM, Robert Moskowitz wrote:

    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/html/Deployment_Guide/s1-bind-zone.html





    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 at centos.org
    http://lists.centos.org/mailman/listinfo/centos

    --
    ---~~.~~---
    Mike
    // SilverTip257 //
  • Robert Moskowitz at Feb 18, 2013 at 6:59 pm
    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 wrote:
    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/html/Deployment_Guide/s1-bind-zone.html


    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcentos @
categoriescentos
postedFeb 15, '13 at 4:44p
activeFeb 18, '13 at 6:59p
posts7
users4
websitecentos.org
irc#centos

People

Translate

site design / logo © 2022 Grokbase