Lame servers in 9.4.0b2

[Mark Andrews]

> > 	Well it is lame.  Notice it is returning a referral to itself.
> 
> Mark,
> Roger that. Investigating that further on my part reveals that to be the 
> case, as you said.
> 
> > 	I suspect you issued a *recursive* query.  Given they running
> > 	BIND 8.3.3-REL-NOESW this recursed and returned the answer
> > 	it was given (note the "aa" flag) and cached it.  Subsequent
> > 	queries return the cached answer (note there is no "aa"
> > 	flag).
> 
> Yes, I was not setting "+norec" on my test queries, so this behavior is 
> accurate. What is the exact significance of BIND 8.3.3-REL-NOESW; does 
> BIND 9 behave differently in this case (noting that these ordb servers 
> are open recursives, which I've contacted them about)?
> 
> >> Downgrading to BIND 9.3.2-P1 causes these messages to go away.
> >>
> >> Could this be a bug with BIND? Is BIND being more sensitive to lame
> >> delegations in more recent versions? Best as we can tell, ordb.org is not
> >> having any problems problems with the zone.
> 
> Not a bug. :)
> 
> What is the different between 9.3.2-P1 and 9.4.0b2 that causes the 
> difference in how this situation is logged?

1880.   [func]          The lame cache is now done on a <qname,qclass,qtype>
                        basis as some servers only appear to be lame for
                        certain query types.  [RT #14916]

The old code tried to identify the domain, which has false positives
when there are multiple levels of the heirachy on the same server.

It was also not type sensitive.

> Thanks for the great explaination!
> 
> Tom Daly
> 
> -- 
> Thomas J. Daly
> tom at dyndns.com
> Dynamic Network Services, Inc.
> http://www.dyndns.com/
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org