failed multi-view zone transfer

[jeffreyp]

thanks chris.  sorry if i've confused anyone.  the notifications appear 
to be working fine.  i enabled notify logging on the slaves and do see 
the notifications at the slaves, as expected.  it's the transfers that 
are not happening.  and, specifically, just the transfers of the 
internal view to the slave on the different subnet.

the soa/mname is the actual primary master, and the zone has two ns 
records, one that is the same hostname as the mname, and an other 
hostname that is the slave.  additionally (and it's redundant, i know), 
there is an also-notify that is the ip address of the slave.

to answer your question:  no, if the actual primary master's name is in 
the mname field the transfer does not work correctly.

so the slave gets notified, and with the proper tsig key, but does not 
transfer the zone.

on the master, the internal zone file is thus:

$ORIGIN .
$TTL 3600 ; 1 hour
somezone.tld	IN SOA	hank.example.com.
	dns.example.com. (
	2003081123 ; serial
	3600       ; refresh (1 hour)
	600        ; retry (10 minutes)
	86400      ; expire (1 day)
	3600       ; minimum (1 hour)
	)

	NS	dean.example.com.
	NS	hank.example.com.

again, the notifies appear to be working fine.  but when using the zone 
file as above, the zone does not transfer to the slave.  but if the 
hank.example.com NS record is removed, the zone does transfer.

as a matter of fact, it doesn't matter what is in the NS records 
(resolvable hostnames, un-resolvable hostnames):  if hank.example.com. 
is in the NS records then the zone will not transfer; if 
hank.example.com. is not in the NS records then the zone will transfer.

thanks for the help!

On 1/22/11 9:43 AM, Chris Buxton wrote:
> Notifications by default do not go to the server listed in the mname
> field of the SOA record, so that the primary master does not notify
> itself.
>
> If you put the actual primary master's name in the mname, does it work
> correctly?
>
> You saud that also-notify lists the slaves. This should ensure that
> both slaves receive notifications, regardless of the mname value. If
> that is not working, then it sounds to me like you've found a bug.
>
> Regards,
> Chris Buxton
> BlueCat Networks
>
> On 1/21/11, jeffreyp<bindusers at bindusers.exjay.com>  wrote:
>> greetings,
>>
>> i'm in the midst of an odd problem (to me, anyway) and would appreciate
>> any pointers.
>>
>> three servers, all running bind-9.7.2-P3 compiled from source with the
>> same options.  one master; two slaves.  two views:  internal and
>> external.  one master and one slave are on the same subnet with just a
>> switch between 'em; the other slave is on a different subnet "out on the
>> internet".
>>
>> i'm wanting to have both views for all zones transferred to both slaves.
>>    i've set things up with tsig and per mark andrews' great scheme
>> documented at
>> http://www.mail-archive.com/bind-users@lists.isc.org/msg03593.html
>>
>> transfers from the master to the slave on its same subnet happen as
>> desired; transfers from the master to the slave on the different subnet
>> do not.
>>
>> notify logging shows that the notifies are being properly received by
>> both slaves.
>>
>> my master zone definitions specify also-notify for both slaves.  each
>> slave zone definition specifies a masters statement.
>>
>> what i've observed (initially because of a typo and quite by chance) is
>> that the transfer to the slave on the internet does not happen if the
>> host specified in the SOA's MNAME field is also specified in an NS record.
>>
>> but if the host specified in the SOA's MNAME field is not an NS record
>> then the transfer does complete.  and therein lies the problem.
>>
>> i've intentionally not posted my config, thinking someone might
>> recognize this off the top of their head.  i will certainly post it if
>> necessary.
>>
>> thanks,
>>
>> jeffreyp
>> _______________________________________________
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>>
>