Forwarding from Internal DNS server.

[Kevin Darcy]

union wrote:

> Hi Kevin,Jim
>
> Thanks for the responses!
>
> I will try better explain what I am trying to achieve.
>
> The setup I am trying to put into effect is a split namespace to do the
> following :
>
> Let all internal hosts resolve all  internal names from the internal DNS
> system, and all external Internet names be resolved by the local ISP's DNS.
> (I was hoping that the internal DNS would be able to forward these queries
> onto the ISP's DNS). ie.) Internally we want to see  internal namespaces +
> external Internet namespace.
> All external Internet hosts can only see a sub-set of out internal namespace
> (Shadow namespace hosted on ISP's DNS). Address translation takes place
> through the firewall.
> Internal default routes on local Lans point to the local firewall.
> The objective:
> If an address request for an external Internet host, made from an internal
> host, "COULD?" be obtained by the internal DNS system forwarding all
> unresolved external queries to the ISP's DNS, then internal users should be
> able to browse/send mail/FTP both internally , and externally.

You can get a "mix" of your internal DNS data and the Internet DNS data by
using standard forwarding schemes. "views", if and when they are implemented,
and depending on exactly *how* they are implemented, may be able to save you
from having to maintain separate internal/external copies of your zones, by
forwarding queries on NXDOMAIN. It's a further optimization to "split" DNS, in
other words, but you can still do split DNS the old-fashioned way without
views.

> If I change the DNS setup so that internal hosts can only see the internal
> namespace on Internal DNS servers then I have to setup a local mail relay
> host(that uses the ISP's DNS, and my internal DNS wildcard MX's will point
> to this relay) to forward all Internet mail.

See above. You can make the external DNS visible to your internal clients via
forwarding.

> I would also then have to set
> up a proxy server(which also uses the local ISP's DNS) to allow
> browsing/FTPing  on the Internet. This model now means that I now have to
> maintain a mail relay,proxy server, and internal DNS system.

I'm not sure why you keep saying you have to use an ISP's DNS. Don't you have
machines with direct Internet access, i.e. at the very least, your firewall(s)?
Can't you run a nameserver on them? That would remove the reliance on your
ISP's DNS.

> I guess on the
> different internal root servers I could try and setup the wilcard MX's to
> point to there local mail relay.

Now you seem to be talking about multiple internal roots. It can be done, but
it's not very maintainable...

> While the approach that I was trying to get
> working above means that I need to only maintain an internal DNS system, and
> an externally resolvable name would allow the default routes to use the
> local ISP connection.
>
> Is it not possibly to get the first method working?? And if so what are my
> missing components?

As described, you can make the Internet DNS visible through forwarding, and
this doesn't require "views".

But you still seem to be alluding to a requirement that mail should always go
out a "close" mail gateway. If you want to "customize" MX records, then this is
not compatible with resolving the names from the Internet DNS, since the
Internet DNS will, assuming all nameservers in the chain are configured
normally and operating properly, give the same MX answers to everyone. To
satisfy *that* requirement, you would have to either a) run multiple internal
roots (yuck), b) have all of the internal-root MX'es resolve to
"global" gateway names containing the addresses of *all* the outbound gateways,
which you could then sortlist, or c) give up using MX'es for outbound mail
routing altogether. The major downside of (a) and (b), as you identified, is
that now your clients don't have visibility to Internet names, so you have to
proxy *everything*. The downside of (c), of course, is that now you have no
convenient, centralized way of controlling mail routing, you have to rely on
local mail-routing configuration (although, as Jim pointed out, you could
minimize this by funnelling the mail through "smart" mailhosts). It's your
decision as to what the best solution is.


- Kevin