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 _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
