Bind 8.2.3 Not Resolving In Stub Zone As Expected
Marc.Thach at radianz.com
Marc.Thach at radianz.com
Tue Jun 19 08:15:59 UTC 2001
Nick,
A quick guess is that nn4btest.nhsia.nhs.uk is not in the nhs.uk zone, but
is below a cut, i.e. in a delegated zone, and of course that would not be
loaded with the stub zone so you would expect referrals.
> nn4btest.nhsia.nhs.uk. 1D IN NS test1.nn4btest.nhsia.nhs.uk.
> test1.nn4btest.nhsia.nhs.uk. 1D IN A 194.189.118.106
These two records tell us that nn4btest.nhsia.nhs.uk is a zone apex itself
(which confirms my guess) and that the nameserver for the zone is the host
test1.nn4btest.nhsia.nhs.uk. and the A record (this is glue) tells us that
it has the address you mention (same as the hostname you are looking up),
although we don't actually see the A record associated with your hostname
so off it goes to try to find it.
> resp: found 'nn4btest.nhsia.nhs.uk' as 'nn4btest.nhsia.nhs.uk'
> (cname=0)
This just means it's found where to look
> evSetTimer(ctx 0x10065000, func 0x42b288, uap 0, due
> 992975733.000000000, inter 0.000000000)
> resp: forw -> [194.189.118.106].53 ds=4 nsid=35256 id=17880 11ms
This bit is where it goes to get the info (from the server named in the NS
record)
So is the host actually a nameserver? if not there is misconfigured data in
the nhs.uk domain. Unless there's a strong reason not to then I think you
should ensure that they provide recursion and you use a forward (only) zone
so that your responsibility is clear.
Marc TXK
________________________________________________________________________
The views expressed are personal and do not necessarily reflect those of
the organisation providing the mail address from which this message was
sent
Nick
<nick at glimmer.de To: undisclosed-recipients:;
mon.co.uk> cc:
Sent by: Subject: Bind 8.2.3 Not Resolving In Stub Zone As Expected
bind-users-bounc
e at isc.org
19/06/2001 02:37
My employer has a private link to a client intranet (domain nhs.uk),
and I've attempted to set up our Bind 8.2.3 servers to forward queries
within nhs.uk to that network's own DNS servers by defining a stub
zone for it :
zone "nhs.uk" {
type stub;
file "db.nhs.uk";
masters { 194.72.7.137;
194.72.7.142; };
forwarders {};
check-names ignore ;
};
However, I find that although I can use nslookup to resolve names
within nhs.uk by explicitly requesting their DNS servers be used, if I
run nslookup without specifying the server to be used then I get
failure (timeout) after a while - as if the stub zone is not doing
what I wanted/expected.
In the following Bind debug level 2 output for a sample lookup of the
name "nn4btest.nhsia.nhs.uk" it *looks* to me as if my Bind server
eventually (after trying a couple of non-responding client nameservers
at 194.6.81.18 and 194.62.42.121 that get notified to us when the stub
zone loads) gets the right answer (IP 194.189.118.106) from one of the
client masters at 194.72.7.137, but thinks that address is a referral
of some kind, and tries to resend the query to the target host itself
(nn4btest) - which is not a DNS server at all and so never responds.
[ Then my Bind server gets confused, tries a few lookups within my
employer's domain, and gives up (I left this bit out). ]
Am I interpreting the debug output correctly ?
Why is my nameserver trying to do this :
resp: forw -> [194.189.118.106].53 ds=4 nsid=35256 id=17880 11ms
when 194.189.118.106 is the address of the host I'm trying to look up
?
Am I being fed duff information by the client nameserver ?
==========================< cut >=============================
Debug level 1
Version = named 8.2.3-REL Mon Feb 5 17:41:02 GMT 2001
root at rccnx3:/usr/local/arc/BIND-8.2.3/src/bin/named
conffile = /etc/namedb/named.conf
Debug level 2
evDeselectFD(fd 7, mask 0x2)
evSetTimer(ctx 0x10065000, func 0x485a90, uap 0x1003f754, due
992976307.756392000, inter 600.000000000)
evSelectFD(ctx 0x10065000, fd 7, mask 0x1, func 0x48095c, uap
0x10033000)
evDeselectFD(fd 7, mask 0x1)
datagram from [127.0.0.1].52312, fd 22, len 40
req: nlookup(1.0.0.127.in-addr.arpa) id 17879 type=12 class=1
req: found '1.0.0.127.in-addr.arpa' as '1.0.0.127.in-addr.arpa'
(cname=0)
ns_req: answer -> [127.0.0.1].52312 fd=22 id=17879 size=152 rc=0
datagram from [127.0.0.1].52311, fd 22, len 39
req: nlookup(nn4btest.nhsia.nhs.uk) id 17880 type=1 class=1
req: found 'nn4btest.nhsia.nhs.uk' as 'nhs.uk' (cname=0)
evSetTimer(ctx 0x10065000, func 0x42b288, uap 0, due
992975725.000000000, inter 0.000000000)
forw: forw -> [194.6.81.18].53 ds=4 nsid=63312 id=17880 7ms retry 4sec
resend(addr=1 n=0) -> [194.62.42.121].53 ds=4 nsid=63312 id=17880 7ms
evSetTimer(ctx 0x10065000, func 0x42b288, uap 0, due
992975729.000000000, inter 0.000000000)
datagram from [127.0.0.1].52311, fd 22, len 39
req: nlookup(nn4btest.nhsia.nhs.uk) id 17880 type=1 class=1
req: found 'nn4btest.nhsia.nhs.uk' as 'nhs.uk' (cname=0)
resend(addr=2 n=0) -> [194.72.7.137].53 ds=4 nsid=63312 id=17880 10ms
evSetTimer(ctx 0x10065000, func 0x42b288, uap 0, due
992975733.000000000, inter 0.000000000)
datagram from [194.72.7.137].53, fd 4, len 75
Response (USER NORMAL -) nsid=63312 id=17880
NS #2 addr [194.72.7.137].53 used, rtt 894
NS #0 [194.6.81.18].53 rtt now 896
NS #1 [194.62.42.121].53 rtt now 896
NS #3 [194.72.7.142].53 rtt now 22
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63312
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; nn4btest.nhsia.nhs.uk, type = A, class = IN
nn4btest.nhsia.nhs.uk. 1D IN NS test1.nn4btest.nhsia.nhs.uk.
test1.nn4btest.nhsia.nhs.uk. 1D IN A 194.189.118.106
rrsetupdate: nn4btest.nhsia.nhs.uk
rrsetupdate: test1.nn4btest.nhsia.nhs.uk
resp: nlookup(nn4btest.nhsia.nhs.uk) qtype=1
resp: found 'nn4btest.nhsia.nhs.uk' as 'nn4btest.nhsia.nhs.uk'
(cname=0)
evSetTimer(ctx 0x10065000, func 0x42b288, uap 0, due
992975733.000000000, inter 0.000000000)
resp: forw -> [194.189.118.106].53 ds=4 nsid=35256 id=17880 11ms
resend(addr=0 n=1) -> [194.189.118.106].53 ds=4 nsid=35256 id=17880
11ms
evSetTimer(ctx 0x10065000, func 0x42b288, uap 0, due
992975741.000000000, inter 0.000000000)
(followed by futile attempts to resolve the name within
our own domain)
==========================< cut >=============================
I have copies of the cache (dumpdb) before and after the above lookup,
if that helps (though I understand only a limited amount of what it
tells me).
Thanks for any light anyone can shed.
Nick Boyce
Bristol, UK
--
Remember:
If brute force doesn't work, you're just not using enough.
More information about the bind-users
mailing list