How is DNS resolution working?

[Ohaya]

Hi,

We have a small cluster of (all) Win2K Advanced Server machines.

One of the machines (machine A) has 2 NICs, where one of the NICs is
connected to what I will refer to as the "external" network, and the other
NIC is connected to an Ethernet switch (our "internal" network). The IP
addresses for internal network are private network address (192.xx.xx.xx).

We have several other machines (again Win2K AS) connected to that same
switch, and these all have private network addresses (again, 192.xx.xx.xx).

One of these machines (machine B) is configured as a Domain Controller, and
also has DNS Server installed and running. Machine A is a member of the
domain for which machine A is the Domain Controller.

The TCP/IP settings on both machine A and machine B are configured for fixed
IP addresses, and have the DNS server IP addresses fixed to point to machine
B (which has the DNS server).

My expectation was that if I went to machine A, and tried to do a ping of a
machine on the external network using a machine name, that that would fail,
because it would try to use the DNS server on machine B.

But, I was kind of surprised because when I did this, and I did the ping on
a machine on the external network, it was able to resolve the machine name!

I had thought that none of the machines in this configuration would be aware
of any machine names outside of the cluster, and I can't figure out why this
is happening.

Is this maybe because it's using WINS to resolve the machine name?

Any ideas?

Thanks,
Jim

 

[Ohaya]

Hi,

We have a small cluster of (all) Win2K Advanced Server machines.

One of the machines (machine A) has 2 NICs, where one of the NICs is
connected to what I will refer to as the "external" network, and the other
NIC is connected to an Ethernet switch (our "internal" network). The IP
addresses for internal network are private network address (192.xx.xx.xx).

We have several other machines (again Win2K AS) connected to that same
switch, and these all have private network addresses (again, 192.xx.xx.xx).

One of these machines (machine B) is configured as a Domain Controller, and
also has DNS Server installed and running. Machine A is a member of the
domain for which machine A is the Domain Controller.

The TCP/IP settings on both machine A and machine B are configured for fixed
IP addresses, and have the DNS server IP addresses fixed to point to machine
B (which has the DNS server).

My expectation was that if I went to machine A, and tried to do a ping of a
machine on the external network using a machine name, that that would fail,
because it would try to use the DNS server on machine B.

But, I was kind of surprised because when I did this, and I did the ping on
a machine on the external network, it was able to resolve the machine name!

I had thought that none of the machines in this configuration would be aware
of any machine names outside of the cluster, and I can't figure out why this
is happening.

Is this maybe because it's using WINS to resolve the machine name?

Any ideas?

Thanks,
Jim

Sorry. In the above, where it says:

"Machine A is a member of the domain for which machine A is the Domain
Controller."

I should've said:

"Machine A is a member of the domain for which machine B is the Domain
Controller."

 

[Ohaya]

The ping command does not depend on DNS. It can use any TCP/IP based name
resolution, including NetBIOS, hosts files, lmhost files, etc.

Doug,

Apologies if this is a dumb question, but would we have had to specifically
configure the IP address for a WINS server for NetBIOS resolution to be
working on machine A?

I know that we don't have anything in the hosts or lmhosts files on machine
A, and I know they put in the IP address of machine B as in the settings for
the DNS in network properties.

Jim

 

[Ohaya]

Doug,

Apologies if this is a dumb question, but would we have had to specifically
configure the IP address for a WINS server for NetBIOS resolution to be
working on machine A?

I know that we don't have anything in the hosts or lmhosts files on machine
A, and I know they put in the IP address of machine B as in the settings for
the DNS in network properties.

Jim

Hi,

I have to stop doing this, but I need to correct my post above.

What I meant to ask was wouldn't we have had to specifically configure
machine A to point to a WINS server for NetBIOS name resolution to be
working?

I know that on machine A, we put in a fixed IP address pointing to machine B
for the DNS, and I know that we don't have a hosts or lmhosts files, and I'm
pretty sure that we didn't configure any IP address for WINS server (at
least not on purpose).

So, what's puzzling me is if the possible name resolution mechanisms on
machine A are DNS, hosts, lmhosts, NetBIOS (not in that order), and we don't
have any of them configured on purpose except for DNS, and our DNS server on
machine B is only on a private network, how is the name resolution
succeeding???

Jim

 

[Doug Sherman [MVP]]

The ping command does not depend on DNS. It can use any TCP/IP based name
resolution, including NetBIOS, hosts files, lmhost files, etc.

Doug Sherman
MCSE Win2k/NT4.0, MCSA, MCP+I, MVP

 

[Ace Fekay [MVP]]

In

Hi,

I have to stop doing this, but I need to correct my post above.

What I meant to ask was wouldn't we have had to specifically configure
machine A to point to a WINS server for NetBIOS name resolution to be
working?

I know that on machine A, we put in a fixed IP address pointing to
machine B for the DNS, and I know that we don't have a hosts or
lmhosts files, and I'm pretty sure that we didn't configure any IP
address for WINS server (at least not on purpose).

So, what's puzzling me is if the possible name resolution mechanisms
on machine A are DNS, hosts, lmhosts, NetBIOS (not in that order),
and we don't have any of them configured on purpose except for DNS,
and our DNS server on machine B is only on a private network, how is
the name resolution succeeding???

Jim

If machine A (if I got your topology right) is using WINS and the host on
the external subnet is in WINS, and you are pinging by it's single host name
(not the whole FQDN), then yes, it's using WINS. If not, since the subnet is
directly connected, then it's going to broadcast on that subnet for the
name. If using WINS, pinging a single name will check LMHOSTS first then
WINS, but all before DNS.

--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.
This posting is provided "AS IS" with no warranties.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory

 

[Ohaya]

"Ace Fekay [MVP]"

In

If machine A (if I got your topology right) is using WINS and the host on
the external subnet is in WINS, and you are pinging by it's single host name
(not the whole FQDN), then yes, it's using WINS. If not, since the subnet is
directly connected, then it's going to broadcast on that subnet for the
name. If using WINS, pinging a single name will check LMHOSTS first then
WINS, but all before DNS.

Ace,

I should've mentioned this. When we did the ping, we used the FQDN of the
host on the external network (e.g., thehost.whatever.com).

Since we were using the external host's FQDN, would the ping still have
caused the broadcast to the external network for the name?

Or, would it only do this broadcast if we had pinged using the hostname
(e.g., thehost)?


I just thought about one other aspect about all of this that I'm starting to
wonder about that might have a bearing on all of this...

This is going to get a bit complicated, so here's what the network config
looks like:

|
|
+---- Machine A ---- Switch ----+----
| |
E | Machine B
x----+ [Domain Controller]
t |
|
+--- ExtDNS
|
|

Machine B = Domain Controller (domain name "test.foo.com")
Machine A = Member (joined to Windows domain "test.foo.com")

ExtDNS = a DNS server on external network, which does DNS for "foo.com"
Ext = a machine on the external network (ExtDNS DNS name=ext.test.foo.com)

Machine A's IP address is registered in the ExtDNS DNS server, with the name
"whatever.test.foo.com".

In other words, if you were on machine "Ext", and pinged
"whatever.test.foo.com", you would end up pinging the external interface of
machine A.

Now, we installed Machine B first, and when we installed Win2K on Machine B,
we set the machine name as "data" and the domain name as "test.foo.com". In
other words the FQDN for machine B from the internal network is
"data.test.foo.com".

I think, based on a thread i posted awhile ago, that we could've picked just
about anything for the domain name (e.g., joe.whatever.foo), but we just
happened to pick "test.foo.com".

We then installed Win2K on Machine A (the member server), and we set the
machine name as "web", and made it a member of (i.e., we joined it to)
domain "test.foo.com". In other words, the FQDN for machine A from the
internal network is "web.test.foo.com".

If you look in the DNS server on machine B, you'll see that both
"web.test.foo.com" and "data.test.foo.com" are registered, and have
"192.xx.xx.xx" IP addresses.

If you ping "web.test.foo.com" from machine B, it resolves to the internal
("192.xx.xx.xx") IP address of machine A.

If you ping "data.test.foo.com" from machine A, it resolves to the IP
address of machine B.


Again, machine B is the Domain Controller, and also has DNS Server running
on it. Machine A is a member server, joined to the domain "test.foo.com"
(whose Domain Controller is machine B).

Here's where this is going to begin sounding strange...

It just happens that on the external network, there is a Windows domain
named "foo.com".

But, remember, our machine A is joined to the domain for which machine B is
the domain controller, not that other Windows domain that is on the external
network.


I'm probably going to muddle this question, but what I'm wondering is if
there is something strange going on with the name resolution when we ping
from machine A because we just happen to pick the name of the "internal"
Windows domain such that that Windows domain's root ("test.com") is the
same as the name of the Windows domain on the external network???

Jim

 

[Ohaya]

Hi,

I want to re-word/simplify the last part of my earlier post/question.

First, here's the network configuration:

|
|
+---- Machine A ---- Switch ----+----
| "web" |
E | Registered in ExtDNS Machine B
x----+ as "whatever.foo.com" [Domain Controller "foo.com"]
t | [DNS entry points "data"
| to Machine B] [DNS server]
|
|
+--- ExtDNS [hosts DNS domain "foo.com"]
| [DNS server]
| [hosts DNS domain "foo.com"]
|

Machine B = Domain Controller (domain name "foo.com")
Machine A = Member (joined to Windows domain "foo.com")

ExtDNS = a DNS server on external network, which does DNS for "foo.com"
Ext = a machine on the external network (ExtDNS DNS name=ext.foo.com)

In the last part of my earlier post, I'm wondering if, with the above
network configuration, it might be possible that when I do a "ping
ext.foo.com" from Machine A, it might be getting confused (because the
suffix for the external network just happens to be the same as the suffix
that we assigned to Machine A), and using NetBIOS name resolution so that it
might be doing a broadcast to the external network to resolve "ext.foo.com"
instead of simply failing the name resolution?

Jim

 

[Ace Fekay [MVP]]

In

Hi,

I want to re-word/simplify the last part of my earlier post/question.

First, here's the network configuration:

|
|
+---- Machine A ---- Switch ----+----
| "web" |
E | Registered in ExtDNS Machine B
x----+ as "whatever.foo.com" [Domain Controller "foo.com"]
t | [DNS entry points "data"
| to Machine B] [DNS server]
|
|
+--- ExtDNS [hosts DNS domain
"foo.com"] | [DNS server]
| [hosts DNS domain "foo.com"]
|

Machine B = Domain Controller (domain name "foo.com")
Machine A = Member (joined to Windows domain "foo.com")

ExtDNS = a DNS server on external network, which does DNS for
"foo.com" Ext = a machine on the external network (ExtDNS DNS
name=ext.foo.com)

In the last part of my earlier post, I'm wondering if, with the above
network configuration, it might be possible that when I do a "ping
ext.foo.com" from Machine A, it might be getting confused (because the
suffix for the external network just happens to be the same as the
suffix that we assigned to Machine A), and using NetBIOS name
resolution so that it might be doing a broadcast to the external
network to resolve "ext.foo.com" instead of simply failing the name
resolution?

Jim

I'll need to see an ipconfig /all from both A and B. I'm thinking that you
are using both DNS addresses in your IP properties, unless I missed that in
your posts.

--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.
This posting is provided "AS IS" with no warranties.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory

 

[Ace Fekay [MVP]]

In

Ace,

I should've mentioned this. When we did the ping, we used the FQDN
of the host on the external network (e.g., thehost.whatever.com).

Since we were using the external host's FQDN, would the ping still
have caused the broadcast to the external network for the name?

No, FQDN pings do NOT use broadcasts.

Or, would it only do this broadcast if we had pinged using the
hostname (e.g., thehost)?
Yes




I just thought about one other aspect about all of this that I'm
starting to wonder about that might have a bearing on all of this...

This is going to get a bit complicated, so here's what the network
config looks like:

|
|
+---- Machine A ---- Switch ----+----
| |
E | Machine B
x----+ [Domain Controller]
t |
|
+--- ExtDNS
|
|

Machine B = Domain Controller (domain name "test.foo.com")
Machine A = Member (joined to Windows domain "test.foo.com")

ExtDNS = a DNS server on external network, which does DNS for
"foo.com"
Ext = a machine on the external network (ExtDNS DNS
name=ext.test.foo.com)

Machine A's IP address is registered in the ExtDNS DNS server, with
the name "whatever.test.foo.com".

In other words, if you were on machine "Ext", and pinged
"whatever.test.foo.com", you would end up pinging the external
interface of machine A.

That would make sense.

Now, we installed Machine B first, and when we installed Win2K on
Machine B, we set the machine name as "data" and the domain name as
"test.foo.com". In other words the FQDN for machine B from the
internal network is "data.test.foo.com".

I think, based on a thread i posted awhile ago, that we could've
picked just about anything for the domain name (e.g.,
joe.whatever.foo), but we just happened to pick "test.foo.com".

We then installed Win2K on Machine A (the member server), and we set
the machine name as "web", and made it a member of (i.e., we joined
it to) domain "test.foo.com". In other words, the FQDN for machine A
from the internal network is "web.test.foo.com".

I'm thinking you are providing both DNS addresses (internal and external) on
the A machine in it's IP properties. Not a good thing. Need to keep it
consistent.

If you look in the DNS server on machine B, you'll see that both
"web.test.foo.com" and "data.test.foo.com" are registered, and have
"192.xx.xx.xx" IP addresses.

If you ping "web.test.foo.com" from machine B, it resolves to the
internal ("192.xx.xx.xx") IP address of machine A.

If you ping "data.test.foo.com" from machine A, it resolves to the IP
address of machine B.


Again, machine B is the Domain Controller, and also has DNS Server
running on it. Machine A is a member server, joined to the domain
"test.foo.com" (whose Domain Controller is machine B).

Here's where this is going to begin sounding strange...

It just happens that on the external network, there is a Windows
domain named "foo.com".

But, remember, our machine A is joined to the domain for which
machine B is the domain controller, not that other Windows domain
that is on the external network.


I'm probably going to muddle this question, but what I'm wondering is
if there is something strange going on with the name resolution when
we ping from machine A because we just happen to pick the name of the
"internal" Windows domain such that that Windows domain's root
("test.com") is the same as the name of the Windows domain on the
external network???

Jim

Let us see an ipconfig /all from both machines please.

--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.
This posting is provided "AS IS" with no warranties.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory

 

[Ohaya]

In

Ace,

I should've mentioned this. When we did the ping, we used the FQDN
of the host on the external network (e.g., thehost.whatever.com).

Since we were using the external host's FQDN, would the ping still
have caused the broadcast to the external network for the name?

No, FQDN pings do NOT use broadcasts.

Or, would it only do this broadcast if we had pinged using the
hostname (e.g., thehost)?
Yes



I just thought about one other aspect about all of this that I'm
starting to wonder about that might have a bearing on all of this...

This is going to get a bit complicated, so here's what the network
config looks like:

|
|
+---- Machine A ---- Switch ----+----
| |
E | Machine B
x----+ [Domain Controller]
t |
|
+--- ExtDNS
|
|

Machine B = Domain Controller (domain name "test.foo.com")
Machine A = Member (joined to Windows domain "test.foo.com")

ExtDNS = a DNS server on external network, which does DNS for
"foo.com"
Ext = a machine on the external network (ExtDNS DNS
name=ext.test.foo.com)

Machine A's IP address is registered in the ExtDNS DNS server, with
the name "whatever.test.foo.com".

In other words, if you were on machine "Ext", and pinged
"whatever.test.foo.com", you would end up pinging the external
interface of machine A.

That would make sense.

Now, we installed Machine B first, and when we installed Win2K on
Machine B, we set the machine name as "data" and the domain name as
"test.foo.com". In other words the FQDN for machine B from the
internal network is "data.test.foo.com".

I think, based on a thread i posted awhile ago, that we could've
picked just about anything for the domain name (e.g.,
joe.whatever.foo), but we just happened to pick "test.foo.com".

We then installed Win2K on Machine A (the member server), and we set
the machine name as "web", and made it a member of (i.e., we joined
it to) domain "test.foo.com". In other words, the FQDN for machine A
from the internal network is "web.test.foo.com".

I'm thinking you are providing both DNS addresses (internal and external) on
the A machine in it's IP properties. Not a good thing. Need to keep it
consistent.

If you look in the DNS server on machine B, you'll see that both
"web.test.foo.com" and "data.test.foo.com" are registered, and have
"192.xx.xx.xx" IP addresses.

If you ping "web.test.foo.com" from machine B, it resolves to the
internal ("192.xx.xx.xx") IP address of machine A.

If you ping "data.test.foo.com" from machine A, it resolves to the IP
address of machine B.


Again, machine B is the Domain Controller, and also has DNS Server
running on it. Machine A is a member server, joined to the domain
"test.foo.com" (whose Domain Controller is machine B).

Here's where this is going to begin sounding strange...

It just happens that on the external network, there is a Windows
domain named "foo.com".

But, remember, our machine A is joined to the domain for which
machine B is the domain controller, not that other Windows domain
that is on the external network.


I'm probably going to muddle this question, but what I'm wondering is
if there is something strange going on with the name resolution when
we ping from machine A because we just happen to pick the name of the
"internal" Windows domain such that that Windows domain's root
("test.com") is the same as the name of the Windows domain on the
external network???

Jim

Let us see an ipconfig /all from both machines please.

Ace et al,

My apologies that I couldn't post back earlier. It's been a really long
day .

Also, I can't provide the "ipconfig /all" directly, as the systems
involved are on a private lan (i.e., what I termed the "external"
network is really our private corporate network (which in turn is
connected to the open Internet), but I can provide the info from an
"ipconfig /all" that I wrote down today:


Machine A:

NIC1: This is the NIC on Machine A that is physically connected to our
corporate network

IP: 10.5.1.211
Subnet: 255.255.0.0
GWY: 10.5.2.254
DNS: 192.168.1.10
BINDING ORDER: This NIC is at the top of the binding order

NIC2: This is the NIC on Machine A that is physically connected to the
"internal" Ethernet switch

IP: 192.1.1.10
Subnet: 255.255.255.0
GWY: NONE (left empty in Network/TCP properties)
DNS: 192.1.1.11
BINDING ORDER*: BOTTOM


Machine B:

NIC1: This is the NIC on Machine B that is also physically connected to
the "internet" Ethernet switch

IP: 192.1.1.11
Subnet: 255.255.255.0
GWY: NONE (left empty in Network/TCP properties)
DNS: 192.1.1.11


I went and specifically tested today, and from Machine A, I can
successfully ping both Machine A (machine name resolves to 192.1.1.10)
and Machine B (machine name resolves to 192.1.1.11). I think this name
resolution is being properly handled by the DNS server on Machine B
(192.1.1.11).

On this same machine, when I ping any other machine (i.e., name
resolves) on the external network (i.e., our corporate network). In
fact, I can ping (name resolves) any machine on the open Internet (e.g.,
www.yahoo.com resolves).

Having done this testing, contrary to what I was theorizing earlier, I
seriously doubt that the name resolution of machines on the open
Internet is happening via broadcast (I'm pretty sure my company's router
or firewall would've blocked any broadcasts out to the open Internet),
so I'm assuming that name resolution of machines on our corporate
network isn't occurring via broadcast either.

So now, I am STILL very puzzled (maybe even more puzzled than before)
about how this name resolution is occurring at all????

Consider the following:

1) Per your posts, since we are pinging by FQDN, NetBIOS name resolution
(e.g., WINS server, broadcast, and LMHOST) should not be occurring, so

2) The only remaining possibilities are either a DNS server or HOSTS
file.

3) I checked the HOSTS file on Machine A, and there are no entries other
than the default "localhost".


Based on the above, the name resolution when I ping from Machine A using
a FQDN should fail, right?

Jim

 

[Steven Umbach]

To help you track down what is exactly going on here is a couple things that can
help and what I would use. Nbtstat -r shows names resolved via netbios. Ipconfig
/displaydns shows names resolved via dns, but I would clear the cache first with
ipconfig /flushdns. The best way, is to use Netmon or other packet sniffer on
the machine trying to resolve a name. It should be readily apparent how the name
is being resolved by watching the packet exchange sequence. --- Steve

In

Ace,

I should've mentioned this. When we did the ping, we used the FQDN
of the host on the external network (e.g., thehost.whatever.com).

Since we were using the external host's FQDN, would the ping still
have caused the broadcast to the external network for the name?

No, FQDN pings do NOT use broadcasts.

Or, would it only do this broadcast if we had pinged using the
hostname (e.g., thehost)?
Yes



I just thought about one other aspect about all of this that I'm
starting to wonder about that might have a bearing on all of this...

This is going to get a bit complicated, so here's what the network
config looks like:

|
|
+---- Machine A ---- Switch ----+----
| |
E | Machine B
x----+ [Domain Controller]
t |
|
+--- ExtDNS
|
|

Machine B = Domain Controller (domain name "test.foo.com")
Machine A = Member (joined to Windows domain "test.foo.com")

ExtDNS = a DNS server on external network, which does DNS for
"foo.com"
Ext = a machine on the external network (ExtDNS DNS
name=ext.test.foo.com)

Machine A's IP address is registered in the ExtDNS DNS server, with
the name "whatever.test.foo.com".

In other words, if you were on machine "Ext", and pinged
"whatever.test.foo.com", you would end up pinging the external
interface of machine A.

That would make sense.

Now, we installed Machine B first, and when we installed Win2K on
Machine B, we set the machine name as "data" and the domain name as
"test.foo.com". In other words the FQDN for machine B from the
internal network is "data.test.foo.com".

I think, based on a thread i posted awhile ago, that we could've
picked just about anything for the domain name (e.g.,
joe.whatever.foo), but we just happened to pick "test.foo.com".

We then installed Win2K on Machine A (the member server), and we set
the machine name as "web", and made it a member of (i.e., we joined
it to) domain "test.foo.com". In other words, the FQDN for machine A
from the internal network is "web.test.foo.com".

I'm thinking you are providing both DNS addresses (internal and external) on
the A machine in it's IP properties. Not a good thing. Need to keep it
consistent.

If you look in the DNS server on machine B, you'll see that both
"web.test.foo.com" and "data.test.foo.com" are registered, and have
"192.xx.xx.xx" IP addresses.

If you ping "web.test.foo.com" from machine B, it resolves to the
internal ("192.xx.xx.xx") IP address of machine A.

If you ping "data.test.foo.com" from machine A, it resolves to the IP
address of machine B.


Again, machine B is the Domain Controller, and also has DNS Server
running on it. Machine A is a member server, joined to the domain
"test.foo.com" (whose Domain Controller is machine B).

Here's where this is going to begin sounding strange...

It just happens that on the external network, there is a Windows
domain named "foo.com".

But, remember, our machine A is joined to the domain for which
machine B is the domain controller, not that other Windows domain
that is on the external network.


I'm probably going to muddle this question, but what I'm wondering is
if there is something strange going on with the name resolution when
we ping from machine A because we just happen to pick the name of the
"internal" Windows domain such that that Windows domain's root
("test.com") is the same as the name of the Windows domain on the
external network???

Jim

Let us see an ipconfig /all from both machines please.

Ace et al,

My apologies that I couldn't post back earlier. It's been a really long
day .

Also, I can't provide the "ipconfig /all" directly, as the systems
involved are on a private lan (i.e., what I termed the "external"
network is really our private corporate network (which in turn is
connected to the open Internet), but I can provide the info from an
"ipconfig /all" that I wrote down today:


Machine A:

NIC1: This is the NIC on Machine A that is physically connected to our
corporate network

IP: 10.5.1.211
Subnet: 255.255.0.0
GWY: 10.5.2.254
DNS: 192.168.1.10
BINDING ORDER: This NIC is at the top of the binding order

NIC2: This is the NIC on Machine A that is physically connected to the
"internal" Ethernet switch

IP: 192.1.1.10
Subnet: 255.255.255.0
GWY: NONE (left empty in Network/TCP properties)
DNS: 192.1.1.11
BINDING ORDER*: BOTTOM


Machine B:

NIC1: This is the NIC on Machine B that is also physically connected to
the "internet" Ethernet switch

IP: 192.1.1.11
Subnet: 255.255.255.0
GWY: NONE (left empty in Network/TCP properties)
DNS: 192.1.1.11


I went and specifically tested today, and from Machine A, I can
successfully ping both Machine A (machine name resolves to 192.1.1.10)
and Machine B (machine name resolves to 192.1.1.11). I think this name
resolution is being properly handled by the DNS server on Machine B
(192.1.1.11).

On this same machine, when I ping any other machine (i.e., name
resolves) on the external network (i.e., our corporate network). In
fact, I can ping (name resolves) any machine on the open Internet (e.g.,
www.yahoo.com resolves).

Having done this testing, contrary to what I was theorizing earlier, I
seriously doubt that the name resolution of machines on the open
Internet is happening via broadcast (I'm pretty sure my company's router
or firewall would've blocked any broadcasts out to the open Internet),
so I'm assuming that name resolution of machines on our corporate
network isn't occurring via broadcast either.

So now, I am STILL very puzzled (maybe even more puzzled than before)
about how this name resolution is occurring at all????

Consider the following:

1) Per your posts, since we are pinging by FQDN, NetBIOS name resolution
(e.g., WINS server, broadcast, and LMHOST) should not be occurring, so

2) The only remaining possibilities are either a DNS server or HOSTS
file.

3) I checked the HOSTS file on Machine A, and there are no entries other
than the default "localhost".


Based on the above, the name resolution when I ping from Machine A using
a FQDN should fail, right?

Jim

 

[Ohaya]

To help you track down what is exactly going on here is a couple things that can
help and what I would use. Nbtstat -r shows names resolved via netbios. Ipconfig
/displaydns shows names resolved via dns, but I would clear the cache first with
ipconfig /flushdns. The best way, is to use Netmon or other packet sniffer on
the machine trying to resolve a name. It should be readily apparent how the name
is being resolved by watching the packet exchange sequence. --- Steve

Steve,

Thanks. I'll try the nbtstat -r and ipconfig /displaydns tomorrow at the
lab, but I'm not familiar with Netmon. Where can I get that? Is it a part
of Windows?

Jim

 

[Steven L Umbach]

Netmon is part of any W2K or W2003 server operating system though you may need to
install it with add/remove programs windows components. There are also third party
free packet sniffers. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;243270
http://www.ethereal.com/

 

[Ace Fekay [MVP]]

In

Ace et al,

My apologies that I couldn't post back earlier. It's been a really
long
day .

Also, I can't provide the "ipconfig /all" directly, as the systems
involved are on a private lan (i.e., what I termed the "external"
network is really our private corporate network (which in turn is
connected to the open Internet), but I can provide the info from an
"ipconfig /all" that I wrote down today:


Machine A:

NIC1: This is the NIC on Machine A that is physically connected to our
corporate network

IP: 10.5.1.211
Subnet: 255.255.0.0
GWY: 10.5.2.254
DNS: 192.168.1.10
BINDING ORDER: This NIC is at the top of the binding order

NIC2: This is the NIC on Machine A that is physically connected to the
"internal" Ethernet switch

IP: 192.1.1.10
Subnet: 255.255.255.0
GWY: NONE (left empty in Network/TCP properties)
DNS: 192.1.1.11
BINDING ORDER*: BOTTOM


Machine B:

NIC1: This is the NIC on Machine B that is also physically connected
to
the "internet" Ethernet switch

IP: 192.1.1.11
Subnet: 255.255.255.0
GWY: NONE (left empty in Network/TCP properties)
DNS: 192.1.1.11


I went and specifically tested today, and from Machine A, I can
successfully ping both Machine A (machine name resolves to 192.1.1.10)
and Machine B (machine name resolves to 192.1.1.11). I think this
name resolution is being properly handled by the DNS server on
Machine B (192.1.1.11).

On this same machine, when I ping any other machine (i.e., name
resolves) on the external network (i.e., our corporate network). In
fact, I can ping (name resolves) any machine on the open Internet
(e.g., www.yahoo.com resolves).

Having done this testing, contrary to what I was theorizing earlier, I
seriously doubt that the name resolution of machines on the open
Internet is happening via broadcast (I'm pretty sure my company's
router
or firewall would've blocked any broadcasts out to the open Internet),
so I'm assuming that name resolution of machines on our corporate
network isn't occurring via broadcast either.

So now, I am STILL very puzzled (maybe even more puzzled than before)
about how this name resolution is occurring at all????

Consider the following:

1) Per your posts, since we are pinging by FQDN, NetBIOS name
resolution (e.g., WINS server, broadcast, and LMHOST) should not be
occurring, so

2) The only remaining possibilities are either a DNS server or HOSTS
file.

3) I checked the HOSTS file on Machine A, and there are no entries
other
than the default "localhost".


Based on the above, the name resolution when I ping from Machine A
using
a FQDN should fail, right?

Jim

Interesting setup. Besides Steve;s suggestion to do some netmon captures to
figure out exactly how it's resolving it, I *think* possibly your Binding
order on machine A should be reversed. Usually in most cases, the internal
corporate network interface wouldn't have a gateway if this guy is
performing NAT. Even if it isn't, you should make the DNS server address
consistent, meaning either use 192.1.1.11or 192.168.1.10. In my view, with
the info you provided, your corp DNS is 192.1.1.11 and that should be used
on BOTH NICs. The reason so far I see is that it's using 192.168.1.10 for
resolution due to your binding order and never gets to 192.1.1.11. See what
I mean?

Try rearraiging the Binding order or just make your DNS server addresses
consistent on both NICs. That is usually best practice so we can eliminate
guess work on what is using what to resolve what and rely on your DNS
server's infrastructure design and forwarding to resolve what you need to.
This will also insure proper AD resolution for this machine considering it's
an AD member.

Make sense?


--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.
This posting is provided "AS IS" with no warranties.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory

 

[Ohaya]

"Ace Fekay [MVP]"

In Ohaya <ohaya@N_O_S_P_A_M_cox.net> posted their thoughts, then I offered mine

Interesting setup. Besides Steve;s suggestion to do some netmon captures to
figure out exactly how it's resolving it, I *think* possibly your Binding
order on machine A should be reversed. Usually in most cases, the internal
corporate network interface wouldn't have a gateway if this guy is
performing NAT. Even if it isn't, you should make the DNS server address
consistent, meaning either use 192.1.1.11or 192.168.1.10. In my view, with
the info you provided, your corp DNS is 192.1.1.11 and that should be used
on BOTH NICs. The reason so far I see is that it's using 192.168.1.10 for
resolution due to your binding order and never gets to 192.1.1.11. See what
I mean?

Try rearraiging the Binding order or just make your DNS server addresses
consistent on both NICs. That is usually best practice so we can eliminate
guess work on what is using what to resolve what and rely on your DNS
server's infrastructure design and forwarding to resolve what you need to.
This will also insure proper AD resolution for this machine considering it's
an AD member.

Make sense?

Ace,

Sorry, the IP address for the DNS on Machine A, NIC1 in the email above was
a typo. It already is 192.1.1.11 ...

As to the binding order, we have this binding order for a very specific
reason. Again, this is going to be complicated.

We have an IIS server running on Machine A, with 2 IIS websites.

The first website is bound to the IP address of NIC1 (10.5.1.211) for ports
8000 (for non-secure HTTP) and 443 (for HTTPS/SSL). This first website is
also configured for both server and client authentication, which means that
to connect to this website, the client end of any connection to the website
has to have a client certificate.

In the application in the first website, there were some situations where we
had to make web requests to itself. But, like I said above, to do this, our
app would have effectively have had a client certificate for these
requests/connections to succeed.

It turns out that for software reasons, this was a problem. Also with the
software we had, we had to have these "loopback" web requests go to the same
hostname (don't ask why !!!).

So, we came up with a scheme whereby we created a second website in IIS,
which we mapped to the same directories as the first website (in other
words, the second website is the same as the first website), but we did not
want anyone to be able to access this second website from the external
network (i.e., only requests from the first website should work), and we
wanted these "loopback" requests to be secured, so we configured this second
website for SSL server authentication only.

In order for this "loopback" scheme to work, effectively, we have to make
sure that when we do name resolution from Machine A, that it resolves to the
192.1.1.10 IP address and NOT the 10.5.1.211 IP address, and the binding
order that I indicated above was what we needed to do this.

You probably have a headache now ... believe me, I have one !!

Anyway, to reiterate, the IP address that I have for the DNS on NIC1 of
Machine A is already 192.1.1.11, and I'll try Steve's suggestions tomorrow,
but I'm still confused why we can resolve names of machines on the external
network from Machine A.

Jim

 

[Ace Fekay [MVP]]

In

Ace,

Sorry, the IP address for the DNS on Machine A, NIC1 in the email
above was a typo. It already is 192.1.1.11 ...

As to the binding order, we have this binding order for a very
specific reason. Again, this is going to be complicated.

We have an IIS server running on Machine A, with 2 IIS websites.

The first website is bound to the IP address of NIC1 (10.5.1.211) for
ports 8000 (for non-secure HTTP) and 443 (for HTTPS/SSL). This first
website is also configured for both server and client authentication,
which means that to connect to this website, the client end of any
connection to the website has to have a client certificate.

In the application in the first website, there were some situations
where we had to make web requests to itself. But, like I said above,
to do this, our app would have effectively have had a client
certificate for these requests/connections to succeed.

It turns out that for software reasons, this was a problem. Also
with the software we had, we had to have these "loopback" web
requests go to the same hostname (don't ask why !!!).

So, we came up with a scheme whereby we created a second website in
IIS, which we mapped to the same directories as the first website (in
other words, the second website is the same as the first website),
but we did not want anyone to be able to access this second website
from the external network (i.e., only requests from the first website
should work), and we wanted these "loopback" requests to be secured,
so we configured this second website for SSL server authentication
only.

In order for this "loopback" scheme to work, effectively, we have to
make sure that when we do name resolution from Machine A, that it
resolves to the 192.1.1.10 IP address and NOT the 10.5.1.211 IP
address, and the binding order that I indicated above was what we
needed to do this.

You probably have a headache now ... believe me, I have one !!

Anyway, to reiterate, the IP address that I have for the DNS on NIC1
of Machine A is already 192.1.1.11, and I'll try Steve's suggestions
tomorrow, but I'm still confused why we can resolve names of machines
on the external network from Machine A.

Jim

Hmm...I'm going to stop trying to think about this....I assumed alot based
on the typo.

Probably, jsut probably, you can't resolve stuff on the external DMZ since
you're properl;y using your internal DNS, which is forwarding out (I think
now, and not enough time to re-read this thread).

Do the netmon thing...you'll find it helpful, since you;re more familiar
with your arrangements and reasons for doing it.


And I don't understand how 192.1.1.11 is a private IP??
That IP is owned by someone....Is this you?

Search results for: 192.1.1.11
BBN Communications BBN-CNETBLK (NET-192-1-0-0-1)
192.1.0.0 - 192.1.255.255
Bolt Beranek and Newman Inc. BBN-WAN (NET-192-1-1-0-1)
192.1.1.0 - 192.1.1.255

# ARIN WHOIS database, last updated 2004-02-26 19:15
# Enter ? for additional hints on searching ARIN's WHOIS database.


--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.
This posting is provided "AS IS" with no warranties.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory

 

[Ohaya]

In

Hmm...I'm going to stop trying to think about this....I assumed alot based
on the typo.

Probably, jsut probably, you can't resolve stuff on the external DMZ since
you're properl;y using your internal DNS, which is forwarding out (I think
now, and not enough time to re-read this thread).

Do the netmon thing...you'll find it helpful, since you;re more familiar
with your arrangements and reasons for doing it.

And I don't understand how 192.1.1.11 is a private IP??
That IP is owned by someone....Is this you?

Search results for: 192.1.1.11
BBN Communications BBN-CNETBLK (NET-192-1-0-0-1)
192.1.0.0 - 192.1.255.255
Bolt Beranek and Newman Inc. BBN-WAN (NET-192-1-1-0-1)
192.1.1.0 - 192.1.1.255

# ARIN WHOIS database, last updated 2004-02-26 19:15
# Enter ? for additional hints on searching ARIN's WHOIS database.

Ace,

I've appreciated all your (and others') help thus far. Please don't
give up on me now ...

I wonder if what you mentioned above (the private IP) may be either THE
or part of the problem? Those 192... IP addresses are definitely what
we had, but I now realize that for private IP addresses, we should have
had 192.168.xx.xx IP addresses instead.

The 192... IP addresses that were picked were just made up, so I'll try
changing them to 192.168.0.xx when I get into the lab later today.

In the meantime, I was up all night last night, and have configured 2
completely different machines here so that I can duplicate the above
network setup. I still have a couple of pieces to add (dual NIC), but
once I do that, I think that I'll be able to test more conveniently
(including running Netmon if it gets to that), so I hope that you all
keep watching out for more postings on this.

Jim

 

[Ohaya]

Ace,

I've appreciated all your (and others') help thus far. Please don't
give up on me now ...

I wonder if what you mentioned above (the private IP) may be either THE
or part of the problem? Those 192... IP addresses are definitely what
we had, but I now realize that for private IP addresses, we should have
had 192.168.xx.xx IP addresses instead.

The 192... IP addresses that were picked were just made up, so I'll try
changing them to 192.168.0.xx when I get into the lab later today.

In the meantime, I was up all night last night, and have configured 2
completely different machines here so that I can duplicate the above
network setup. I still have a couple of pieces to add (dual NIC), but
once I do that, I think that I'll be able to test more conveniently
(including running Netmon if it gets to that), so I hope that you all
keep watching out for more postings on this.

Jim

Hi All,

I haven't completed setting my own test configuration yet, but while I
was in the lab today, I went ahead and changed the 192.1.xx.xx IP
addresses on both Machine A and Machine B to 192.168.xx.xx.

On Machine B, where the DNS server is running, I also changed the DNS
setting for that machine to point to 127.0.0.1.

I only had a short time to test in the lab after that, but it seemed
like the above changes worked, and after that:

- I was able to ping both Machine A and Machine B from Machine A, and
names resolved correctly to 192.168.xx.xx IP addresses, and
- I was able to ping both Machine A and Machine B from Machine B, and
names resolved correctly to 192.168.xx.xx IP addresses, and
- From Machine A, when I tried to ping any machines on the external
network, I'd get an "Unknown host" error (i.e., name resolution failed).

As mentioned in my earlier post, I'm still hoping to cobble together a
test system myself, and will post back after that, but if my testing
today is correct, I still don't understand why using the 192.1.xx.xx IP
addresses on the internal side of the network was allowing name
resolution of machines on the external network.

Thanks again,
Jim

 

[Ace Fekay [MVP]]

In

Ace,

I've appreciated all your (and others') help thus far. Please don't
give up on me now ...

I wonder if what you mentioned above (the private IP) may be either
THE
or part of the problem? Those 192... IP addresses are definitely what
we had, but I now realize that for private IP addresses, we should
have
had 192.168.xx.xx IP addresses instead.

The 192... IP addresses that were picked were just made up, so I'll
try changing them to 192.168.0.xx when I get into the lab later today.

In the meantime, I was up all night last night, and have configured 2
completely different machines here so that I can duplicate the above
network setup. I still have a couple of pieces to add (dual NIC), but
once I do that, I think that I'll be able to test more conveniently
(including running Netmon if it gets to that), so I hope that you all
keep watching out for more postings on this.

Jim

I haven't given up... Kind of a confusing scenario you have. I see you
posted a fresh post regarding this. Hopefully someone else will see
something that I/we may have missed.

--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.
This posting is provided "AS IS" with no warranties.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory