redirecting root hints to fake internal root server
kcd at chrysler.com
Wed Aug 28 14:44:02 UTC 2013
On 8/28/2013 5:25 AM, Cathy Almond wrote:
> 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.
That's a risky choice, since when you forward to another server by
default, you trust it with your name resolution. As we know, trust isn't
always transitive. If they forward, and they forward, and so on,
eventually you may find that your resolution is going out to the
Internet, your users are forming VPN tunnels over DNS, and bypassing all
of your security controls.
So, my preference in this situation would be to define a root zone locally.
More information about the bind-users