Internal roots and Internet access ?

[Seifert, Reinhold (EDP Sys.)]

> -----Original Message-----
> From: William J. Stacey [mailto:staceyw at ameritech.net]
> Sent: Saturday, March 23, 2002 3:26 PM
> To: Seifert at seeg.sharp-eu.com
> Subject: Re: Internal roots and Internet access ?
> 
> 
> Hi Seifert.
> I am curious about this and have a few questions if you don't mind:
Sure.

> 1) How does changing from proxy to packet filtering effect your DNS?
> Are the clients using the proxy for DNS today, or are they pointed to
> their local DNS which forwards (via root hints) unknown queries to the
> hq roots?
Today, internal clients (including name servers) have *no* direct internet
access. Anything (ftp,http, smtp,...) destined for the Internet is just 
passed on to the proxy firewall. The firewall, as a proxy, does external 
name lookups on behalf of the clients (the firewall knows what's internal
and external).
Now, with a packet filter this is different because its only task is to
decide whether the packet is allowed or not depending on the filter rules.
There is no proxy functionality - therefore the client already needs to
lookup
the external name/address. Basic network routing (BTW, this is another issue

when changing the firewall "type") will route these packets to the firewall.
If source/destination/port is "ok" then the *client* is allowed to make the
connection.

> 2) These hq "root" servers are not configured as real roots are they?
> If so, how do they forward unknown INET queries to the INET?
They *are* real root name servers, but internal only. As described above, 
they don't need to know anything about the bad-bad-Internet.

> 3) Why do you put the HQ servers in root.hints on the remote 
> DNS servers instead of forwarding to HQ server?
Actually that was based on recommendations in the "DNS&BIND" bible by
Cricket Liu & Paul Albitz. I have not checked whether this is still the
case in the 4th Ed., but at that time they clearly preferred the internal
roots over forwarding.
Anyway, that setup serve{s|d} our (not so small) environment quite well.

-Reinhold

> 
> Maybe I can help if I understand your environment a little better.
> 
> --
> William Stacey, MCSE
> Microsoft MVP (Windows 2000/NT Server)
> 
> 
> "Seifert, Reinhold (EDP Sys.)" <Seifert at seeg.sharp-eu.com> wrote in
> message news:<a7bjln$oii at pub3.rc.vix.com>...
> > Hi all,
> > 
> > I'm sure this has been asked several times (therefore I apologize), 
> > but still I have no clue whatsoever how to solve my DNS problem I 
> > describe below, even though I looked through the list archive ... 
> > therefore I ask.
> > 
> > Background:
> > Currently, we have a proxying firewall. None of the 
> internal clients 
> > and nameservers have direct Internet access. In our headquarter we 
> > have two internal *root* name servers
> > which delegate directly from root to "ourdomain.com." Two 
> other boxes
> run
> > the master
> > and slave DNS for "ourdomain.com".
> > Other (also internal) offsite locations connected via LAN/WAN to the
> > headquarter run 
> > their own DNS for the corresponding subdomain, e.g.
> "xyz.ourdomain.com", as
> > master. 
> > For redundancy reasons the name servers in the headquarter 
> are slaves
> for
> > those 
> > subdomains. All internal name servers use a "db.cache" root 
> hint that
> points
> > at the 
> > headquarter's internal root name servers.
> > 
> > Now we are going to replace our proxying firewall by 
> packet-filtering 
> > firewalls. This introduces the need that at least part of 
> the internal
> 
> > clients will be able to
> > resolve Internet names.
> > 
> > That is the point where I'm stuck. Is it possible to keep the 
> > "internal roots" concept ? I have read anything between "Nope, now 
> > way" and "Yes, but tricky". The main reason I am asking is 
> because I 
> > have almost no control over the DNS at the
> > offsite locations. If at all possible I would like to avoid 
> to change
> the
> > various DNS 
> > (NT/W2k DNS, Novell, BIND 4.8, 4.9, 8.x ..) setups over there.
> > 
> > Any help/comments/hints is very much appreciated.
> > Thanks,
> > 
> > -Reinhold
> > 
> > 
> > 
> > 
>