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

蔡火胜 hxcan at packetscout.com
Fri Dec 9 01:52:02 UTC 2011

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 
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 

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
> ...and send mail to bind9-bugs at isc.org.  Thanks.

More information about the bind-users mailing list