DNS and RRAS (revisited)

[DublStuf]

Hi, I was wondering if this tricky DNS and RRAS issue was ever solved:

http://groups.google.com/groups?hl=en&lr=&[email protected]&rnum=11


We are having a similar problem. Our remote users cannot use DNS to
resolve our internal IP's through a vpn tunnel, BUT *from some hotels
only*. Ninety-nine percent of the time there is no issue, but we seem
to have a problem with the hotels that provide a DNS server IP to the
local NIC, *and* that hotel's DNS server answers ALL DNS queries
'authoritatively' with the IP address of what I assume is a proxy
server on their local network. So when a Windows XP computer queries
a FQDN of something on our internal network while VPN'd in from one of
these locations, it gets a response from the hotel's DNS server
indicating the IP address of the hotel's proxy, and the client tries
to use that IP to get to our server. Of course means the user has no
access to the resource on our network (Exchange for example).

I'm guessing that at more 'normal' hotels, the hotel's DNS cannot
resolve the query and so the DNS servers from the VPN are tried, which
resolve the addresses correctly and everything works.

The DNS settings the XP client is getting from our servers show the
correct DNS servers, so I'm not sure that there are any settings on
the server that will affect this. (Same behaviour in both 2000 and
2003 vpn servers)

I suspect that the problem will need correction on the client (XP) to
make it query our DNS servers through the vpn, first before attempting
to use those from the network connection provided by the hotel. I'm
posting here because this group had the only thread that seemed to
have a similar issue.

1) Does anyone have an idea on how to force the XP client to query
using the VPN DNS settings first?

I saw a suggestion to make sure the 'remote connections' appeared last
in the network binding order, and while I have yet to confirm that on
the remote users' machines, it appears to be the default in XP, so I'm
not hopeful that will resolve the issue.

2) Testing is a bit tricky with the remote users in Japan (and very
busy). Does anyone know how I could set up a system that would
imitate the hotel's? i.e. a DNS server which would answer any DNS
query for any domain with a local IP address as if it had successfully
resolved it.

Thanks,

Alan

 

[Kevin D. Goodknecht Sr. [MVP]]

In

Hi, I was wondering if this tricky DNS and RRAS issue was
ever solved:

http://groups.google.com/groups?hl=en&lr=&[email protected]&rnum=11


We are having a similar problem. Our remote users cannot
use DNS to
resolve our internal IP's through a vpn tunnel, BUT *from
some hotels
only*. Ninety-nine percent of the time there is no
issue, but we seem
to have a problem with the hotels that provide a DNS
server IP to the
local NIC, *and* that hotel's DNS server answers ALL DNS
queries
'authoritatively' with the IP address of what I assume is
a proxy
server on their local network. So when a Windows XP
computer queries
a FQDN of something on our internal network while VPN'd
in from one of
these locations, it gets a response from the hotel's DNS
server
indicating the IP address of the hotel's proxy, and the
client tries
to use that IP to get to our server. Of course means the
user has no
access to the resource on our network (Exchange for
example).

I'm guessing that at more 'normal' hotels, the hotel's
DNS cannot
resolve the query and so the DNS servers from the VPN are
tried, which
resolve the addresses correctly and everything works.

The DNS settings the XP client is getting from our
servers show the
correct DNS servers, so I'm not sure that there are any
settings on
the server that will affect this. (Same behaviour in
both 2000 and
2003 vpn servers)

I suspect that the problem will need correction on the
client (XP) to
make it query our DNS servers through the vpn, first
before attempting
to use those from the network connection provided by the
hotel. I'm
posting here because this group had the only thread that
seemed to
have a similar issue.

1) Does anyone have an idea on how to force the XP
client to query
using the VPN DNS settings first?

I saw a suggestion to make sure the 'remote connections'
appeared last
in the network binding order, and while I have yet to
confirm that on
the remote users' machines, it appears to be the default
in XP, so I'm
not hopeful that will resolve the issue.

2) Testing is a bit tricky with the remote users in
Japan (and very
busy). Does anyone know how I could set up a system that
would
imitate the hotel's? i.e. a DNS server which would
answer any DNS
query for any domain with a local IP address as if it had
successfully
resolved it.

If your AD domain name is a third level such as ad.domain.com it is fairly
easily done by adding a delegation for the third level name to the public
namespace as shown in this article.
Verification of SJC-SP-DNS-01.supplier01-int.com:
http://www.microsoft.com/windows200...enarios/scenarios/dns_vfy_sjcspdns01_01ic.asp

292822 - Name resolution and connectivity issues on a Routing and Remote
Access Server that also runs DNS or WINS:
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q292822

 

[DublStuf]

In DublStuf <[email protected]> commented
Then Kevin replied below:

If your AD domain name is a third level such as ad.domain.com it is fairly
easily done by adding a delegation for the third level name to the public
namespace as shown in this article.
Verification of SJC-SP-DNS-01.supplier01-int.com:
http://www.microsoft.com/windows200...enarios/scenarios/dns_vfy_sjcspdns01_01ic.asp

292822 - Name resolution and connectivity issues on a Routing and Remote
Access Server that also runs DNS or WINS:
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q292822

Thanks for the reply, some interesting reading there about RRAS and
name resolution. We're not running DNS or WINS on our RRAS servers,
but it's good to know about issues that could arise in that situation.

I've been able to do some more testing from the hotel in Japan, and
the problem seems to have "gone away". Their DNS server is no longer
giving answers (wrong answers) for our internal "domain.local" network
when queried. So now our remote users are resolving correctly, and
can access internal resources as per normal.

The hotel uses the 'login to their homepage and click to pay' to
charge guests to connect to the Internet, so I'm wondering if it had
something to do with that system, although they obviously had Internet
connectivity because we were able to take remote control of their
desktop to run tests at the time of the problem.

While the problem no longer seems to be happening at the moment, I'd
like to resolve it in case it occurs again. I'm going to run some
tests using a couple of different DNS servers giving conflicting IP
information for the same FQDN and see if I can figure out how it will
decide which one to use.

If anyone else has other ideas or info on this stuff, please let me
know.

Thanks,
Alan

 

[Kevin D. Goodknecht Sr. [MVP]]

In

Thanks for the reply, some interesting reading there
about RRAS and
name resolution. We're not running DNS or WINS on our
RRAS servers,
but it's good to know about issues that could arise in
that situation.

I've been able to do some more testing from the hotel in
Japan, and
the problem seems to have "gone away". Their DNS server
is no longer
giving answers (wrong answers) for our internal
"domain.local" network
when queried. So now our remote users are resolving
correctly, and
can access internal resources as per normal.

The hotel uses the 'login to their homepage and click to
pay' to
charge guests to connect to the Internet, so I'm
wondering if it had
something to do with that system, although they obviously
had Internet
connectivity because we were able to take remote control
of their
desktop to run tests at the time of the problem.

While the problem no longer seems to be happening at the
moment, I'd
like to resolve it in case it occurs again. I'm going to
run some
tests using a couple of different DNS servers giving
conflicting IP
information for the same FQDN and see if I can figure out
how it will
decide which one to use.

If anyone else has other ideas or info on this stuff,
please let me
know.

So your internal domain is domain.local?
You can create entries in the system's hosts file for the internal server's
names to fix this. What happens is without the hosts file entries the
queries go out and if the hotel's DNS answers with not found before your
internal DNS server can respond the query fails and the negative answer is
cached, causing your issue. By adding the entries to the hosts file, these
entries are loaded into the DNSCache and would go to any DNS servers,
resolving the issue.

 

[DublStuf]

So your internal domain is domain.local?
You can create entries in the system's hosts file for the internal server's
names to fix this. What happens is without the hosts file entries the
queries go out and if the hotel's DNS answers with not found before your
internal DNS server can respond the query fails and the negative answer is
cached, causing your issue. By adding the entries to the hosts file, these
entries are loaded into the DNSCache and would go to any DNS servers,
resolving the issue.

Yes, we're using "domian.local" for our internal namespace. Hosts
files would (and do) work for the name resolution problem, which is
originally what I wanted to do-- run a script to query the internal
dns and create a hosts file and distribute it to remote clients via a
GPO with slow link detection turned off... or something along those
lines. But I've been "told" that hosts files are not a satisfactory
resolution to the problem (by management).

The problem that was happening with the hotel was that their DNS
server would give a *positive* answer to "anyhost.domain.local" that
it had no business giving, of something like 10.0.0.1 (the gateway IP
on the hotel network). Whereas all hosts on our internal
"domain.local" network are in the 192.168.xx.xx range.

I've set up a test environment with conflicting DNS information for
the same zones where I can duplicate the behaviour (using a seperate
remote primary DNS server for "domain.local" with conflicting records,
placed on the same subnet as the vpn client).

So what would happen is that the name would get resolved first by the
DNS server on the foreign network by the "Local Area Connection" to an
incorrect IP (the hotel's gateway) and no other DNS servers (like the
ones from the PPP adapter) would be tried. I found an interesting
article on the order which XP queries DNS servers from each of its
interfaces:
http://www.microsoft.com/resources/...Windows/XP/all/reskit/en-us/prjj_ipa_bsmz.asp

Basically this article says that the 'preferred' adapter's first DNS
server will be queried first and if it gets an immediate answer,
that's what it goes with. So I'd like to find a way to make the
remote connection adapter the 'preferred' adapter when a remote
connection is active. Any ideas? Binding order didn't seem to have
any effect on it...

Another potential solution is to have them run "netsh" scripts upon
vpn'ing and again after disconnection, to alter the DNS setting on the
Local Area Connection to our servers and then back to DHCP. But these
are execs and they don't want to be bothered with running extra
scripts either, apparently we need to "make it work" so it's
completely transparent to them. I guess I should check if there are
'connect' and 'disconnect' scripts that can be set on the 2003 VPN
server... somehow I think 'disconnect' will be tricky though, and may
be prone to leaving their adapter with internal DNS settings, at which
point they would be unable to resolve names on the Internet.

Thanks,
Alan

 

[Kevin D. Goodknecht Sr. [MVP]]

In

"Kevin D. Goodknecht Sr. [MVP]" <[email protected]>
wrote in message


Yes, we're using "domian.local" for our internal
namespace. Hosts
files would (and do) work for the name resolution
problem, which is
originally what I wanted to do-- run a script to query
the internal
dns and create a hosts file and distribute it to remote
clients via a
GPO with slow link detection turned off... or something
along those
lines. But I've been "told" that hosts files are not a
satisfactory
resolution to the problem (by management).

Hosts file may be your only option to work around this. (read on)

The problem that was happening with the hotel was that
their DNS
server would give a *positive* answer to
"anyhost.domain.local" that
it had no business giving, of something like 10.0.0.1
(the gateway IP
on the hotel network). Whereas all hosts on our internal
"domain.local" network are in the 192.168.xx.xx range.

Another example of why admins should stay clear of wildcard records.(read
on)

I've set up a test environment with conflicting DNS
information for
the same zones where I can duplicate the behaviour (using
a seperate
remote primary DNS server for "domain.local" with
conflicting records,
placed on the same subnet as the vpn client).

I will give you another interesting option I have used one time before that
works great, see below.

So what would happen is that the name would get resolved
first by the
DNS server on the foreign network by the "Local Area
Connection" to an
incorrect IP (the hotel's gateway) and no other DNS
servers (like the
ones from the PPP adapter) would be tried. I found an
interesting
article on the order which XP queries DNS servers from
each of its
interfaces:
http://www.microsoft.com/resources/...Windows/XP/all/reskit/en-us/prjj_ipa_bsmz.asp

Basically this article says that the 'preferred'
adapter's first DNS
server will be queried first and if it gets an immediate
answer,
that's what it goes with. So I'd like to find a way to
make the
remote connection adapter the 'preferred' adapter when a
remote
connection is active. Any ideas? Binding order didn't
seem to have
any effect on it...

Another potential solution is to have them run "netsh"
scripts upon
vpn'ing and again after disconnection, to alter the DNS
setting on the
Local Area Connection to our servers and then back to
DHCP. But these
are execs and they don't want to be bothered with running
extra
scripts either, apparently we need to "make it work" so
it's
completely transparent to them. I guess I should check
if there are
'connect' and 'disconnect' scripts that can be set on the
2003 VPN
server... somehow I think 'disconnect' will be tricky
though, and may
be prone to leaving their adapter with internal DNS
settings, at which
point they would be unable to resolve names on the
Internet.

I understand what you're going through and I feel your pain. Many admins
recommend using the .local Top Level Domain for internal domain names, I
usually recommend against it because it causes the exact problems you're
having. This is why I recommend using a third level of the public domain
name, as does Microsoft, so that you can delegate the internal name in the
public zone, this is the exact setup I have.
But you're not using the third level name and you're using the .local TLD
you will have to use hosts files.

I have used one other resolution in a case like you have that has worked but
requires a regular connection to the internal network. When I say regular
that means depending on the Expire time on the SOA record as to how often
you must connect.
I installed BIND DNS on a XP laptop, then pulled a secondary zone from the
AD DNS server for the .local AD zone because this particular user didn't
want to have to keep updating a hosts file. I did increase the expire time
on the zone to 28 days for this domain so the laptop can actually go for 28
days before the zone expires, but I could have settled for a week or so
since he usually connects at least once a day. The BIND DNS does not have a
forwarder configured it just uses Root Hints for external resolution. It
would require that the VPN connection have a reserved IP address so that you
can allow zone transfers to the laptop when it connects. Since the BIND has
a secondary zone it will try to contact the Primary to check for a newer
zone using the refresh and retry values to check the primary. So until it is
connected to the VPN it cannot retrieve its new zone, once connect it
usually only takes a few minutes.
It is either this or the hosts file. There is a benefit to using the BIND
resolution, you have connectivity to a DNS server 100% of the time
regardless of whether you are connected to the internet or not.

 

[bo]

http://www.ardice.com/Arts/Movies/Titles/2/28_Days

 

[DublStuf]

I understand what you're going through and I feel your pain. Many admins

recommend using the .local Top Level Domain for internal domain names, I
usually recommend against it because it causes the exact problems you're
having. This is why I recommend using a third level of the public domain
name, as does Microsoft, so that you can delegate the internal name in the
public zone, this is the exact setup I have.
But you're not using the third level name and you're using the .local TLD
you will have to use hosts files.

I have used one other resolution in a case like you have that has worked but
requires a regular connection to the internal network. When I say regular
that means depending on the Expire time on the SOA record as to how often
you must connect.
I installed BIND DNS on a XP laptop, then pulled a secondary zone from the
AD DNS server for the .local AD zone because this particular user didn't
want to have to keep updating a hosts file. I did increase the expire time
on the zone to 28 days for this domain so the laptop can actually go for 28
days before the zone expires, but I could have settled for a week or so
since he usually connects at least once a day. The BIND DNS does not have a
forwarder configured it just uses Root Hints for external resolution. It
would require that the VPN connection have a reserved IP address so that you
can allow zone transfers to the laptop when it connects. Since the BIND has
a secondary zone it will try to contact the Primary to check for a newer
zone using the refresh and retry values to check the primary. So until it is
connected to the VPN it cannot retrieve its new zone, once connect it
usually only takes a few minutes.
It is either this or the hosts file. There is a benefit to using the BIND
resolution, you have connectivity to a DNS server 100% of the time
regardless of whether you are connected to the internet or not.

Thanks for your help and suggestions... I recently noticed that MS had
moved to using the 3rd level of a public domain for the internal
network, when writing my 2003 upgrade exams... I wasn't sure why, and
didn't remember seeing that when I did 2000, but I can see how it
could help in a situation like this. Unfortunately renaming our
internal domain structure probably isn't going to happen any time
soon.

Installing a secondary DNS on the laptops is something I wouldn't have
thought of, but I probably will fight for hosts files first to keep
things as simple as I can. I've been scouring the net and can't find
anything to change the default DNS query order in XP, or which adapter
it chooses as its 'preferred'... although I'm sure it's buried in the
registry somewhere!

Thanks again for your time and suggestions!

Alan

 

[Kevin D. Goodknecht Sr. [MVP]]

In

Thanks for your help and suggestions... I recently
noticed that MS had moved to using the 3rd level of a
public domain for the internal network, when writing my
2003 upgrade exams... I wasn't sure why, and didn't
remember seeing that when I did 2000, but I can see how
it could help in a situation like this. Unfortunately
renaming our internal domain structure probably isn't
going to happen any time soon.

Installing a secondary DNS on the laptops is something I
wouldn't have thought of, but I probably will fight for
hosts files first to keep things as simple as I can.
I've been scouring the net and can't find anything to
change the default DNS query order in XP, or which
adapter it chooses as its 'preferred'... although I'm
sure it's buried in the registry somewhere!

The DNS Client Service Does Not Revert to Using the First Server in the
List: http://support.microsoft.com/default.aspx?scid=kb;en-us;286834

The DNS Client Service Does Not Revert to Using the First Server in the List
in Windows XP:
http://support.microsoft.com/default.aspx?scid=kb;en-us;320760