DNS External/Internal Shadow Domains? (WARNING: LONG)

[Kevin Darcy]

Steve,
           If your architecture allows all of your clients to resolve
Internet names, then, when your Internet connection is down, you are going to
get timeouts/failures on all queries the answers for which are not already
cached/slaved/mastered in one of your nameservers. There's really no way
around this. When the name's unavailable, it's unavailable.

    So, given this, are you just trying to make name resolution for all of
your *internal* zones completely autonomous of the Internet? You can achieve
this by ensuring that, for every internal zone you have, at least one
nameserver along every forwarding path from each internal client to the
Internet has a master, slave, or forward-to-internal-server definition, or
that the zone is within the recursive scope of a
disable-forwarding-and-use-internal-roots definition for at least one of
those nameservers. In this way, you never have to make these queries over the
Internet and they are thus unaffected by the status of your Internet
connection.

    What are the advantages of including internal roots in the mix here? If
any of the following apply:

        a) you have a lot of internal zones, which would be unmanageable to
configure individually on all of your nameservers, and/or
        b) your internal network connectivity is variable/non-robust, and/or
        c) you're concerned about all of the overhead of forwarding and/or
zone transfers between your internal nameservers,

then you may want to consider setting up internal roots. Named keeps track of
how quickly it gets responses to referred queries, and prefers faster
servers. This cached referral information allows it to adapt relatively
quickly to failures, or to changing network conditions or other forms of
congestion. Nameservers which cache and use referral information also tend to
be more efficient than forwarding nameservers when their queries tend to
"cluster" in certain parts of the namespace, since they can fetch information
about those parts of the namespace more directly. And there's no
mutual-exclusivity here either: an internal-root architecture does not
preclude you from setting up any given nameserver as a slave for a given
internal zone, if that makes more sense from an efficiency standpoint (any
subzones of that zone, however, may need separate definitions if you do
this).

    The downside to internal roots? You need to allocate separate server
resources to support the internal-root part of the architecture, since those
servers cannot be configured to forward by default to the Internet and thus
cannot be used as regular nameservers in your environment. You wouldn't
necessarily have to dedicate separate *machines* to this function; you could
just grab servers which are doing something else, e.g. webservers or
whatever, and make them internal-root nameservers, pointing their resolvers
away from themselves if necessary.

    One thing you want to do -- if I'm understanding your diagram correctly
-- which you *cannot* do, however, with the current implementation of BIND,
is to have a nameserver which is authoritative for a zone ("toast.com" in the
example) forward queries to some other nameserver for unknown names in that
zone. When a nameserver is authoritative for a zone, it thinks it knows
everything there is to know about that zone. Maybe the "views" mechanism
slated for inclusion in a future release of BIND might change this. In the
meantime, if you only want to serve up a subset of your domain to the outside
world, or if you want names in that domain to resolve differently, depending
on whether they are queried from the inside versus from the outside, you'll
probably have to separately maintain the external zone data (although some of
the new sortlist/rrset-order stuff might be an acceptable substitute in the
latter case).


- Kevin

Steve Kelley wrote:

> Hi Joe,
>
> Thanks for your response.  The issue is not to standard.
> I assume your message below assumes that the Internal name
> servers use Internal root name servers.  If so, I agree it
> seems pretty standard.  The only problem we are seeing with
> this configuration is that we would like to setup our Internal
> name servers as both the Internal root name server and Internal
> domain name server.  This causes some confusion concerning setting
> the "forward" option on the Internal name server.
>
> If you setup an Internal root name server, can it exist on a name
> server that is setup as a forwarder?
>
> How critical do you think it is to a corporation that name resolution
> relies on the Internet root name server vs. Internal root name servers?
>
> We don't have very many Internet disruptions in a given year, but we don't
> want a disruption to bring down hostname resolution internally due to
> Internet root name servers not being available.
>
> Maybe this shows you more detail as to what we are trying to accomplish:
>
>      Internet        Internet        Internet
>         |               |               |
>         |           Ext. View           |
>     jelly.com       toast.com       butter.com
>      1.1.1.0         1.1.2.0         1.1.3.0
>         |       Uses Internet Roots     |
>         |       Resolver points to      |
>         |       Internal name server    |
>         |       to handle internal name |
>         |       lookups.                |
>         |               |               |
>      Firewall        Firewall        Firewall
>         |               |               |
>         |          Internal View        |
>         |           toast.com           |
>         |       forwards to Ext. name   |
>         |       server for un resolved  |
>         |       hosts.  Delegate sub    |
>         |       domains to remote sites |
>         |       connected via WAN.      |
>         |               |               |
>          \             / \             /
>           \           /   \           /
>            \         /     \         /
>             \       /       \       /
>              \     /         \     /
>               \   /           \   /
>                \ /             \ /
>                 |               |
>         wheat.toast.com    rye.toast.com
>
> If your "internal" domains use Internet root name servers to allow
> the "internal" domain to resolve Internet hostnames, the internal
> domains can't resolve other internal subdomains as the Internet root
> name servers delegate to your external domain name servers who don't
> have a view of the internal domain structure.
>
> So if you want a true split DNS solution with both an internal/external
> view of your domain it would appear you would have to make use of a
> combination of internal root name servers, and the use of forwarders to
> resolve Internet domain names.
>
> Thanks,
> Steve...
>
>
> Joseph S D Yao wrote:
> >
> > This is pretty standard.  Internal name servers resolve all internal
> > domains.  They forward to the firewall for all unresolved queries.  No
> > domains are split in half between internal and external [or if they are,
> > you resign yourself to losing the other part of the domain].
> >
> > --
> > Joe Yao                         jsdy at cospo.osis.gov - Joseph S. D. Yao
> > COSPO/OSIS Computer Support                                     EMT-B
> > -----------------------------------------------------------------------
> > This message is not an official statement of COSPO policies.