<p>I don't see the desired outcome of making them both master and the trying to have one transfer from the other.<br>
Have one be master and one be slave from the master. No reason to alter code and query responses will be the same to your clients. </p>
<p>-Ben Croswell</p>
<div class="gmail_quote">On Dec 8, 2011 8:57 PM, "蔡火胜" <<a href="mailto:hxcan@packetscout.com">hxcan@packetscout.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I use a modified version of BIND9.7.1-p2.I installed it on two machines(MachineA and MachineB). They both host the same zone in master mode.<br>
And in the modified code , one machine would refresh (using dns_zone_refresh) its zone data from the other in order to get the same data.<br>
<br>
This time , MachineA has a serial number 85 for the zone and MachineB has a serial number of 83. MachineA is running .<br>
When I start MachineB , it calls dns_zone_refresh and later runs into the callback function "refresh_callback". In that function , it runs into the lines which start from the label "tcp_transfer:" , which requires the zone type to be dns_zone_slave or dns_zone_stub , but this time the zone type is dns_zone_master , so assert error. It runs into the "tcp_transfer:" code because of a lower serial number (83 vs 85,that's another problem for myself).<br>

<br>
Above is the cause of the crash. It seems nothing to do with the original BIND code.But I have some questions.Should I do a transfer of a zone  between two  servers which both host that zone as MASTER type? And , if they have the same serial number , then the call of dns_zone_refresh has no effect , right?Then , it means I misused dns_zone_transfer  , is that right ?<br>

<br>
<br>
于 2011年12月08日 23:28, Evan Hunt 写道:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Congratulations, it means you've found the successor of CVE-2011-4313 :-}<br>
<br>
Any details on the triggering event? Was it a zone transfer?<br>
</blockquote>
On the off chance that the crash was in fact remotely triggered (in<br>
which case this would indeed be a security concern), please *don't* send<br>
details of the triggering event to an open mailing list.  Instead, gather<br>
up the information detailed in this article:<br>
<br>
<a href="https://deepthought.isc.org/article/AA-00340/89/What-to-do-if-your-BIND-or-DHCP-server-has-crashed.html" target="_blank">https://deepthought.isc.org/<u></u>article/AA-00340/89/What-to-<u></u>do-if-your-BIND-or-DHCP-<u></u>server-has-crashed.html</a><br>

<br>
...and send mail to <a href="mailto:bind9-bugs@isc.org" target="_blank">bind9-bugs@isc.org</a>.  Thanks.<br>
<br>
</blockquote>
______________________________<u></u>_________________<br>
Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/<u></u>listinfo/bind-users</a> to unsubscribe from this list<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/<u></u>listinfo/bind-users</a></blockquote></div>