bad referrals

[Mark.Andrews at iengines.com]

> On Dec 6,  5:36pm, Wayne Vigeant wrote:
> } Subject: Re: bad referrals
> 
> } We recently upgraded from bind 8.1.2 to 8.2.2-P5 and started seeing lots
> } more bad referrals. We see them for our own domain and subdomains and for
> } .com and even ".". Each time I check the master servers for any of these
> } zones they appear to be ok. We're also using forwarders. Is it possible 
> } that packets are timing out and causing these bad referrals?
> 
> BIND acting as as a client of a forwarder might be erroneously logging
> logging the responses it gets from its forwarder.
> 
> 	If the client has a cached NS RRset for example.com
> 
> 	and the client forwards a request for something.example.com
> 
> 	and the forwarder has cached data for something.example.com
> 
> 	and the NS RRset for example.com has expired from the forwarder's
> 	cache
> 
> 	then the response from the forwarder will contain the requested
> 	data for something.example.com, and will contain the COM NS
> 	RRset in the additional data section.
> 
> BIND on the client may interpret this response as a bad referral, since
> the NS RRset is closer to the root than the RRset that it found in it's
> own cache.  This should only be an indication of a problem if the answer
> is received directly from a server that is thought to be authoritative.
> I think the lame delegation code could may have the same problem.
> 
> The attached patch was generated by a sleep deprived brain and is
> completely untested.
> 
> (BTW, I think the hp->rd && hp->ra test should also be used to figure
> out whether to calculate the server RTT earlier in the code).
> 
	The first hunk is definitly wrong even with forwarders.

	At this point in the code we have identified a referral
	answer, so even if we get one from a forwarder it is lame
	as far as we are concerned.  The identifing the referral
	should be made stronger as the code assumes wrongly that
	the SOA record, if present, will be first in the section.

	The second and third hucks cover too much in the if.
	Testing for "fwd != NULL" in the "else if (...)" would be
	a more reasonable patch.
	
	Mark
> 
> --- ns_resp.c.orig	Thu Nov  4 20:40:57 1999
> +++ ns_resp.c	Wed Dec  8 01:52:36 1999
> @@ -751,7 +751,8 @@
>  		 * classes tend to not have good strong delegation graphs).
>  		 */
>  
> -		if (type == T_NS && ns_samedomain(qp->q_domain, name)) {
> +		if (type == T_NS && !(hp->rd && hp->ra) &&
> +		    ns_samedomain(qp->q_domain, name)) {
>  			nameserIncr(from.sin_addr, nssRcvdLDel);
>  			mark_lame(qp, from);
>  			mark_bad(qp, from);
> @@ -977,6 +978,7 @@
>  				switch (type) {
>  				case T_NS:
>  				case T_SOA:
> +					if (!(hp->rd && hp->ra)) {
>  					if (!ns_samedomain(aname, name)) {
>  						ns_info(ns_log_resp_checks,
>  						    "bad referral (%s !< %s)",
> @@ -994,6 +996,7 @@
>  							 qp->q_domain : ".");
>  						db_freedata(dp);
>  						continue;
> +					}
>  					}
>  					if (type == T_NS) {
>  						nscount++;
> 
--
Mark Andrews, Internet Engines Inc. / Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at iengines.com