Lame servers in 9.4.0b2

Tue Oct 17 23:36:08 UTC 2006

> Hi Folks,
> We are testing BIND 9.4.0b2 in various production locations on 
> our network. One issue we've noticed is that BIND (as a recursive) is 
> considering some servers lame, even though they are answering perfectly 
> for thier zone.
> 
> Application example: Querying the relays.ordb.org zone for open relay 
> information. Our mail server will execute a number of DNS requests for 
> hosts within relays.ordb.org to this instance of BIND. When reviewing the 
> log, we see:
> 
> Oct 17 17:47:29 mxin2 named[750]: lame server resolving 
> '91.249.13.204.relays.ordb.org' (in 'relays.ordb.org'?): 206.154.202.54#53

	Well it is lame.  Notice it is returning a referral to itself.

; <<>> DiG 9.3.2 <<>> 91.249.13.204.relays.ordb.org @206.154.202.54 +norec
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47140
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 9

;; QUESTION SECTION:
;91.249.13.204.relays.ordb.org. IN      A

;; AUTHORITY SECTION:
relays.ordb.org.        70061   IN      NS      b.ns.ordb.org.
relays.ordb.org.        70061   IN      NS      d.ns.ordb.org.
relays.ordb.org.        70061   IN      NS      e.ns.ordb.org.
relays.ordb.org.        70061   IN      NS      f.ns.ordb.org.
relays.ordb.org.        70061   IN      NS      m.ns.ordb.org.
relays.ordb.org.        70061   IN      NS      n.ns.ordb.org.
relays.ordb.org.        70061   IN      NS      o.ns.ordb.org.
relays.ordb.org.        70061   IN      NS      p.ns.ordb.org.
relays.ordb.org.        70061   IN      NS      q.ns.ordb.org.

;; ADDITIONAL SECTION:
b.ns.ordb.org.          68015   IN      A       193.163.220.60
d.ns.ordb.org.          68016   IN      A       206.154.202.54
e.ns.ordb.org.          68016   IN      A       130.226.1.4
f.ns.ordb.org.          68016   IN      A       206.154.203.54
m.ns.ordb.org.          68016   IN      A       193.70.152.20
n.ns.ordb.org.          68016   IN      A       85.116.4.22
o.ns.ordb.org.          68016   IN      A       194.158.102.12
p.ns.ordb.org.          3267    IN      A       209.142.2.8
q.ns.ordb.org.          68016   IN      A       205.139.192.54

;; Query time: 59 msec
;; SERVER: 206.154.202.54#53(206.154.202.54)
;; WHEN: Tue Oct 17 23:24:01 2006
;; MSG SIZE  rcvd: 338

> Oct 17 17:47:29 mxin2 named[750]: lame server resolving 
> '91.250.13.204.relays.ordb.org' (in 'relays.ordb.org'?): 206.154.202.54#53
> Oct 17 17:47:29 mxin2 named[750]: lame server resolving 
> '8.213.188.195.relays.ordb.org' (in 'relays.ordb.org'?): 206.154.202.54#53
> Oct 17 17:47:29 mxin2 named[750]: lame server resolving 
> '94.134.141.64.relays.ordb.org' (in 'relays.ordb.org'?): 206.154.202.54#53
> Oct 17 17:47:29 mxin2 named[750]: lame server resolving 
> '41.88.132.64.relays.ordb.org' (in 'relays.ordb.org'?): 205.139.192.54#53
> Oct 17 17:47:29 mxin2 named[750]: lame server resolving 

	Similarly here

; <<>> DiG 9.3.2-P1 <<>> 41.88.132.64.relays.ordb.org @205.139.192.54 +norec
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17781
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 9

;; QUESTION SECTION:
;41.88.132.64.relays.ordb.org.	IN	A

;; AUTHORITY SECTION:
relays.ordb.org.	69868	IN	NS	b.ns.ordb.org.
relays.ordb.org.	69868	IN	NS	d.ns.ordb.org.
relays.ordb.org.	69868	IN	NS	e.ns.ordb.org.
relays.ordb.org.	69868	IN	NS	f.ns.ordb.org.
relays.ordb.org.	69868	IN	NS	m.ns.ordb.org.
relays.ordb.org.	69868	IN	NS	n.ns.ordb.org.
relays.ordb.org.	69868	IN	NS	o.ns.ordb.org.
relays.ordb.org.	69868	IN	NS	p.ns.ordb.org.
relays.ordb.org.	69868	IN	NS	q.ns.ordb.org.

;; ADDITIONAL SECTION:
b.ns.ordb.org.		67743	IN	A	193.163.220.60
d.ns.ordb.org.		67743	IN	A	206.154.202.54
e.ns.ordb.org.		67743	IN	A	130.226.1.4
f.ns.ordb.org.		67743	IN	A	206.154.203.54
m.ns.ordb.org.		67743	IN	A	193.70.152.20
n.ns.ordb.org.		67743	IN	A	85.116.4.22
o.ns.ordb.org.		67743	IN	A	194.158.102.12
p.ns.ordb.org.		2998	IN	A	209.142.2.8
q.ns.ordb.org.		67743	IN	A	205.139.192.54

;; Query time: 367 msec
;; SERVER: 205.139.192.54#53(205.139.192.54)
;; WHEN: Wed Oct 18 09:28:41 2006
;; MSG SIZE  rcvd: 337

> '91.249.13.204.relays.ordb.org' (in 'relays.ordb.org'?): 205.139.192.54#53
> Oct 17 17:47:29 mxin2 named[750]: lame server resolving 
> '91.250.13.204.relays.ordb.org' (in 'relays.ordb.org'?): 205.139.192.54#53
> Oct 17 17:47:29 mxin2 named[750]: lame server resolving 
> '147.91.61.64.relays.ordb.org' (in 'relays.ordb.org'?): 205.139.192.54#53
> Oct 17 17:47:29 mxin2 named[750]: lame server resolving 
> '40.102.124.207.relays.ordb.org' (in 'relays.ordb.org'?): 205.139.192.54#53
> 
> Re-executing the same query manually through dig (at 205.139.192.54 or 
> 206.154.202.54 directly) result in the proper answer being returned.

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

; <<>> DiG 9.3.2-P1 <<>> 41.88.132.64.relays.ordb.org @205.139.192.54
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 35361
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;41.88.132.64.relays.ordb.org.	IN	A

;; AUTHORITY SECTION:
relays.ordb.org.	1800	IN	SOA	b.ns.ordb.org. hostmaster.ordb.org. 1161120602 600 300 604800 1800

;; Query time: 215 msec
;; SERVER: 205.139.192.54#53(205.139.192.54)
;; WHEN: Wed Oct 18 09:31:10 2006
;; MSG SIZE  rcvd: 113

; <<>> DiG 9.3.2-P1 <<>> 41.88.132.64.relays.ordb.org @205.139.192.54
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 38968
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;41.88.132.64.relays.ordb.org.	IN	A

;; AUTHORITY SECTION:
relays.ordb.org.	1782	IN	SOA	b.ns.ordb.org. hostmaster.ordb.org. 1161120602 600 300 604800 1800

;; Query time: 214 msec
;; SERVER: 205.139.192.54#53(205.139.192.54)
;; WHEN: Wed Oct 18 09:31:28 2006
;; MSG SIZE  rcvd: 98

> 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.
> 
> Any thoughts or help is very much appreciated.
> 
> 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