A Zone Transfer Question

Darcy Kevin (FCA) kevin.darcy at fcagroup.com
Fri Feb 19 19:24:58 UTC 2016

            REFRESH is set to 1 minute. That's not a long time to wait. Just do a packet capture and see if the slave is issuing zone-refresh queries regularly in the 30-second-to-1-minute range (it's randomized, of course, between REFRESH/2 and full REFRESH).

If the slave isn't issuing refreshes, then check whether the zone got loaded properly as a slave zone in the first place, and that the masters clause is set properly.

If the slave *is* issuing refreshes, is it getting a response? Are the refresh queries even showing up on the master side?

If the refresh queries are getting a response, but there's no AXFR/IXFR following subsequently, look in the log files for some sort of resource issue, e.g. concurrent zone transfers or something of that nature.

                                                                                                                        - Kevin

From: bind-users-bounces at lists.isc.org [mailto:bind-users-bounces at lists.isc.org] On Behalf Of John W. Blue
Sent: Friday, February 19, 2016 2:19 PM
To: David Li
Cc: BIND Users
Subject: Re: A Zone Transfer Question

"kick off" as in update the zone and not by using dig.


Sent from Nine<http://www.9folders.com/>

From: "John W. Blue" <john.blue at rrcic.com<mailto:john.blue at rrcic.com>>
Sent: Feb 19, 2016 1:17 PM
To: David Li
Cc: BIND Users
Subject: Re: A Zone Transfer Question

Nothing in the logs, eg?  Well so much for getting an easy resolution.  :D

If you trust your conf files and logs are clean, I personally next to turn to tcpdump.  You really need to know what (if anything) is being placed on the wire.  Something like this should get you started:

tcpdump -i eth0 -n port domain

Kick off a transfer and see what happens.


Sent from Nine<http://www.9folders.com/>

From: David Li <dlipubkey at gmail.com<mailto:dlipubkey at gmail.com>>
Sent: Feb 19, 2016 1:04 PM
To: John W. Blue
Cc: BIND Users
Subject: Re: A Zone Transfer Question

Hi John,

Nothing in the /var/log/messages indicates transfer problems. In fact
I don't think the transfer ever started by itself for some reason
until I manually used "dig" to initiate.


On Fri, Feb 19, 2016 at 9:00 AM, John W. Blue <john.blue at rrcic.com<mailto:john.blue at rrcic.com>> wrote:
> Hello David,
> You can get started by checking your log files to see if named is
> complaining about anything it might not like that is preventing the
> transfer.
> John
> Sent from Nine
> From: David Li <dlipubkey at gmail.com<mailto:dlipubkey at gmail.com>>
> Sent: Feb 19, 2016 10:46 AM
> To: BIND Users
> Subject: A Zone Transfer Question
> This is my first time to try master slave configuration. Here is a
>     brief description:
>     I have two Centos 7.1 VMs - each is configured for a zone. VM1 is the
>     master for zone1 and slave for zone2. VM2 is master for zone2 and
>     slave for zone1. Both zones uses DNS Dynamic Update from DHCP
> servers on the same VM
>     to update the A records in their zone files. No DNSSEC configured.
>     To start, everything seems to be working fine. I have one host in each
>     zone and they can resolve each other fine.
>     Now I add a new host to zone1 and its sequence number has been bumped
>     up. I read that when the zone1 file changes, it will automatically
>     notify its slave zone (ie. zone2) to start a zone transfer after 15
>     min. This never happened. Then I restarted named on VM2 and hoped it
>     would pull the new zone1 file. This didn't happened either.
>     Eventually I have to either restart the VM2 or use dig to start the
>     zone transfer.
>     Can anyone spot anything obviously wrong here? Do I need to post my
>     zone file and named.conf?
>     Thanks.
>     David
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
> bind-users mailing list
> bind-users at lists.isc.org<mailto:bind-users at lists.isc.org>
> https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20160219/772fef18/attachment-0001.html>

More information about the bind-users mailing list