redirecting root hints to fake internal root server

[Cathy Almond]

On 27/08/13 21:28, Kevin Darcy wrote:
> On 8/27/2013 1:07 PM, Colin Harvey wrote:
>> My environment is firewalled from the real world.  For queries on
>> zones to which I'm not master, I want to recurse to a corporate
>> server.  nslookup some.internal.hostname.com internal.corporate.server
>> works fine.
> nslookup is a terrible DNS troubleshooting tool. Try dig. And to mimic
> how your nameserver would talk to the other nameserver, use the options
> +norec and +bufsiz=4096 (unless you've changed your EDNS0 buffer size
> from the default, in which case, plug in that value instead).
> 
>> Setting "." to use this internal server in the root.hints file does
>> not.  In fact I do not even see my system trying to recurse.  (I'm
>> looking at network traffic with a sniffer.)
>> My root.hints:
>> .    600    IN    NS    internal.corporate.server.
>> internal.corporate.server.    600    IN    A    192.168.1.1
> Do you have recursion enabled?
>> Alternatively I've setup a forwarding zone in named.conf to query
>> 192.168.1.1 for 'internal.hostname.com'.
> Ugh, don't do that. Forwarding is for getting around network
> restrictions or limitations, and you haven't (so far) indicated that you
> have any of those to deal with.

If you're really playing in an internal-only name space with no queries
ever going out to the Internet name space, then in order to do recursion
properly in that environment, you should really have access to a
nameserver that is essentially taking the role of of the root
nameservers - an 'internal root'.  It should be authoritative for "."
and then in its root zone, have delegations to your internal namespace
nameservers for the internal top level zones.  It might also be
authoritative for some of those internal zones itself too.

On your recursive server, you configure the internal root nameserver in
your hints zone, and then when you first need to recurse, it will
'prime' the roots by querying that server for the NS records for '.'.
If that server (or those servers) doesn't (don't) respond
authoritatively with the necessary information, then your server isn't
going to be able to do recursion very successfully. :-(

If you don't have internal roots, then you don't really have any option
except to use forwarding to direct queries to another nameserver to deal
with where you don't have something else in place to resolve queries for
that specific zone.  Bear in mind that you (usually!) can't control what
names your clients will query you for if you're 'their' recursive
server, so you need some way to handle <anything> they throw at you.

For the 'known' other internal zones, you can use zone type static-stub
to 'tell' your recursive server who the authoritative servers are - and
you should just need to configure the top level(s) - everything else
below those should then be resolved recursively, starting with those
static-stub servers as the 'nearest' authoritative servers if there are
none nearer already in cache.

And finally, although this probably isn't the cause of your problems,
you're using an RFC1918 network, so depending on what else you have
configured, you might be tripping over the automatic empty zones that
named loads.  There's also a bug (to be fixed in upcoming releases)
where adding a manually configured zone of type forward as opposed to
any other type isn't disabling the creation of the automatic zone.  Take
a look at "disable-empty-zone" in the ARM, and also
https://kb.isc.org/article/AA-00800 (you'll need to register to view it,
but registration is open to all).  There's also
https://kb.isc.org/article/AA-00803 that includes a feedback comment
about the bug that was recently uncovered.

And yes - do use dig (from your recursive server) rather than nslookup
for testing - with options that you've previously had recommended to you.

Cathy