BIND 8.x, security, and delegations

[Gregg TeHennepe]

Cricket Liu wrote:
 
> Hmm.  Well, I thought this would be the case, since the query the name
> server received was outside of the zone, and hence covered by the global
> allow-query access list, but I set this up here and the parent name server
> seems to send the referral anyway.

This prompted me to do what I should have done in the beginning, and this is
turn tracing on. Now I'm more confused than ever. On the 8.2 primary after
turning security on and turning debug up to level 3, I've seen both successful
and unsuccessful queries for the delegated host:

Successful (I instigated this by using nslookup pointed at the external server):

datagram from [136.244.1.2].53, fd 22, len 41
req: nlookup(www.informatics.jax.org) id 59713 type=1 class=1
req: found 'www.informatics.jax.org' as 'informatics.jax.org' (cname=0)
findns: 2 NS's added for 'informatics'
ns_forw()
find_zone(www.informatics.jax.org,5,1)
find_zone: unknown zone
find_zone(informatics.jax.org,5,1)
find_zone: unknown zone
find_zone(jax.org,5,1)
find_zone: unknown zone
find_zone(org,5,1)
find_zone: unknown zone
nslookup(nsp=0xefffebd8, qp=0x1615b0, "www.informatics.jax.org")
nslookup: NS "uncompaghre.informatics.jax.org" c=1 t=2 (flags 0x2)
nslookup: NS "hobbes.informatics.jax.org" c=1 t=2 (flags 0x2)
nslookup: 2 ns addrs total
retrytime: nstime0ms t4 nretry0 u4 : v4
evSetTimer(ctx 0x108520, func 0x35578, uap 0, due 929461813.000000000, inter 0.0
00000000)
forw: forw -> [192.233.41.22].53 ds=4 nsid=32760 id=59713 11ms retry 4sec
free_nsp: uncompaghre.informatics.jax.org rcnt 2
free_nsp: hobbes.informatics.jax.org rcnt 2
datagram from [192.233.41.22].53, fd 4, len 93
qfindid(32760) -> 0x1615b0
Response (USER NORMAL -) nsid=32760 id=59713
stime 929461812/541104  now 929461812/569865 rtt 28
NS #0 addr [192.233.41.22].53 used, rtt 16
NS #1 [192.233.41.33].53 rtt now 11
rrextract: dname www.informatics.jax.org type 5 class 1 ttl 3600
rrextract: dname l1.informatics.jax.org type 1 class 1 ttl 3600
rrsetupdate: www.informatics.jax.org
rrsetcmp: name not in database
rrsetupdate: www.informatics.jax.org 0
rrsetupdate: www.informatics.jax.org 0
rrsetupdate: l1.informatics.jax.org
rrsetcmp: name not in database
db_update(www.informatics.jax.org, 0x4a9b18, 0x4a9b18, 0, 031, 0x15dbc4)
db_update: adding 0x4a9b18
rrsetupdate: l1.informatics.jax.org 0
rrsetupdate: l1.informatics.jax.org 0
db_update(l1.informatics.jax.org, 0x4af604, 0x4af604, 0, 031, 0x15dbc4)
db_update: adding 0x4af604
resp: got as much answer as there is
send_msg -> [136.244.1.2].53 (UDP 22) id=59713

Then after this came a rejection:

datagram from [144.82.100.41].53, fd 22, len 41
req: nlookup(www.informatics.jax.org) id 17696 type=1 class=1
req: found 'www.informatics.jax.org' as 'www.informatics.jax.org' (cname=0)
unapproved query from [144.82.100.41].53 for "www.informatics.jax.org"
ns_req: answer -> [144.82.100.41].53 fd=22 id=17696 size=41 rc=5

Has named lost its mind? Why would the req return differently:

req: found 'www.informatics.jax.org' as 'informatics.jax.org' (cname=0)
   vs
req: found 'www.informatics.jax.org' as 'www.informatics.jax.org' (cname=0)

Should I report this behavior to the ISC folks?

- Gregg

-- 
Gregg TeHennepe  | Unix Systems Administrator  | The Jackson Laboratory
gat at jax.org      | http://aretha.jax.org/~gat  | Bar Harbor, Maine  USA