root hints and forwarders

  • Thread starter Thread starter doobr1e
  • Start date Start date
D

doobr1e

we have a multiple site setup, basically 4 regions with wan links back
to HQ ... 1 single domain split into the seperate sites for each region
and HQ, all win2k sp4 with 2 dc's at each site

it is planned that all external traffic will come in/out via leased
lines through HQ. proxy server at HQ for web and exchange 2k servers at
each site for mail.

how should dns be setup in this setup? we are not the root server for
the domain, the ISP is (we've named the domain as domain.local) its
setup currently without any forwarders on any of the win2k servers and
its been said the root hints will resolve the names ... how does this
work? in a single server setup ive always pointed the servers dns at
itself with the dns server having the isp dns as forwarders and this
worked well but in this multiple server config im unsure about it.

should we be using forwarders from any/all of the dns servers?
do root hints resolve external address's without the use of forwarders
at all?

im a bit unclear and confused on it and could do with a few pointers.
 
Basicaly what you're gonna configure is split DNS, and it
should work fine the same way you ran it with one DNS
server. All of your internal DNS server should
have .local domain resolving no problem, and they should
have your ISP DNSs for forwarders. Or you can just setup
your HQ DNS with forwarders and rest have HQ DNS as their
forwarder
CR
 
You can't use "Split-Brain DNS" if the name of your local domain is
"domain.local". However, your setup will work. Root hints will solve your
DNS queries. Your DNS servers will cache entries for commonly used domains.
You "may" want to setup your DNS servers to forward to your ISP DNS since
they host your domain. It will speed up resolution for your domain slightly.
For the context of this discussion thread your on the right track.

ML.net
 
Either root hints or forwarders will work fine to resolve public
names. The root hints just cause an public name query
to start at the top of the domain hierarchy and work down to
resolve, while forwarding to your ISP has them do the work
and just give you back the answer. WIth the TTL caching that
goes on there's really not much performance difference.

However, I (and others) occasionally run into a problem when
I put clients on pure root hints -- a random domain or two will stop
resolving because the server thinks its gotten an invalid response.

Anyway I've seen this enough that I no longer recommend
the configuration unless there is no other choice. (And then I'll
schedule a daily restart of the DNS server service.)

Your remote office DNSen normally should forward up through your
HQ DNS, which can then forward to your ISP if needed. In rare
situations it can make sense to forward public queries
directly out of branch offices, but if the WAN links have the
headroom I prefer to channel it centrally.

Steve Duff, MCSE
Ergodic Systems, Inc.
 
However, I (and others) occasionally run into a problem when
I put clients on pure root hints -- a random domain or two will stop
resolving because the server thinks its gotten an invalid response.

Anyway I've seen this enough that I no longer recommend
the configuration unless there is no other choice. (And then I'll
schedule a daily restart of the DNS server service.)

Your remote office DNSen normally should forward up through your
HQ DNS, which can then forward to your ISP if needed. In rare
situations it can make sense to forward public queries
directly out of branch offices, but if the WAN links have the
headroom I prefer to channel it centrally.

Steve Duff, MCSE
Ergodic Systems, Inc.
Click to expand...

ok, thanks everyone for the pointers ....

so to sum up ....

it should work as is (just using root hints) with an occasional issue as
mentioned above or we can set HQ up as forwarders to ISP dns and in the
regional offices set the HQ machines that are forwarding to the ISP as
forwarders for our regional dns servers ...

taking this dns question one step into our exchange 2k migration, were
half way through it and currently exchange is acting as mail store but
mail is still being collected by internet mail through outlook, this is
soon to go completely and exchange to handle everything once everyone is
configured for exchange which is far off ....

the question is in order for outlook2k to send/receive internet mail in
this manner we have the internet mail listed as the highest priority so
that it use pop3/smtp from the client and not exchange - so to my
thinking outlook requires a path out for external name resolution to
resolve the ISP's name servers for pop/smtp mail to work ..... also
firewall for this needs to allow port 110 and 25 out as well otherwise
it will resolve the name using either root hints or forwarders but not
be able to send/receive due to firewall restrictions .... yes?
 
d> do root hints resolve external address's without the use
d> of forwarders at all?

No. The use of root hints ("standard recursion") does not
involve forwarding (which is a different kind of recursion).

<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/dns-monolithic-server-as-proxy.html>

d> should we be using forwarders from any/all of the dns servers?

Not necessarily. The choice between the two scenarios (of forwarding
and performing query resolution onesself) involves such decision
criteria as the proximity of one's own proxy DNS server to the rest
of Internet; the cost, size, and usage of the link between one and
one's ISP; the DNS namespace that the forwardee presents; the security
of the forwardee; and the shape of hole that one is capable of
knocking into one's firewall.

<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/dns-server-roles.html#ForwardingProxy>
 
M> You "may" want to setup your DNS servers to forward to your ISP
M> DNS since they host your domain. It will speed up resolution
M> for your domain slightly.

This is not necessarily true. Where one's proxy DNS server has the same IP
connectivity to the rest of Internet as the forwardee does, in the case of a
cache miss forwarding is actually slower than one's proxy DNS server
performing query resolution itself.
 
d> we can set HQ up as forwarders to ISP dns and in the regional
d> offices set the HQ machines that are forwarding to the ISP as
d> [forwardees] for our regional dns servers

If the direct link from your regional offices to the rest of Internet is
faster, less congested, or less expensive than the indirect link from those
offices to the rest of Internet via your HQ, then you should consider _not_
choosing this option.
 
d> we can set HQ up as forwarders to ISP dns and in the regional
d> offices set the HQ machines that are forwarding to the ISP as
d> [forwardees] for our regional dns servers

If the direct link from your regional offices to the rest of Internet is
faster, less congested, or less expensive than the indirect link from those
offices to the rest of Internet via your HQ, then you should consider _not_
choosing this option.
Click to expand...

the regional offices now have no link to the internet other than through
HQ ... a wan has been put in so that all external connectivity funnels
through one central point for monitoring/blocking/reporting purposes
(complete waste of the wans bandwidth if you ask me)
 
Back
Top