Strange problem when updating zone files

Kevin Darcy kcd at daimlerchrysler.com
Tue Jan 28 19:47:43 UTC 2003


Rasmus Haslund wrote:

> Hi!
>
> Problem:
>
> I change something in zone file for ANY domain on my primary dns server
> (which handles the same domains as my secondary dns server).
>
> Primary ns: ns.ipv6shells.com
> Secondary: backup-dns.dk
>
> Example:
> I add A record localhost.ipv6shells.com to zone file and update serial.
> Restart primary NS server. Nothing happens on backup-dns.dk (!!)... However
> I get the following in the primary dns log:
>
> Jan 23 23:09:20 linux named[7045]: lame server resolving 'backup-dns.dk' (in
> 'backup-dns.dk'?): 80.199.16.132#53

I tend to think this is unrelated to your main problem, since a master (what
you are calling a "primary") doesn't have to be able to resolve the name of a
slave (what you are calling a "secondary") in order to transfer a zone to it.

> Nothing happens at the secondary ns - it doesnt recieve the new updated zone
> file.

Well, the whole serial-check/zone-transfer cycle is never *instantaneous* even
under the best of circumstances, and unless the slave is in the NS records of
the zone, it won't get a NOTIFY message so it could take hours, if not days,
depending on how you have your SOA.REFRESH set, before the slave will check the
serial number and know that it needs to transfer a fresh copy of the zone. Is
the slave in the NS records? What is your SOA.REFRESH setting? How long did you
wait for the slave to serial-check & zone-transfer?

> Now if I restart the secondary dns server (not making ANY changes on either
> the primary and/or the secondary) I get the following:
>
> Primary dns log:
> Jan 23 23:13:00 linux named[7045]: client 80.199.16.132#28196: transfer of
> 'ipv6shells.com/IN': AXFR-style IXFR started
>
> Secondary dns log:
> Jan 23 23:12:37 firewall named[18872]: transfer of 'ipv6shells.com/IN' from
> 80.62.64.130#53: end of transfer

Looks normal to me. Did the slave have an up-to-date copy of the zone at that
point?


- Kevin





More information about the bind-users mailing list