BIND 8 data loss problem

[Mark Andrews]

> I hope this does not turn out to be a duplicate.  I posted last Friday 
> and have not seen my message yet.
> 
> -----------------------------------------------------------------------
> Thanks Kevin & Mark.
> 
> Enabling recursion solved that problem.  But I'm still a little
> confused.  This server is a hidden master for all zaboo.org zones, so it
> should be authoritative.  Why does it need to recurse to itself for an
> answer?
 
	It is *not* authoritative for the NS records of the child zone.
	Only the child servers are.  It has a *copy* of the NS records
	which are used as glue to find the real NS RRset in the child
	zone.  Note this may differ from the copy it currently has.  If
	it does differ it should be corrected to match that in the child
	zone.  Failure to do this can result in broken delegations.

> The server is currently isolated off network while testing the upgrade
> and only talking to itself so it never went anywhere to get the answer.
>   It had the answer all along.

	No it didn't.  It has a copy of the answer which may have been
	out of date.  It provided that copy in the referral it returned.

> I understand that in typical practice, a referral probably makes sense
> for this condition. Is there a way to circumvent change 1461 without
> breaking functionality?

	It doesn't break functionality.  It breaks your incorrect
	assumptions about what it should be returning.  It will
	correctly work as a authoritative server.
 
	BIND 8 only has one internal database structure.  If you enable
	recursion it will *lie* and return the glue copy in the answer
	section if you make a recursive query.  This is because it has
	no place to store the real answer so it returns the best it has.

	BIND 9 has multiple internal databases (one for each zone and
	one for the cache).  It has the ability to store both the real
	answer (in the cache) and the glue (in the zone) returning
	which ever is appropriate to the query.

> Thanks again for the great help.
> Ann
> 
> Mark Andrews wrote:
> >>The NS records in the response have been moved from the Answer Section 
> >>to the Authority Section, which makes more sense since the response is 
> >>effectively a referral. See
> >>
> >>1461.   [func]          return referrals for glue (NS/A/AAAA) if 
> >>recursion is
> >>                        disabled (recursion no;).
> >>
> >>in the src/CHANGES file.
> >>
> >>If you want to provide an actual *answer* to that question, then you 
> >>either need to recurse for it (which would require loosening your 
> >>recursion settings) or be authoritative (i.e. a slave) for the zone. 
> >>It's possible you might be able to accomplish this by defining the child 
> >>as a "stub" zone, but I don't have a working installation of 8.4.6 to be 
> >>able to confirm or deny this...
> >>
> >>                                                                         
> >>                     - Kevin
> > 
> > 
> > 	Note also this is a authorative only server (recursion no;).
> > 	End systems are not expected to query this directly but
> > 	rather through a iterative resolver.  A iterative resolver will
> > 	follow the referral and get the NS records from the slave.
> >  
> > 
> 
> 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org