DNS Bind – Use Of /etc/named Directory

Home » CentOS » DNS Bind – Use Of /etc/named Directory
CentOS 4 Comments

Hello,

For many years we have modified the ‘/etc/named.conf’ file to include local settings. The disadvantage with this is of course that when bind is updated, it creates an ‘/etc/named.conf.rpmnew’ file. We then have to determine what is new, and apply the relevant changes to our modified named.conf file.

There is, however, an ‘/etc/named’ directory which I assumed was for local configuration settings. The main ‘/etc/named.conf’ file makes no mention of this directory, so (I suspect) any config files in ‘/etc/named’ would, by default, just be ignored.

As far as I can tell we could put our local configuration settings into a file in ‘/etc/named’, but we would then, once again, have to modify
‘/etc/named.conf’ to tell it to include config files in ‘/etc/named’. We would then be back at square one in that any bind update would create an ‘rpmnew’
file.

I admit I haven’t actually tested this, but has anyone used the ‘/etc/named’
directory and not had to modify the main ‘/etc/named.conf’ file?

I suspect, if not, then this should be raised as a possible bug since it would make sense not to have to modify the main configuration file at all.

Thanks,

John.

4 thoughts on - DNS Bind – Use Of /etc/named Directory

  • The ‘/etc/named.conf.rpmnew’ file supplied is a bare minimum to
    “configure the … server as a caching only nameserver (as a localhost DNS resolver only)”. As soon as you start adding any structure to it things change, not just are added to. See
    ‘/usr/share/doc/bind-*/sample/etc/named.conf’ for example. Probably the biggest “gotcha” is that as soon as you use _any_ views you MUST use views for _all_ zones.

    If you were to move the default ‘/etc/named.conf.rpmnew’ to
    ‘/etc/named.conf’ and add an ‘include “/etc/named/*”;’, line as you suggest, you would be building problems for the future. Let’s say you dropped in ‘internal.conf’ which had a simple ‘view “internal” stanza –
    then your root hints, localhost, localhost IPV6 and reverse localhosts would disappear. Just what you wouldn’t want at 00:51 !

    What you can do safely is to include the zone definitions in a separate file (see ‘/etc/named.rfc1912.zones’ for example) and include that file. Doing things this way means that your main configuration file can be written to either use views or not, and to just include your zone definitions in the appropriate place. See the sample file for an example.

    HTH,

    Martin

  • Thanks for the reply.

    However, we don’t use views and the local settings are not for zones. We do currently have a separate zone file, but again that requires an ‘include’ in the main ‘/etc/named.conf’. If a local settings file (in ‘/etc/named’) could be used, then we would simply ‘include’ the zone file in that. Ultimately, the main named.conf file would remain untouched.

    John.

  • Since I don’t know your particular configuration, the above was of necessity rather general. That though is the point, the default named installation has to be generic and cover everything from a basic installation up to a major cluster with multiple networks. I suspect that in your case there will be no advance on diff(1) and vi(1)!

    Regards, Martin

  • I finally got round to giving this a test. Unfortunately unless you are adding new configuration sections, or zones, then it does not work. I wanted to add some extra ‘options’ settings and placed them into an
    ‘/etc/named/local_named.conf’ file. (The ‘/etc/named.conf’ was modified to include this file.)

    Upon starting bind/named though it complained with
    “/etc/named/local_named.conf:2: ‘options’ redefined near ‘options'”
    because I had defined the ‘options’ section in my new config file, as well as it being present in the supplied default ‘/etc/named.conf’.

    So, in order to add extra options settings, I see no way other than modifying the supplied ‘/etc/named.conf’ file.

    Note: it may well be possible to ‘include’ a file within the ‘/etc/named.conf’
    options section, provided that file only contained ‘options’ settings. In our case we also want to modify the logging section slightly, so we would need another include in the ‘logging’ section. Overall, we would end up modifying the ‘/etc/named.conf’ file with include files just as much as if we just added the new options directly to it. Trying to use ‘/etc/named’ in our case is just not worth it.

    John.