Internal Zone Transfers?
kcd at daimlerchrysler.com
Tue Jun 6 00:57:49 UTC 2006
michaelbertelson at gmail.com wrote:
> 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.
More information about the bind-users