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
...and send mail to bind9-b...@isc.org. Thanks.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
