On Tue, Aug 14, 2007 at 12:51:18PM -0400, Mark Quitoriano wrote:

increasing the serial number? i didn't know that silly me i guess :) so if my serial number is 20070101 when i update the file it should be 20070102?

Technically the new serial number merely needs to be larger than the previous, but best practices say that the serial number should really be something like YYYYMMDD## (where ## is a count of how many changes made that day).

So if you changed the data today it would be 2007081401 If you made a second change, 2007081402 etc

Robert - elists wrote:

mark quitoriano wrote:

...

Im using centos 4.5 and bind 9.2.4-27.0.1.el4, im having a problem propagating updates on domains. when i update the main NS the secondary and tertiary doesn't update automatically. i need to delete the <domain>.zone file in the secondary and tertiary to get update from the main NS. I don't where's the problem i don't get any errors i just dont get the AXFR when the don't delete the file from the backup NS.

As others have said, you MUST increment the zone's serial. Addtitionally, on the master you may want to add "notify yes;" to the zone stubs. This will make sure bind sends out a message (notification) to the slaves when a zone is changed.

As previously noted, you have to increase the serial number of the zone, plus in the secondary, in the conf file, you have to make sure that the ownership and permissions are correct.

Permissions - good point. Modifying slave serials??? Er, no. Don't do that. I'm pretty sure you weren't suggesting the OP do that....but that's how it reads[1] :)

Ip source of the update matters too

Usually only a problem when you have a firewall that's matching the source IP of TCP/53 connections (zone transfers always happen over TCP). But seeing as the OP can refresh the zones after hosing the slave's cache, I doubt this is a network problem.

Overall, Dns is easy to debug in the log files…

Here, here :)

Mark Quitoriano wrote:

On 8/12/07, *James Gray* <james.gray@dot.com.au mailto:james.gray@dot.com.au> wrote:

As others have said, you MUST increment the zone's serial.
Addtitionally, on the master you may want to add "notify yes;" to the
zone stubs.  This will make sure bind sends out a message
(notification)
to the slaves when a zone is changed.

where do i put the notify yes? on named.conf? or on the .zone file? do you have sample config for that? thanks!

the master notifies all servers that have NS records in the zone (except itself, of course).

Mark Quitoriano wrote:

On 8/12/07, *James Gray* <james.gray@dot.com.au mailto:james.gray@dot.com.au> wrote:

As others have said, you MUST increment the zone's serial.
Addtitionally, on the master you may want to add "notify yes;" to the
zone stubs.  This will make sure bind sends out a message
(notification)
to the slaves when a zone is changed.

where do i put the notify yes? on named.conf? or on the .zone file? do you have sample config for that? thanks!

---

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Hi all,

Mark, are you running chrooted BIND? If so, the file locations are somewhat different, but the general paradigm is the same.

NON-Chrooted: db.* files are in /var/named named.conf is in /etc zone.* files are in /etc/bind

Chrooted: db.* files are in /var/named/chroot/var/named/ (if slaves, they're in /var/named/chroot/var/named/slaves/) named.conf is in /var/named/chroot/etc/ zone.* files are in /var/named/chroot/etc/bind

I recently (with *lots* of pointers from this list) got my secondary NS up running a chrooted BIND (on CentOS 5). One of the issues I had was the path set for the slave zone files.

In my secondary, I had the full path including the leading /var/named/chroot/. That was a big error. The chrooted location is, it seems, understood so my path/to_zone_files/ was wrong in my secondary's named.conf file.

Made a *big* difference for me, clearly.

I do hope this helps.

~Ray