Bind 8.2.3 Not Resolving In Stub Zone As Expected

[Marc.Thach at 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                                                                                                           
                    <nick at 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 at isc.org                                                                                                      
                                                                                                                                   
                                                                                                                                   
                    20/06/2001 03:03                                                                                               
                                                                                                                                   
                                                                                                                                   





On 19 Jun 2001 01:35:32 -0700, Marc.Thach at 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.