Internal Zone Transfers?

Kevin Darcy kcd at
Tue Jun 6 00:57:49 UTC 2006

michaelbertelson at wrote:
> Greetings.
> I inherited some DNS servers which I am a little unsure about how to
> properly get to do internal zone transfers for external (publicly
> available) zones.
> The basics of how it is setup right now are as follows:
> When the slaves (as an example) perform a notify or zone transfer, they
> automatically try to go to the external NAT'ed IP address for that name
> server.  I have checked all the allow-notify, allow-update, etc,
> statements, but they do not seem to be used for this purpose, as it
> will always use the name servers specified in each zone file, which are
> referenced in the external view zone files as an external IP address.
> My understanding is that I cannot specify an internal IP address for
> the A records for the name servers, as they are used by resolvers on
> the Internet.  So I have no idea how to get internal zone transfers to
> work properly.
NOTIFY and zone transfers, although obviously related in protocol terms, 
are treated somewhat differently in named.conf, so let's start by 
distinguishing those two different mechanisms.

The default targets for NOTIFYs for a particular zone, from a master for 
that zone, are the nameservers specified in the NS records of the zone, 
minus the master itself. If you want to *add* to that list, you can do 
so using the "allow-notify" syntax. If you want to *replace* and/or 
*subtract* from that list, then specify "notify explicit" along with 
your "allow-notify". When "explicit", NOTIFYs are sent *only* to the 
slaves specified in the "allow-notify". Note that "notify explicit" is 
only available in BIND 9. You didn't say what version you are running. 
So, the upshot is you have pretty much complete control over where the 
NOTIFYs are sent. As for where the NOTIFYs *originate*, when you have a 
multi-homed box, you can control that using the "notify-source" option. 
That might simplify your NAT configuration, and/or your "allow-notify" 
configuration on the slave side.

The source(s) of a slave's zone transfers, on the other hand, are in no 
way determined by what's in the data for the zone, and is/are *only* 
specified in the "masters" clause of the slave zone definition. So I'm 
not sure why you are claiming that the zone data affects this.

One frequent source of difficulty is when both the master and slave have 
both an "internal" and "external" view, how does one set things up so 
that the correct version of a given zone is transferred? One option is 
to dedicate an interface (physical or virtual) to each view on the 
slave, and then use the "transfer-source" option, binding to a 
particular address on a particular interface, to ensure that the right 
view gets selected for any particular zone transfer.

If you don't want to do all of that extra networking configuration at 
the OS level, then you could attempt to exploit BIND 9.3's ability to 
select views based on TSIG keys. However, unless you're already using 
and/or familiar with using TSIG, I wouldn't necessarily recommend that 
option as an initial implementation.

                           - Kevin

More information about the bind-users mailing list