New to BIND - Setting up slaveserver

michoski michoski at
Mon May 7 23:30:44 UTC 2012

note: keeping replies on-list, so others can also chime in and help...

On 5/7/12 2:41 PM, "James Sheffer" <James at> wrote:
> On May 7, 2012, at 3:56 PM, michoski wrote:
>> On 5/7/12 1:02 PM, "James Sheffer" <James at> wrote:
>>> My first question is about my options.  For now, I want to "receive"
>>> transfers
>>> from my Master server.  I may want to disallow the NS2 from transferring
>>> requests for outside domains (It appears this is a good idea?) but for now
>>> (testing) I don't want to do that.  Does this look correct for a basic Slave
>>> server's options?:
>>> PS - I'm not sure on syntax - should the "allow-update" and "allow-transfer"
>>> statements be like they are with an extra ";" inside the curly brackets (It
>>> feels wrong but I keep seeing it )?
>> it's not that you have an extra semicolon inside the brackets but rather
>> each element is terminated with a semicolon...  this may help:
>> whatever-option {
>>    elementA;
>>    elementB;
>>    elementC;
>> };
> I guess I thought that the semi-colon was terminating the statement by being
> outside the brackets (a semi colon both inside and outside didn't seem to
> "balance" in my mind!) but I see your point now.  I also wondered that if this
> is correct, shouldn't there be a semi colon inside the "allow-notify"
> statement as well (or as you pointed out, all statements?

yes, this syntax is common...for example, you will want:

allow-notify {;;
    // etc...

named-checkconf will help you here.

> As for the spacing, I was working remotely and didn't have a way to copy/paste
> between locations, so that is my manual typing, typing typos :-)
> My mistake - I thought "allow-notify" was telling the slave to only accept
> transfers from the ip address supplied (Master).

allow-notify is a list of additional addresses to notify about zone changes
other than those listed as "NS" records in your zone files.

beside the dns & bind book and google references, i suggest getting familiar
with the BIND 9 ARM for your version:

you can see links there such as:

>> recursion may be needed for your internal clients, but you generally want it
>> in a private view or controlled by an acl (see secure template).
> I still need to study "recursion" as I haven't quite grasped it's meaning :-)

recursion is how you run a caching server.  so if you have clients that need
to look up "" or other data not hosted explicitly in your zone
files recursion is what you want.  however, you want to lock it down to
specific clients (using views, acls and allow-recursion options) so random
bad guys can't do things like poison your cache.

without recursion enabled, your server will only be able to serve
"authoritative" data found in local zone files you configure.

you can read more on this in the ARM.  :-)

> Thanks - I've already found the named-checkconf command and am using it to
> make sure everything is the way it should be.
> Since the folder "named" is owned by root and I created a folder called
> "slaves" for the zone files within the named folder, I assume that I want the
> "slaves" folder also owned by root with the same privileges, correct?

usually you will run BIND with a flag like "-u named" which says to drop
root privileges after startup, so you will want directories BIND needs to
write to owned by that user or a group the user belongs to.

> Thank you so much for the help and explanations, as well as pointing me to the
> example conf files - the more I can see the better I understand and don't ask
> to many questions that I could have found in a search first :-)

it's good that you take the time to search (we all should), but also don't
feel bad about asking questions...that's why we're here!

By nature, men are nearly alike;
by practice, they get to be wide apart.
        -- Confucius

More information about the bind-users mailing list