failed while receiving responses and jnl touching

Mark Andrews Mark_Andrews at
Mon Apr 3 22:58:46 UTC 2006

> 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/ does not exist, creating it
> >>>Feb 10 00:18:52 foo named[22143]: transfer of '' from
> >>> failed while receiving responses: not exact
> >>>Feb 10 00:18:52 foo named[22143]: transfer of '' from
> >>> end of transfer
> >>>Feb 10 00:18:54 foo named[22143]: zone transferred
> >>>serial 1316824
> >>>Feb 10 00:18:54 foo named[22143]: transfer of' from
> >>> 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?

	Named will perform a AXFR if the IXFR deltas fail to apply cleanly.

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

	Because it was forced to request a AXFR.  Any journal it had is
	now incomplete.

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

	No limit is specified.  If the IXFR request cannot be
	satisfied using deltas then a AXFR style response is returned.

	In coming updates really should not affect IXFR or AXFR
	otherwise you can parform DoS on the zone transfer process.
	This is one of the areas we fixed with BIND 9 by allowing
	AXFR to complete while still accepting updates.  BIND 8
	aborts the AXFR on update.  Some other vendors do/did change
	the final SOA record of the AXFR.

	As always before reporting a bug ensure that you are running
	up to date code on both ends.


Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at

More information about the bind-users mailing list