Bind 8.2.3 Not Resolving In Stub Zone As Expected
Nick
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@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.
Marc....@radianz.com
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
<ni...@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...@isc.org
19/06/2001 02:37
Nick
On 19 Jun 2001 01:35:32 -0700, Marc....@radianz.com wrote:
>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.
Thanks - that was it. I managed to contact the nhs.uk domain admins
today, and discovered that although they initially only informed us of
the two domain masters I listed in the stub zone statement, they
actually have a fairly complex intranet with multiple delegated zones,
and a significant number of other nameservers.
The target host (194.189.118.106) is indeed a nameserver for a
delegated zone (as well as a webserver). In fact I've now had to open
up our firewall to allow DNS to a whole bunch of other nameservers on
their network, *and* add a bunch of static routes to our nameserver so
it can get to them (its default route points at our own intranet). The
lack of this is what was failing my query.
>> 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.
What tells us that ? The mere presence of the NS record ? What's
the "1D" about (I'm just curious) ?
> ... 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.
Do you mean I should expect their master nameservers (the ones in the
zone statement) to recursively complete all my lookups for me, so my
nameservers would never need to contact any other nameservers on their
network ? Is that a customary arrangement ?
Thanks very much for your help.
Nick Boyce
Bristol, UK
--
Baruch's Observation:
If all you have is a hammer, everything looks like a nail.
Marc....@radianz.com
Nick,
If you use a conventional DNS model (i.e. not using forwarders), then you
can expect to configure the firewall to allow DNS queries to any outside
address. If you have no control over the outside network (or Internet)
then you can expect new DNS servers to appear witout warnings so
restricting DNS traffic to only known servers is asking for trouble.
Yes, the NS record tells us directly that the target (leftmost field) is at
the top of a zone, 1D is "one day" and is a time-to-live (TTL) for the
individual record, one day would be pretty short for a NS record on the
Internet but this is OK on a (relatively) smaller closed network.
As for forwarding, yes that's what I meant. If they don't want their
masters recursing for you then maybe they should provide caching servers
for this purpose (or you could put one in outside your firewall), it really
depends on volumes and your relationship with them. You just put the
appropriate IP addresses in a forward zone, they don't have to be the
masters for the zone, forwarding is really a kludge.
The use of forwarders like this is not good (or customary) practice for
Internet connectivity, but when integrating two private networks
(particularly if there is or might be other inter-network connectivity)
then selective zone forwarding can be a real boon. I was worried that you
might be suffering from a misconfiguration of their DNS structures, in this
case an agreement that you use forwarding is particularly helpful since it
eliminates your configurations as a source of potential problems when
things do go wrong.
Marc TXK
Nick
<ni...@glimmer.de To: undisclosed-recipients:;
mon.co.uk> cc:
Sent by: Subject: Re: Bind 8.2.3 Not Resolving In Stub Zone As Expected
bind-users-bounc
e...@isc.org
20/06/2001 03:03
Nick
>If you use a conventional DNS model (i.e. not using forwarders), then you
>can expect to configure the firewall to allow DNS queries to any outside
>address. If you have no control over the outside network (or Internet)
>then you can expect new DNS servers to appear witout warnings so
>restricting DNS traffic to only known servers is asking for trouble.
OK - point taken.
[...]
>As for forwarding, yes that's what I meant. If they don't want their
>masters recursing for you then maybe they should provide caching servers
>for this purpose (or you could put one in outside your firewall), it really
>depends on volumes and your relationship with them. You just put the
>appropriate IP addresses in a forward zone, they don't have to be the
>masters for the zone, forwarding is really a kludge.
> ... when integrating two private networks
>(particularly if there is or might be other inter-network connectivity)
>then selective zone forwarding can be a real boon.
I certainly like the idea of their servers recursively handling our
queries, but I was under the impression selective forwarding was unreliable
or broken with Bind 8 and needs Bind 9 - I'm sure someone told me stub
zones were a better idea with Bind 8.
Anyway, I'm off to find out how to get my servers to make recursive queries
to the stub zone. I know you can tell your own servers whether or not to
allow recursion but I don't know how to make mine *request* recursion from
the other servers.
Thanks again for pointing out I should have just believed what the Bind
debug output was telling me.
Nick Boyce
Bristol, UK
--
You know you've landed gear-up when it takes full power to taxi.
Kevin Darcy
ni...@glimmer.demon.co.uk wrote:
> On 20 Jun 2001 01:45:42 -0700, Marc....@radianz.com wrote:
>
> >As for forwarding, yes that's what I meant. If they don't want their
> >masters recursing for you then maybe they should provide caching servers
> >for this purpose (or you could put one in outside your firewall), it really
> >depends on volumes and your relationship with them. You just put the
> >appropriate IP addresses in a forward zone, they don't have to be the
> >masters for the zone, forwarding is really a kludge.
>
> > ... when integrating two private networks
> >(particularly if there is or might be other inter-network connectivity)
> >then selective zone forwarding can be a real boon.
>
> I certainly like the idea of their servers recursively handling our
> queries, but I was under the impression selective forwarding was unreliable
> or broken with Bind 8 and needs Bind 9 - I'm sure someone told me stub
> zones were a better idea with Bind 8.
I think you may have misunderstood. Generally you want to avoid forwarding
because it doesn't scale well, and by limiting the choices your nameserver
makes as to what other nameservers to use for resolving names, it loses some
optimization and robustness. Certainly, in situations where you just want to
"override" the delegation information for a particular zone, or override any
forwarding directive you have at a higher level, defining a zone as "stub" is
preferable to defining it as "forward" (in the case where you want to override
higher-level forwarding, you'll need a "forwarders { }" clause in the stub zone
definition in order to achieve this effect).
However, to deal with connectivity issues, sometimes forwarding is the
*only* choice. It would appear from the log output you posted earlier that you
do indeed have some sort of connectivity issue. Therefore forwarding might be
the answer for you. But I would still try to limit the use of forwarding as
much as possible, and wherever you're using forwarding to deal with a lack of
connectivity, make sure to specify "forward only", otherwise if you lose
contact with your forwarder(s), your nameserver will beat its head against the
wall trying to talk to the nameservers directly. In such a situation, it's
better that the queries fail immediately, than for your nameserver to get
bogged down with doomed resends/retries.
> Anyway, I'm off to find out how to get my servers to make recursive queries
> to the stub zone. I know you can tell your own servers whether or not to
> allow recursion but I don't know how to make mine *request* recursion from
> the other servers.
You make your server "request recursion" from other servers by setting it up to
forward to those servers. That's basically the whole point of forwarding.
- Kevin