Internal Websites Periodically Can't Be Resolved

  • Thread starter Thread starter Mark Olbert
  • Start date Start date
M

Mark Olbert

Hi all,

I'm having a problem with a Win2K server (SP4) that I use to host multiple ASP.NET development
projects. I use multihoming to give each project website a separate IP address.

What happens is this: when I first turn on my client (XP SP1) machine in the morning (which is
connected by a LAN to the server) I cannot surf to any of the internal websites (in IE I get page
not found / can't be displayed errors, while Visual Studio just refuses to load the project because
it can't contact the site).

If I then open a command window and do an nslookup on the internal site it works fine. However,
tracert and ping both fail.

Opening IE and surfing to the numeric IP address of the site instantly brings it up (which is what
makes me think this is a DNS problem).

Previously I've worked around this problem by going down to the server, resetting the DNS, and
waiting about 10 or 15 minutes. At that point my client machine can again resolve the human-readable
site names and all works as expected.

But if I stop working on the sites for a couple of hours the problem re-occurs.

This morning when I ran into the problem I tried running an ipconfig /registerdns on the client XP
machine. The sites were instantly resolvable after doing that.

The only odd thing I've noticed about the DNS records on the server is that there are multiple
"blank" A records (which say something like (same as parent folder) for the name). It looks like
these records are being created, one for each of the multihomed websites.

Can someone explain what the heck is going on? And, more importantly, how I can make the problem go
away?

- Mark
 
In
Mark Olbert said:
Hi all,

I'm having a problem with a Win2K server (SP4) that I use to host
multiple ASP.NET development projects. I use multihoming to give each
project website a separate IP address.

What happens is this: when I first turn on my client (XP SP1)
machine in the morning (which is connected by a LAN to the server) I
cannot surf to any of the internal websites (in IE I get page not
found / can't be displayed errors, while Visual Studio just refuses
to load the project because it can't contact the site).

If I then open a command window and do an nslookup on the internal
site it works fine. However, tracert and ping both fail.

Opening IE and surfing to the numeric IP address of the site
instantly brings it up (which is what makes me think this is a DNS
problem).

Previously I've worked around this problem by going down to the
server, resetting the DNS, and waiting about 10 or 15 minutes. At
that point my client machine can again resolve the human-readable
site names and all works as expected.

But if I stop working on the sites for a couple of hours the problem
re-occurs.

This morning when I ran into the problem I tried running an ipconfig
/registerdns on the client XP machine. The sites were instantly
resolvable after doing that.

The only odd thing I've noticed about the DNS records on the server
is that there are multiple "blank" A records (which say something
like (same as parent folder) for the name). It looks like these
records are being created, one for each of the multihomed websites.

Can someone explain what the heck is going on? And, more importantly,
how I can make the problem go away?

- Mark
Click to expand...

Couple questions:

1. WHat DNS addresses is the client using?
If there is an ISP's DNS in there, that can cause unpredictable results,
and suggest to only use your internal DNS server(s) only and not the ISP's.
Recommended to configure a forwarder for efficient Internet resolution.

2. Is AD on your network??
If so, the blank records (called the LdapIpAddress) are being created
automatically by AD for each DC that exists in the domain. Clients use this
to connect to the domain's sysvol when applying a GPO, such as:
\\domain.com\sysvol\domain.com\policies

3. What method are you trying to connect to the site?
www.domain.com
or
http://domain.com
?
If the latter, then see question and explanation in # 2.

--
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
 
1. WHat DNS addresses is the client using?
If there is an ISP's DNS in there, that can cause unpredictable results,
and suggest to only use your internal DNS server(s) only and not the ISP's.
Recommended to configure a forwarder for efficient Internet resolution.
Click to expand...

The internal LAN uses only 192.168.1.x addresses. The websites currently occupy 192.168.1.150
through 192.168.1.155.
2. Is AD on your network??
If so, the blank records (called the LdapIpAddress) are being created
automatically by AD for each DC that exists in the domain. Clients use this
to connect to the domain's sysvol when applying a GPO, such as:
\\domain.com\sysvol\domain.com\policies
Click to expand...

Yes, the server is the PDC for the domain, and is running AD. I can understand the blank record
existing for one of the multihomed addresses, but why all of them?
3. What method are you trying to connect to the site?
www.domain.com
or
http://domain.com
?
Click to expand...

I configure the multihome addresses to point to different hosts, e.g.,

192.168.1.150 --> site1.mydomain.com
192.168.1.151 --> site2.mydomain.com

The LAN is not accessible from the internet (i.e., it runs behind a linux firewall/router).

Any suggestions on fixing the problem?

- Mark
 
In Mark Olbert <[email protected]> posted a question
Then Kevin replied below:
:: 1. WHat DNS addresses is the client using?
:: If there is an ISP's DNS in there, that can cause unpredictable
:: results, and suggest to only use your internal DNS server(s) only
:: and not the ISP's. Recommended to configure a forwarder for
:: efficient Internet resolution.
:
: The internal LAN uses only 192.168.1.x addresses. The websites
: currently occupy 192.168.1.150 through 192.168.1.155.
:
::
:: 2. Is AD on your network??
:: If so, the blank records (called the LdapIpAddress) are being
:: created automatically by AD for each DC that exists in the domain.
:: Clients use this to connect to the domain's sysvol when applying a
:: GPO, such as: \\domain.com\sysvol\domain.com\policies
:
: Yes, the server is the PDC for the domain, and is running AD. I can
: understand the blank record existing for one of the multihomed
: addresses, but why all of them?

DCs will create a blank record for every IP on them, that is one reason
multi homing a DC is not recomended. Not only will you have a blank
<dnsdomainname> for each IP if you look down in gc._msdcs.<dnsdomainname>
there will be another blank record for each IP address.
Instead of mutihoming your DC, give the websites a host header and use one
IP address on the DC.


:: 3. What method are you trying to connect to the site?
:: www.domain.com
:: or
:: http://domain.com
:: ?
:
: I configure the multihome addresses to point to different hosts, e.g.,
:
: 192.168.1.150 --> site1.mydomain.com
: 192.168.1.151 --> site2.mydomain.com

This is not necessary, give the DC one IP and configure host headers for the
different sites. Then in DNS create host records for the different sites
pointing to this one IP. Or, this is one time I would recommend using an
alias (CNAME) record, create an alias for each site and point the alias to
the FQDN of the DC.

: Any suggestions on fixing the problem?

Make sure all internal clients use only the DC for DNS, this includes the
DC. Do not use your ISP's DNS anywhere except as a forwarder in the DNS
server, on the forwarders tab.
 
In
Mark Olbert said:
The internal LAN uses only 192.168.1.x addresses. The websites
currently occupy 192.168.1.150 through 192.168.1.155.


Yes, the server is the PDC for the domain, and is running AD. I can
understand the blank record existing for one of the multihomed
addresses, but why all of them?


I configure the multihome addresses to point to different hosts, e.g.,

192.168.1.150 --> site1.mydomain.com
192.168.1.151 --> site2.mydomain.com

The LAN is not accessible from the internet (i.e., it runs behind a
linux firewall/router).

Any suggestions on fixing the problem?

- Mark
Click to expand...

Mark,

It's a tough one because just as I previously stated, and Kevin also stated,
is that EVERY domain controller creates this record for the reasons I
stated.

Also, you didn't respond to my question as to HOW you connect:
If connecting by
Then the LdapIpAddress will affect this.

As Kevin mentioned, you're better off using the www method and using
hostheaders and avoid connecting without the www.

There are registry entries you can use to modify this behavior, but may
affect GPOs in the domain (among other things that connect by the domain.com
name (such as DFS).

--
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
 
DCs will create a blank record for every IP on them, that is one reason
multi homing a DC is not recomended. Not only will you have a blank
<dnsdomainname> for each IP if you look down in gc._msdcs.<dnsdomainname>
there will be another blank record for each IP address.
Instead of mutihoming your DC, give the websites a host header and use one
IP address on the DC.
Click to expand...

I'm loathe to use host headers because I've heard they're not uniformly supported properly by older
browsers, and I test most of my sites against older browsers as well as newer ones.
This is not necessary, give the DC one IP and configure host headers for the
different sites. Then in DNS create host records for the different sites
pointing to this one IP. Or, this is one time I would recommend using an
alias (CNAME) record, create an alias for each site and point the alias to
the FQDN of the DC.
Click to expand...
Make sure all internal clients use only the DC for DNS, this includes the
DC. Do not use your ISP's DNS anywhere except as a forwarder in the DNS
server, on the forwarders tab.
Click to expand...

Okay, that's the way I have things set now.
 
3. What method are you trying to connect to the site?
Also, you didn't respond to my question as to HOW you connect:
Click to expand...

Yes, I did; I don't access by blank host name, I access by site1.domain.com, site2.domain.com, etc.
As Kevin mentioned, you're better off using the www method and using
hostheaders and avoid connecting without the www.
Click to expand...

I've seen the KB article I believe you're referring to about modifying the default behavior for the
DC creating host records. I may try that, as I have to test my projects against older browsers, and
those older browsers don't always honor host headers.

As an aside to Microsoft... thanx, guys, for developing software that drives folks to buy extra
hardware ("don't run certain software on the DC"), and mucks up the DNS. Great, just great.

If you can sense some frustration here, you're right, there is; I get so sick and tired of paying
money for software that is of lower quality and usability than open source stuff.

Anyway, thanx for your help.

- Mark
 
In
Mark Olbert said:
Yes, I did; I don't access by blank host name, I access by
site1.domain.com, site2.domain.com, etc.
Click to expand...


I apologize, I misread it. So then I would suggest to use hostheaders using
those specific names, such as:
site1.domain.com, site2.domain.com, etc
I've seen the KB article I believe you're referring to about
modifying the default behavior for the DC creating host records. I
may try that, as I have to test my projects against older browsers,
and those older browsers don't always honor host headers.
Click to expand...


What older versions? Is this for your internal network?

As an aside to Microsoft... thanx, guys, for developing software that
drives folks to buy extra hardware ("don't run certain software on
the DC"), and mucks up the DNS. Great, just great.
Click to expand...


DCs are the authenticating and security components in a domain. If that
fails, other things go wrong, so it's really suggested to let them be what
they do best. This was also true under NT4, it's just that the X.500
Directory Service uses DNS as it's services locating mechanism (which is an
efficient centralized/distributed means to locate services and the
components that offer those services). If you alter this, other things
occur. Sun has it's own mechanisms for X.500. If you alter them, just as
this, errors may occur.
If you can sense some frustration here, you're right, there is; I get
so sick and tired of paying money for software that is of lower
quality and usability than open source stuff.

Anyway, thanx for your help.

- Mark
Click to expand...

--
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
 
In Mark Olbert <[email protected]> posted a question
Then Kevin replied below:
:: DCs will create a blank record for every IP on them, that is one
:: reason multi homing a DC is not recomended. Not only will you have a
:: blank <dnsdomainname> for each IP if you look down in
:: gc._msdcs.<dnsdomainname> there will be another blank record for
:: each IP address.
:: Instead of mutihoming your DC, give the websites a host header and
:: use one IP address on the DC.
:
: I'm loathe to use host headers because I've heard they're not
: uniformly supported properly by older browsers, and I test most of my
: sites against older browsers as well as newer ones.

I think you would have to go back to the dark ages of computers to find a
browser that does not support host headers. I can't even name one, can you?
I think the pecentage of these browsers are so miniscule, designing a web
site for them would only make sense if you are hosting a web site strictly
for one client. In that case they would get the website that does not have a
host header.
Multihomed DCs are a problem, you can work around the problem by adding
these registry entries using regedt32.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

Registry value: DnsAvoidRegisterRecords
Data type: REG_MULTI_SZ

LdapIpAddress
GcIpAddress

After you add this entry run ipconfig /registerdns and add a blank record
for the internal address DNS is listerning and that file sharing is bound in
the 'domain.com' zone and in the 'gc._msdcs.domain.com' subzone.
 
DCs are the authenticating and security components in a domain. If that
fails, other things go wrong, so it's really suggested to let them be what
they do best. This was also true under NT4, it's just that the X.500
Directory Service uses DNS as it's services locating mechanism (which is an
efficient centralized/distributed means to locate services and the
components that offer those services). If you alter this, other things
occur. Sun has it's own mechanisms for X.500. If you alter them, just as
this, errors may occur.
Click to expand...

And if the folks writing the software that defines a DC knew what they were doing there wouldn't be
those kinds of problems. The kind of shortcoming you're talking about is a design/philosophywouldn't exist. But it's easier, and more profitable, to be slovenly.

- Mark
 
In
Mark Olbert said:
And if the folks writing the software that defines a DC knew what
they were doing there wouldn't be those kinds of problems. The kind
of shortcoming you're talking about is a design/philosophy
wouldn't exist. But it's easier, and more profitable, to be slovenly.

- Mark
Click to expand...

Very harshly stated for what was designed to make directory services
efficient with the use of SRV records. It's not a DC design problem since
after all, Microsoft didn't create the DNS SRV RFC's, it's a standard that
any company can choose to use it for Directory services or anything else,
such as Microsoft did.

--
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
 
MO> I'm loathe to use host headers because I've heard they're
MO> not uniformly supported properly by older browsers, [...]

They still aren't, if one goes by the original specification. But
in practice nowadays it is _web server administrators_ that don't
uniformly and properly support host headers.

Most modern web browser softwares don't conform to section 3.1 of RFC
1738, but instead apply the DNS Client library's name qualification
procedures to the "host" portion of a URL. (This common contravention
of the specification is recognised in RFC 2396.) To specify a fully
qualified domain name in the "host" portion of a URL, therefore, in
order to avoid such things as search path surprises, one has to
explicitly supply the trailing full stop to the domain name in a URL.

Unfortunately, this change to the original specification has the
knock-on effect of requiring that the administrators of content HTTP
servers configure virtual hosting such that the _fully qualified_
domain name is recognised by the server, since there is now (where
there wasn't before) a distinction between URLs that have fully
qualified domain names as their "host" portions and those that do not.

In other words, each web site has to have _at least two_ configured
"host header" strings. Alas! Many web site administrators fail to
do this as they should, and their web sites are as a consequence not
accessible when one uses fully qualified domain names in URLs.

<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/web-allowing-omission-of-www.html#HTTP>
 
KDGS> I think you would have to go back to the dark ages of computers
KDGS> to find a browser that does not support host headers.

Actually, one merely has to go back a handful of years.

KDGS> I can't even name one, can you?

Mark might not be able to (even though he does say that he tests using older
web browsing softwares), but I certainly can.
 
In Jonathan de Boyne Pollard <[email protected]> posted a question
Then Kevin replied below:
: KDGS> I think you would have to go back to the dark ages of computers
: KDGS> to find a browser that does not support host headers.
:
: Actually, one merely has to go back a handful of years.

A handful of years for you is most of the life time to a dog, I was speaking
in comparison, the dark ages for computers pretty much pre dates Windows 95.
Windows 95 did to computers what the Model T did to automobiles. Before that
very few people had a computer, they were too expensive, and many of us who
have a computer now, had no plans of getting one. The people I knew that had
computers before that were either businesses or the obnoxious elitists like
you that come here and parse words and sentences.
If I stated an untruth then say that, if all you want to do is parse words,
then get a life. 3
I don't need you to parse my words, I got enough of that forty years ago
when I was in elementary school.

:
: KDGS> I can't even name one, can you?
:
: Mark might not be able to (even though he does say that he tests
: using older web browsing softwares), but I certainly can.
Do you? Very good, I'm happy for you. Do you have point to make here?
 
Very harshly stated for what was designed to make directory services
efficient with the use of SRV records. It's not a DC design problem since
after all, Microsoft didn't create the DNS SRV RFC's, it's a standard that
any company can choose to use it for Directory services or anything else,
such as Microsoft did.
Click to expand...

It's not harshly stated at all, IMHO. If I wanted to be a beta tester, I'd sign up to be one. I
choose to be "just" a customer. When I pay someone significant $$$ for a product, I expect it to
work well, particularly with their own stuff.

Unfortunately, MS' philosophy has been, for years, ship stuff first, make it work second (there's a
very sad Newsweek editorial from some years ago that quotes Ballmer as saying precisely that... and,
what's worse, he was proud of the philosophy).

I'm willing to concede/stipulate that the programmers at Microsoft aren't the ones responsible;
their management is.

But from my point of view that's irrelevant. Again, I'm just a customer, I just want a product that
works.

- Mark
 
In Mark Olbert <[email protected]> posted a question
Then Kevin replied below:
: Hi all,
:
: I'm having a problem with a Win2K server (SP4) that I use to host
: multiple ASP.NET development projects. I use multihoming to give each
: project website a separate IP address.
:
: What happens is this: when I first turn on my client (XP SP1)
: machine in the morning (which is connected by a LAN to the server) I
: cannot surf to any of the internal websites (in IE I get page not
: found / can't be displayed errors, while Visual Studio just refuses
: to load the project because it can't contact the site).
:
: If I then open a command window and do an nslookup on the internal
: site it works fine. However, tracert and ping both fail.
:
: Opening IE and surfing to the numeric IP address of the site
: instantly brings it up (which is what makes me think this is a DNS
: problem).
:
: Previously I've worked around this problem by going down to the
: server, resetting the DNS, and waiting about 10 or 15 minutes. At
: that point my client machine can again resolve the human-readable
: site names and all works as expected.
:
: But if I stop working on the sites for a couple of hours the problem
: re-occurs.
:
: This morning when I ran into the problem I tried running an ipconfig
: /registerdns on the client XP machine. The sites were instantly
: resolvable after doing that.
:
: The only odd thing I've noticed about the DNS records on the server
: is that there are multiple "blank" A records (which say something
: like (same as parent folder) for the name). It looks like these
: records are being created, one for each of the multihomed websites.
:
: Can someone explain what the heck is going on? And, more importantly,
: how I can make the problem go away?
:
: - Mark

What DNS servers are listed in the XP ipconfig?
 
What DNS servers are listed in the XP ipconfig?

Here's an ipconfig /all dump:

C:\Documents and Settings\Mark.MAKEITSO>ipconfig /all

Windows IP Configuration

Host Name . . . . . . . . . . . . : makeitso
Primary Dns Suffix . . . . . . . : arcabama.com
Node Type . . . . . . . . . . . . : Unknown
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : arcabama.com

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Intel(R) PRO/100 VE Network Connection
Physical Address. . . . . . . . . : 00-07-E9-BF-50-43
Dhcp Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 192.168.1.2
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.20
DNS Servers . . . . . . . . . . . : 192.168.1.200
192.168.1.20

192.168.1.200 is the Win2K server. 192.168.1.20 is the firewall/router (which also runs DNS, but
only resolves the external DSL IP address for my domain; everything else it forwards).

- Mark
 
In Mark Olbert <[email protected]> posted a question
Then Kevin replied below:
:: What DNS servers are listed in the XP ipconfig?
:
: Here's an ipconfig /all dump:
:
: C:\Documents and Settings\Mark.MAKEITSO>ipconfig /all
:
: Windows IP Configuration
:
: Host Name . . . . . . . . . . . . : makeitso
: Primary Dns Suffix . . . . . . . : arcabama.com
: Node Type . . . . . . . . . . . . : Unknown
: IP Routing Enabled. . . . . . . . : No
: WINS Proxy Enabled. . . . . . . . : No
: DNS Suffix Search List. . . . . . : arcabama.com
:
: Ethernet adapter Local Area Connection:
:
: Connection-specific DNS Suffix . :
: Description . . . . . . . . . . . : Intel(R) PRO/100 VE
: Network Connection Physical Address. . . . . . . . . :
: 00-07-E9-BF-50-43 Dhcp Enabled. . . . . . . . . . . : No
: IP Address. . . . . . . . . . . . : 192.168.1.2
: Subnet Mask . . . . . . . . . . . : 255.255.255.0
: Default Gateway . . . . . . . . . : 192.168.1.20
: DNS Servers . . . . . . . . . . . : 192.168.1.200
: 192.168.1.20
:
: 192.168.1.200 is the Win2K server. 192.168.1.20 is the
: firewall/router (which also runs DNS, but only resolves the external
: DSL IP address for my domain; everything else it forwards).
:
: - Mark
You see what the problem is that you have defined your router for DNS on
your internal client. You should only point to the Win2k DC for DNS and
remove the router from the NIC on all domain members. The DNS server on your
Win2k should forward to the router.
The reason it starts working when you run ipconfig /registerdns is that this
command resets the DNS order and puts the internal server back at the top.
Your internal DNS has the records you need but the Router does not.
Then to get the Win2k to resolve names in arcabama.com that only exist in
the External DNS server you must add the records to the internal DNS server
on the Win2k. It must be done this way to resolve your issues.
If you have issues with using the setup I noted, please post back, I'll be
glad to help you resolve them. But you must use the Win2k DNS for all
internal clients and domain members.

You also have issues with your public DNS you are missing NS records your
master nameserver is not answering with authority (it's lame) take a look at
this http://www.dnsreport.com/tools/dnsreport.ch?domain=arcabama.com
 
In
Mark Olbert said:
It's not harshly stated at all, IMHO. If I wanted to be a beta
tester, I'd sign up to be one. I choose to be "just" a customer. When
I pay someone significant $$$ for a product, I expect it to work
well, particularly with their own stuff.

Unfortunately, MS' philosophy has been, for years, ship stuff first,
make it work second (there's a very sad Newsweek editorial from some
years ago that quotes Ballmer as saying precisely that... and, what's
worse, he was proud of the philosophy).

I'm willing to concede/stipulate that the programmers at Microsoft
aren't the ones responsible; their management is.

But from my point of view that's irrelevant. Again, I'm just a
customer, I just want a product that works.

- Mark
Click to expand...

I am not here to argue/agree with anything. I am here to help you with any
problems you post. This is a forum to help the public with their problems,
where this forum is specifically for DNS problems.

SRV records are an industry standard that were NOT created by Microsoft, but
used by their services and applications. You will see them used more and
more in the future by other companies. Microsoft was pretty much one of the
first, if not the first to use them.

Apparently your internal websites not being to be resolved periodically is
due to your DNS config on your machines, based on your posted ipconfig /all.
The DNS resolver service works in such a manner that it will use the first
in the list, if it doesn't provide an answer, it will go to the second one,
but it will remove the first one from the eligible resolver list and won't
go back to it unless the system is restarted, or the DNS client service is
restarted on the client machine. Hence your whole issue.

Cardinal rule: USE ONLY YOUR INTERNAL DNS SERVER THAT HOSTS YOUR AD ZONE.
Using any others, such as your ISP's or your firewall/router, *WILL* cause
undesirable and unpredicatable results and *MAY/WILL* cause AD to not
function properly.

If one were to have researched this prior to their deployment, this problem
may not have occured and hence the harsh statements.


--
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
 
Back
Top