Archived from groups: microsoft.public.win2000.dns (
More info?)
"RichWhit" <RichWhit@discussions.microsoft.com> wrote in message
news
94DFF26-6382-4B24-BC9C-0C5575BC20C0@microsoft.com...
> It is your opinion that I should publish the public and private IP address
in
> the internal DNS zone?
>
No, not exactly. It is my advice to publish all Private Addresses
you wish to in the internal (version of the) zone, and to also publish
only those public addresses there which will not conflict.
Publishing a public address is of course unnecessary if the particular
resource is not ever needed by internal users, but other than that publish
it -- BUT ONLY if it is not already published via an internal address.
The goal is to give the internal users (via the Internal DNS) ALL of
the resources available with internal addresses, and then supplement
this by listing any public resources only available through the public
IP.
After that, the problem boils down to routing (and perhaps firewall
filters.)
--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
> "Herb Martin" wrote:
>
> > "RichWhit" <RichWhit@discussions.microsoft.com> wrote in message
> > news:42FF161F-AD4C-4D08-B292-75FDF76B18F6@microsoft.com...
> > > I do maintain the same dns zones internally and externally. The
external
> > dnz
> > > zones have the public IP addresses that need to be accessed publicly
and
> > the
> > > internal dns zone has the private internal IP addresses listed for the
all
> > > internal resources.
> >
> > Makes sense, but the INTERNAL must also have all of the external
> > records (and addresses) for any resources you wish the internal users
> > to contact.
> >
> > > There is a NAT translation done at the firewall. If a
> > > user is connected to the internal network via the VPN server which is
> > located
> > > behind the firewall, only private IP address can be used.
> >
> > Why? In theory, it can come with private and go back out through the
> > NAT to acceptable Internet locations (e.g., Microsoft.com) IF you have
> > the routing setup properly.
> >
> > Likely you would prefer to use an internal address for any resource
> > that exists with both internal and external addresses.
> >
> > > Some users do not
> > > get the private IP address from the internal DNS server, but rather
get
> > the
> > > public IP address from their ISP dns server. If the resource is not
> > listed
> > > in the public DNS then the client gets the private IP address from the
> > > private DNS server.
> >
> > No, you cannot expect a client (or ordinary forwarding/recursing DNS
server)
> > to check "two DNS servers" if the first one fails to resolve or gives
out
> > unusable
> > addresses.
> >
> > DNS clients ONLY check one DNS system (one working DNS server) and that
> > one must resolve everything that is needed by that client.
> >
> > People commonly try to put in Preferred and Alternate DNS DNS servers
from
> > different DNS server "sets" in the mistaken belief that clients will
keep
> > checking;
> > they will not.
> >
> >
> > > How can I force name resolution to use only the internal
> > > private dns server provided through the DHCP settings projected
through
> > the
> > > VPN server to the VPN client.
> >
> > Normally an RRAS client (VPN or RRAS) uses the DNS server (and WINS
server
> > and Default Gateways) from the RRAS server -- these are given priority
WHILE
> > the connection is in place. When the connection is dropped the
interface
> > (VPN/RAS)
> > specific stuff if removed and the machine goes back to using the normal
NIC
> > property stuff it has configured.
> >
> > You can test such things by looking at "ipconfig /all" and by using
programs
> > (while
> > connected) like "Nslookup TARGET" to see which is the "current default"
DNS
> > server.
> >
> > You can also use "Nslookup TARGET IP_SPECIFIC_DNS_SERVER" to see
> > if this would get you a different answer.
> >
> > --
> > Herb Martin, MCSE, MVP
> > Accelerated MCSE
> >
http://www.LearnQuick.Com
> > [phone number on web site]
> >
> > >
> > > "Herb Martin" wrote:
> > >
> > > > "RichWhit" <RichWhit@discussions.microsoft.com> wrote in message
> > > > news:7A5FBCEF-1BC1-4208-B3AA-AC48BC22668B@microsoft.com...
> > > > > I have a private NAT internal network with private internal DNS
server
> > and
> > > > I
> > > > > have a public DNS hosted for my publicly available servers and
> > services.
> > > > > When some users connect to the private internal network using
> > Microsoft
> > > > VPN
> > > > > client, they are not able to get the private internal IP address
of
> > any
> > > > > publicly available resource. Because the internal network does
not
> > know
> > > > how
> > > > > to route public IP addresses, these users are not able to connect
to
> > the
> > > > > Exchange server or internal web sites. Does anyone have a
suggestion
> > as
> > > > to
> > > > > how to resolve this issue?
> > > >
> > > > You are mingling a DNS problem with a routing problem -- such are
almost
> > > > totally separate. Routing should be solved first, then DNS made to
> > work.
> > > >
> > > > If you have the "same zone (name)" inside as outside this is termed
> > "Shadow
> > > > DNS" (or split DNS" and requires that you MANUALLY duplicate all
useful
> > > > external resources into the internal version of the zone.
> > > >
> > > >
> > > > > This is only an issue for some users. The
> > > > > clients are configured with default VPN settings that stipulate to
use
> > the
> > > > > local default gateway. If the address is not listed in the public
> > DNS,
> > > > then
> > > > > the private DNS address is resolved from the internal DNS server.
> > > >
> > > > Tell us very explicitly how this routes -- do a lot of "tracert"
using
> > IP
> > > > addresses and focus on where things go wrong (wrong initial router,
> > > > stuck in the VPN, wherever.)
> > > >
> > > > Then lets figure out the DNS if it is still broken after you
configure
> > you
> > > > shadow DNS (if that is what you have) corrrectly.
> > > >
> > > > --
> > > > Herb Martin, MCSE, MVP
> > > > Accelerated MCSE
> > > >
http://www.LearnQuick.Com
> > > > [phone number on web site]
> > > >
> > > >
> > > >
> >
> >
> >
Facebook
Twitter
Instagram