failed while receiving responses and jnl touching

[Kevin Darcy]

Barry Finkel wrote:

>drummah wrote:
>
>  
>
>>>Does anyone have thoughts on this (below)?  I am not sure why this is
>>>occuring. 
>>>
>>>Thanks in advance!
>>>
>>>Jon Wayne
>>>
>>>
>>>drummah wrote:
>>> 
>>>
>>>      
>>>
>>>>I need some help in my continuing education with BIND and DNS.  I have
>>>>a firewall running BIND 9 split-DNS slaving off of a wintendows domain
>>>>controller which is master for DNS and running  AD and DHCP.  The W2k
>>>>domain controller is on the internal network side of the firewall.  The
>>>>domain controller is not set to notify.  The zone files on the firewall
>>>>are set to refresh every fifteen minutes, too frequent perhaps.
>>>>
>>>>I am receiving the following logs:
>>>>
>>>>Feb 10 00:18:52 foo named[22143]: journal file
>>>>/etc/namedb.u/foo.foo.foo.net.db.jnl does not exist, creating it
>>>>Feb 10 00:18:52 foo named[22143]: transfer of 'foo.foo.foo.net/IN' from
>>>>123.4.5.67#53: failed while receiving responses: not exact
>>>>Feb 10 00:18:52 foo named[22143]: transfer of 'foo.foo.foo.net/IN' from
>>>>123.4.5.67#53: end of transfer
>>>>Feb 10 00:18:54 foo named[22143]: zone foo.foo.foo.net/IN: transferred
>>>>serial 1316824
>>>>Feb 10 00:18:54 foo named[22143]: transfer of foo.foo.foo.net/IN' from
>>>>123.4.5.67#53: end of transfer
>>>>
>>>>After searching the archives of this group, the closest answer that I
>>>>located was the following:
>>>>
>>>>"This indicated that the IXFR delta contained a request to remove a
>>>>record that did not exist or to add a record that already exists.
>>>>named will treat the zone as being out of sync and retransfer the
>>>>entire zone."
>>>>
>>>>If this is true, then this may explain why the transfer fails and then
>>>>immediatly succeeds.  Please help me to correct this and stop this from
>>>>filling up my logs.  What should I look for and correct?
>>>>
>>>>Also, unlike BIND8, I thought that the jnl file always exists in BIND9
>>>>once DNS is started.  Why does need to create the jnl file over and
>>>>over every 15 minutes?
>>>>
>>>>Thanks for any insight and replies.
>>>>
>>>>Jon Wayne
>>>>        
>>>>
>
>
>And Kevin Darcy replied:
>
>  
>
>>Open a ticket with Microsoft on their crappy zone-transfer implementation.
>>    
>>
>
>I have no reason to believe that the MS code has bugs.  I have seen this
>happen with one of my forward and reverse zone pairs that is under the
>control of a MS DHCP server.  If there happen to be a "large" (i.e.,
>more than a few) DDNS updates to the MS W2003 DNS Server at the same
>time, then I can see where the IXFR might start and then the zone
>information changes due to another incoming DDNS packet.  I am not
>familiar with the IXFR protocol, so I do not know how many "delta
>decks" need to be saved on the master.
>
I can follow your reasoning with respect to Dynamic Updates "corrupting" 
a zone transfer that's already in progress, although if that is the root 
cause, I think ISC should probably produce a better error message, since 
it's not obvious in the least from the error message what the cause of 
the problem is.

However, since 95% of the "not exact" errors I see in my logs are for 
zones hosted on MSDNS servers, even though the number of such zones are 
dwarfed by the number of non-MSDNS-hosted slave zones, and even though 
client registration in those zones is *disabled* in our environment, I'd 
have to say there's at least circumstantial evidence of other 
deficiencies in MSDNS's zone-transfer code or overall design (maybe all 
of the DCs are rabidly re-registering their SRV records via Dynamic 
Update (?); if so, that's a design flaw).

                                                                         
                                                               - Kevin