Barry Finkel wrote:
I ran a test this morning on one of the Solaris 10 slave servers. A query to the server showed serial numbers:_tcp 1238 _udp 842 Both of these match the zone on the MS Windows DNS Server. I checked the zone files on the slave server: _tcp 1239 _udp 843 Both of these are increased by one from what BIND returns in response to a query. The two zones have NO .jnl files. I did ./rndc stop <<Wait for the "exiting" message.>> /etc/init.d/named.anl start;tail -f /var/adm/messages Once BIND started, the serial numbers were INCREASED, as I expected they would be, given the lack of .jnl files. And a few minutes later BIND complained about the serial number on the master being less than that on the slave for both zones. I consider this a bug in BIND 9. What further diagnostics do I need to get? I have another Solaris 10 slave on which, I assume, I can duplicate this. And from past experience, in one day, after the zone has expired and been refreshed, I will be in the same state on this slave.
Do bind slave instances EVER make up or increment serial numbers? This just seems like such an unlikely bug that bind would start doing that. Could it be that the supposed slave instance is accepting dynamic updates? I'd be tracing/tracking SOA files on the master, and communications between the dns instances very closely before I'd even give such a potential bug much thought. Perhaps there are bind functions that I'm not aware of and I'm wrong. John _______________________________________________ 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
