Sorry miles forgot the "reply all" to talk<br><br><div class="gmail_quote"><div class="gmail_quote"><div class="im">On Thu, Jul 30, 2009 at 10:22 PM, Miles Nordin <span dir="ltr"><<a href="mailto:carton@ivy.net" target="_blank">carton@ivy.net</a>></span> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<br>
the way you test zone transfers is:<br>
<br>
 dig <a href="http://metm.org" target="_blank">metm.org</a>. axfr @primary<br>
</blockquote></div><div><br>thanks. I needed that. <br></div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Also in other cases of debugging broken slave servers, but not this<br>
case, you may want to check:<br>
<br>
 dig <a href="http://metm.org" target="_blank">metm.org</a>. soa @<primary or secondary><br>
<br>
and look at the serial number.  The slave will not AXFR unless the<br>
master has a higher serial number.  but, that is not your problem<br>
because the slave is reporting SERVFAIL rather than old data---your<br>
guess that the slave cannot download the zone and the Expire time in<br>
the SOA has elapsed, is probably right.</blockquote><div><br> <br></div></div></div>I just increased the serial number  to try to force a notify of the slaves -- nothing happend<br>removed all the allow-transfer clauses from named.conf (which used to have an acl with all the slaves in it)<br>

<br>and still the secondarys give a SERVFAIL .... grrr<br><font color="#888888"><br>Marco<br>
</font></div><br>