[lug] Re: dns for non-internet visible network

[Frank Whiteley]

----- Original Message ----- 
From: "David Anselmi" <anselmi at anselmi.us>
To: "William D. Knoche" <Bill.Knoche at sun.com>; "Boulder (Colorado) Linux
Users Group -- General Mailing List" <lug at lug.boulder.co.us>
Sent: Tuesday, January 04, 2005 07:23
Subject: Re: [lug] Re: dns for non-internet visible network


> William D. Knoche wrote:
> > I have a taken a slightly different approach. I have a DNS server
> > visible externally that only provides resolution for the servers that
> > need to be resolved externally. I set up an identical dns server
> > internally that is "stealth" and not visible to the outside. All
> > internal clients point to it. It forwards requests to resolve
> > external hosts to the external dns server.
>
> I wonder whether simpler might be better.
>
> [...]
> > the zone file for mydomain has all the external hosts info plus all
> > the internal hosts info. Both of these dns servers are authoritative
> > for mydomain.com. This is ok since only the internal servers will
> > access the internal dns server for all our hosts internal and
> > external and only external host (not ours) resolution is forwarded to
> > the external dns server. The external dns server is only accessed by
> > external hosts seeking to resolve the externally visible ip(s).
>
> You have internal and external records in one zone file on both internal
> and external servers?  How do you prevent external queries for internal
> records?
>
> To summarize your setup: internal server caches for internal hosts, is
> authoritative and master for mydomain.com; forwards to external server.
>   External server caches for internal server (i.e. answers recursive
> queries for non-authoritative zones), is authoritative and slave for
> mydomain.com.
>
> If I were to do it, I think I'd make the external server the master and
> authority for external data and it would not cache (it would only answer
> queries for its records).  The internal server would be the master and
> authority for internal data and would cache for internal clients.
>
> By caching on your external server, and (if you're actually) storing
> internal data externally, you make it more likely that a
> misconfiguration will expose your external server to recursive queries
> or answering with internal data.
>
> Probably I missed something and it isn't that bad.  There is some value
> in making both servers as similar as possible, to ease administration.
> But I think it's more useful to separate external data (and the external
> domain physically if not logically) from internal data.  Just me of
> course and if it works for you don't change it.
>
> Dave
> _______________________________________________

I'm reminded of a Front Range school district providing their own DNS and
inadvertently advertising their 10.x.x.x internal network including their
internal MX address.  Although their primary pipe was CW.net at the time,
they were pulling USENET from FRII.  However, due to the DNS announcement,
e-mail routing from the 1000+ FRII hosted domains and co-lo servers was
confused since FRII was using 10.x.x.x for their internal LAN.  For those
domains, the school district MX was unreachable since FRII was only
supporting NNTP port 119 via that connection.  This happened during a
migration from a *NIX DNS server to a Windows DNS server and they simply got
it wrong, however, they were unbelieving as everything appeared to be
working fine internally.  Took several calls to straighten it out since
e-mails went nowhere;^)

Frank Whiteley