Bind Zone Transfer Problem

Todd Zullinger tmz at
Tue Jul 4 05:12:28 UTC 2006

Hash: SHA1

Charles Curley wrote:
>> That's one solution I found for someone having the same problem and
>> it makes sense, as right now your secondary is trying to write the
>> localdomain file to /var/named, which it won't have permission to
>> write to by default.
> Well, it *should*. The files there are root:named. But that explains
> it, doh. The files have permissions of -rw-r-----, so all I needed
> to do was change that.

The files have those permissions, but the directory itself isn't
writable by named.

> Is this a bug in bind, or rather in the bind RPM package? I'm
> running this in the chroot jail provided by the bind-chroot package.

Neither, AFAICT.  It's by design.  Slaves are meant to go in the
slaves subdir, with is writable by named.  This is for security.  It
limits the amount of damage someone can do with a bind exploit by
limiting the permissions the named user/group has.  (Not that bind has
ever had remote exploits. ;)

> This leaves one minor mystery:
> Jul  3 22:07:09 dragon named[15783]: running
> Jul  3 22:07:09 dragon named[15783]: zone localdomain/IN: Transfer started.
> Jul  3 22:07:09 dragon named[15783]: transfer of 'localdomain/IN' from connected using
> Jul  3 22:07:10 dragon named[15783]: zone localdomain/IN: transferred serial 2006070301
> Jul  3 22:07:10 dragon named[15783]: transfer of 'localdomain/IN' from end of transfer
> Jul  3 22:07:10 dragon named[15783]: zone localdomain/IN: sending notifies (serial 2006070301)
> Jul  3 22:07:10 dragon named[15783]: client received notify for zone 'localdomain'
> Jul  3 22:07:10 dragon named[15783]: zone localdomain/IN: refused notify from non-master:
> Well, of course it's refusing a notification from itself. I'm probably
> leaving out an option to tell it not to notify anyone of the
> change. Well, I'll track that one down later.

I think you'll want to fiddle with the settings for notify and/or


        If yes (the default), DNS NOTIFY messages are sent when a zone
        the server is authoritative for changes, see the section
        called "Notify". The messages are sent to the servers listed
        in the zone's NS records (except the master server identified
        in the SOA MNAME field), and to any servers listed in the
        also-notify option.

        If explicit, notifies are sent only to servers explicitly
        listed using also-notify. If no, no notifies are sent.

        The notify option may also be specified in the zone statement,
        in which case it overrides the options notify statement. It
        would only be necessary to turn off this option if it caused
        slaves to crash.

It seems to me that if you set notify to no in the zone config for
localdomain on the slave, that would prevent it from trying to notify
itself.  But I'm going on reading the manual, not on having done this
within a reasonable period of time in the past.

>> Relying on government to protect your privacy is like asking a peeping
>> tom to install your window blinds.
>>     -- John Barlow, co-founder of EFF
> Good one. From whom do they think I want to protect my privacy,
> anyway.

Yourself?  Isn't that who the government is always protecting you


- -- 
Todd        OpenPGP -> KeyID: 0xD654075A | URL:
I have to decide between two equally frightening options.  If I wanted
to do that, I'd vote.
    -- Duckman

Version: GnuPG v1.4.4 (GNU/Linux)
Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl.


More information about the users mailing list