BIND9's NXDOMAIN vs NOERROR/NODATA

Mark_Andrews at isc.org Mark_Andrews at isc.org
Thu Dec 12 22:08:37 UTC 2002


> > > If you have, say, an A RR for foo.bar.example.com but no records for
> > > bar.example.com and send a query for "bar.example.com" of any type,
> > > older BINDs will answer NOERROR, empty answer section ("NODATA").
> > > BIND 9 will return "NXDOMAIN". From the first one can deduce the
> > > existence of something below "bar.example.com", while the second is
> > > really misleading.
> > 
> > i agree.
> > 
> > > This must have been discussed before, but all I found was a rather old
> > > quote from Paul Vixie stating:
> > > 
> > > >> NXDOMAIN's scope is the {name,type}.  RFC 2308 implicitly outlawed BIN
> D's
> > > >> behaviour, which is to return NOERROR/ANCOUNT=0 for empty nonterminals
> .
> > 
> > note that i was wrong.  NXDOMAIN's scope is {name}, and is type-independent
> .
> > 
> > > I did not yet manage to read this into RFC 2308 (section2, I guess)
> > > and being "implicit" it would be in contradiction to section 4.3.2 of
> > > RFC 1034. How can "bar.example.com" not exist if "foo.bar.example.com"
> > > does and obviously is below "bar.example.com" in the DNS hierarchy?
> > > This is not consistent.
> > 
> > that's true, and in the case of inconsistency there is no right answer, and
> > in this case the latter document (RFC2308) was allowed to win.
> > 
> > > Could someone please agree with me or shed some light upon this? Thanks!
> > 
> > i still think NOERROR/ANCOUNT=0 is the right answer.
> 
> Back in July, I filed a bug report [ISC-Bugs #3264] on this very same
> issue and Mark replied that it is a side-effect of implementing RFC-2535
> (DNSSEC) and that namedroppers was the proper forum to get this resolved.
> 
> Here was the reply that I was working on:
> =====
> Hmmm.  I just read RFC-2535 and could find no explicit requirement
> that NXDOMAIN be set for NODATA responses.  In fact, for non-existent
> RRtypes, the opposite is explicitly stated:
> 
>   5. Non-existent Names and Types
> 
>    The nonexistence of a name in a zone is indicated by the NXT ("next")
>    RR for a name interval containing the nonexistent name. An NXT RR or
>    RRs and its or their SIG(s) are returned in the authority section,
>    along with the error, if the server is security aware.  The same is
>    true for a non-existent type under an existing name except that there
>                                                        ^^^^^^^^^^^^^^^^^
>    is no error indication other than an empty answer section
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    accompanying the NXT(s).
> =====
> 
> To Mark's credit, he spotted this problem way back in 1999:
> 
>   http://ops.ietf.org/lists/namedroppers/namedroppers.199x/msg03885.html
> 
> Because BIND9 is supposed to be a scrupulous implementation of the
> related RFCs, I'm probably wrong and RFC-2535 requires BIND9 to return
> NXDOMAIN for empty nodes.  If so, I think the following argument has
> prectical merit:
> 
> Since this inconsistency is DNSSEC related, go ahead and return
> NXDOMAIN along with the NXT RRs to a DNSSEC-aware resolver if
> that's what's required.  The NXT RRs can be walked to determine
> if the status is really NODATA.  However, if BIND9 returns NXDOMAIN
> without the NXT RRs to a non-DNSSEC-aware resolver, that is really
> an outright lie because there are no NXT records to enable the
> correct status to be determined.  Lying is bad.  I certainly can't
> see anything in RFC-2535 that would explicitly preclude BIND9 from
> performing this conditional resolution.
> 
> Andris
> 

	Well I still think there is DNSSEC is wrong on this and the
	rcode should be NOERROR.  We should use DS as a opportunity to
	fix this.

	It is possible by looking at the NXT record alone to determine
	if the query name is actually for a empty node.

	You find the common suffix of the owner and next domains.
	All domainnames that can be created by removing the left
	most label and not getting the common suffix are empty.
	The common suffix in NOT in the range covered.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at isc.org


More information about the bind-workers mailing list