What does this mean ? INSIST(zone->type == dns_zone_stub) failed

Ben Croswell ben.croswell at gmail.com
Fri Dec 9 03:55:28 UTC 2011


I don't see the desired outcome of making them both master and the trying
to have one transfer from the other.
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.

-Ben Croswell
On Dec 8, 2011 8:57 PM, "蔡火胜" <hxcan at packetscout.com> wrote:

> 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.
> 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.
>
> This time , MachineA has a serial number 85 for the zone and MachineB has
> a serial number of 83. MachineA is running .
> 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).
>
> 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
> ?
>
>
> 于 2011年12月08日 23:28, Evan Hunt 写道:
>
>> Congratulations, it means you've found the successor of CVE-2011-4313 :-}
>>>
>>> Any details on the triggering event? Was it a zone transfer?
>>>
>> On the off chance that the crash was in fact remotely triggered (in
>> which case this would indeed be a security concern), please *don't* send
>> details of the triggering event to an open mailing list.  Instead, gather
>> up the information detailed in this article:
>>
>> https://deepthought.isc.org/**article/AA-00340/89/What-to-**
>> do-if-your-BIND-or-DHCP-**server-has-crashed.html<https://deepthought.isc.org/article/AA-00340/89/What-to-do-if-your-BIND-or-DHCP-server-has-crashed.html>
>>
>> ...and send mail to bind9-bugs at isc.org.  Thanks.
>>
>>  ______________________________**_________________
> Please visit https://lists.isc.org/mailman/**listinfo/bind-users<https://lists.isc.org/mailman/listinfo/bind-users>to unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/**listinfo/bind-users<https://lists.isc.org/mailman/listinfo/bind-users>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20111208/4e1aeb68/attachment.html>


More information about the bind-users mailing list