Can internal root server also forward?

Michael Milligan milli at acmeps.com
Wed Aug 27 02:32:23 UTC 2008


Internal roots and forwarding are fundamentally incompatible, orthogonal
even.  Mixing them leads to pain.

You should only ever use forwarding to get around a firewall.

You should only ever use internal roots if you NEVER want to get around
a firewall (usually, your firewall).

What you are trying to do is possible, but will be brittle, in the sense
that you'll have to worry about hard-coded IP addresses every time
something changes in your DNS infrastructure.

I know, so far not at all helpful.

Forwarding overrides all, when looking up a (fully-qualified) domain
name.  A nameserver looks in authoritative data and the cache and if the
answer is not there and matches a forwarding rule (globally or domain
specific), then it forwards ignoring any delegations.  That's the
general problem you have to contend with and understand when trying to
make something work in your environment.

The least painful way to make this work is to open the firewall (at
least for port 53 traffic, UDP and TCP) between both companies and put a
normal delegation for the other company name space (forward- and
reverse-mapping zones) into your root (".") servers and thus having all
your internal name servers use iterative resolution to find answers.
And vice versa... but if the other company doesn't use an internal root
(likely, I rarely run across internal roots outside of the US
Government), then they can just put in stub, slave, or (least
preferably) forward zones on their side (on their global forwarders) to
catch and resolve everything on your side.

And if it's the case that you have RFC 1918 addressing conflicts on both
sides (common for a merger to involve both sides using 10/8 internally),
you could be in a world of hurt.  NAT with DNS proxies as a solution is
just the ultimate evil... avoid it if you can (i.e., renumbering is less
painful).

Hope that helps.

Regards,
Mike

joeunc wrote:
> Well what we have is that it is a seperate company outside the
> firewall that is kind of "merged" in with existing company.
> Company A wants to resolve internal hosts on Company B. The forwarding
> was hoping to not have to open all the firewalls between the two for
> the delegation from root to happen via NS records.
> We are thinking of putting in a forwarder box and delegating at
> internal root to that forwarder and then running forward only caching
> on the forwarder over to the "other" company.
> 
> thanks
> Joe
> 
> 
> 
> On Aug 25, 11:34 pm, Mark Andrews <Mark_Andr... at isc.org> wrote:
>>> Have an internal root server with zone db.root.
>>> Forwarding is not turned on as global option. Tried to add two forward
>>> zones with forward only into the root server and it would never
>>> forward. NXDOMAIN on localhost digs for that forward zone. If the zone
>>> is delegated in the the db.root file with NS  records it works
>>> obviusly, The internal root server is running BIND 9.2.2.
>>> Are there limitations on a root server having forward only zones?
>>> thanks
>>> Joe
>>         The real question is why did you decide to use forward
>>         zones rather than using a normal delegation.
>>
>>         Forward zones are there for when you need to do something
>>         special.  They are not a replacement for doing normal
>>         delegations.
>>
>>         Mark
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742                 INTERNET: Mark_Andr... at isc.org
> 
> 

-- 
Michael Milligan                                   -> milli at acmeps.com


More information about the bind-users mailing list