DNS Server Help

Hello,

We have a setup where 3 of our servers are also DC's. The PDC is a Windows
2000 box, the other two DC's are Server 2003 boxes. All servers run DNS, and
it's replicated to the DC's from the PDC. The PDC also runs DHCP and doles
out IP addresses to the workstations on the network. This includes letting
the stations know where to look for DNS information. (PDC first, the DC's
second and third)

All runs fine unless the PDC is down. In this case most (but not all) of
the workstations cannot browse the internet, nor can they connect to the
exchange server from outlook. Everything else runs fine.

It appears part of the DNS duties are not being taken over by the other DNS
servers? Can anyone tell me what I should be lookin at in the DNS server
software?

Thank You,

D

"NewtoExpressionWeb" <> wrote in
message news:2AED60A4-6E65-4030-B18A-...

> It appears part of the DNS duties are not being taken over by the other
> DNS
> servers? Can anyone tell me what I should be lookin at in the DNS server
> software?

There is no "failover" with DCs. That is a misconception. The purpose of
multiple DCs it so that you have multiple copies of the DNS Zone and
multiple copies of the Active Directory Database,...it is not so that having
one DC fail will be "transparent". A secondary reason for multiple DCs is
so that you can place one at each Site in a multi-Site network so that uses
will use the one closest to them to conserve WAN bandwidth,...this function
works off of the AD Sites and Subnets Objects.

Redundancy and failover are not the same thing.

Reasons why there is no "failover:

1. FSMO roles are not duplicated across DCs,...an Role can only exist on one
chosen DC at a time. If that DC goes down the FSMO role is lost until the
down DC is repaired or the Role is manually seized by another DC.

2. Client's TCP/IP Specs to not move to the next DC as you would expect.


--
Phillip Windell

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------

So even though the stations have a second DNS server listed, it won't use
that DNS server to query? Or are you saying the other DNS servers cannot
answer them?

"Phillip Windell" wrote:

> "NewtoExpressionWeb" <> wrote in
> message news:2AED60A4-6E65-4030-B18A-...
>
> > It appears part of the DNS duties are not being taken over by the other
> > DNS
> > servers? Can anyone tell me what I should be lookin at in the DNS server
> > software?
>
> There is no "failover" with DCs. That is a misconception. The purpose of
> multiple DCs it so that you have multiple copies of the DNS Zone and
> multiple copies of the Active Directory Database,...it is not so that having
> one DC fail will be "transparent". A secondary reason for multiple DCs is
> so that you can place one at each Site in a multi-Site network so that uses
> will use the one closest to them to conserve WAN bandwidth,...this function
> works off of the AD Sites and Subnets Objects.
>
> Redundancy and failover are not the same thing.
>
> Reasons why there is no "failover:
>
> 1. FSMO roles are not duplicated across DCs,...an Role can only exist on one
> chosen DC at a time. If that DC goes down the FSMO role is lost until the
> down DC is repaired or the Role is manually seized by another DC.
>
> 2. Client's TCP/IP Specs to not move to the next DC as you would expect.
>
>
> --
> Phillip Windell
>
> The views expressed, are my own and not those of my employer, or Microsoft,
> or anyone else associated with me, including my cats.
> -----------------------------------------------------
>
>
>

"NewtoExpressionWeb" <> wrote in
message news:AE36572A-AE8B-41CE-99F7-...
> So even though the stations have a second DNS server listed, it won't use
> that DNS server to query? Or are you saying the other DNS servers cannot
> answer them?

It will use them, only after a timeout period the client is waiting for a
response from the server. If it responds with an NXDOMAIN response, meaning
there is no record from the server it asked, then it will look no further,
but if it receives a NULL response, m eaning the DNS server is down, it will
remove the first entry from the 'eligible resolvers list' for a certain
amount of time (depending on the OS version and SP level), then send the
query to the second one. This is based on the client side resolver, not the
DNS server. This time out period can be perceived as by someone sitting
there waiting as 'it's not working' because it appears to be taking so long.
Also, if it is already cached locally by the client side service, it will
not ask and will send the connection request to the cached record, which if
it is the server that is down, then it can't connect anyway, and no
response, but you may be sitting there expecting it to go to the other DC
that is up. The way to reset the list is to restart the DHCP Client service
on the workstation, and the way to delete the cache on the client is to run
ipconfig /flushdns.

Make sense?

--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSA Messaging, MCT
Microsoft Certified Trainer


For urgent issues, you may want to contact Microsoft PSS directly. Please
check http://support.microsoft.com for regional support phone numbers.

"Efficiency is doing things right; effectiveness is doing the right
things." - Peter F. Drucker
http://twitter.com/acefekay

"NewtoExpressionWeb" <> wrote in
message news:AE36572A-AE8B-41CE-99F7-...
> So even though the stations have a second DNS server listed, it won't use
> that DNS server to query? Or are you saying the other DNS servers cannot
> answer them?

It depends on "how" the DC is down. If it is completely powered down, or
the network cable is uinplugged, or the DNS Service is shutdown,...then
after an annoying timout period the Client will drop to the next DNS on the
list. However that DC/DNS may not have the FSMO Roles that might be needed
at that moment,...so there could be failures or delays.

Beasically it come down to these two options:

1. Get the DC fixed as quick as possible

OR

2. Seize the FSMO Roles with the remianing DC as quickly as possible and add
the IP# of the dead DC to the remaining DC as a "secondary IP" so that the
Client will find it using the same IP# they were previously using. When
the dead DC is fixed then you can drop that IP# off and give it back to the
original DC and move the FSMO Roles back to where they were.

There are a few MS articles describing the behavor, but I can find any of
the links. Maybe one of the other guys knows of some.

--
Phillip Windell

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------

Both replies make sense. The DC was off for about 20 minutes. The affected
workstations did not end up ever using the other DNS servers. I'll look for
a way to configure that timeout in the DHCP settings to push to the clients.
I had just assumed the DNS on the other two servers had a problem. LoL

"Phillip Windell" wrote:

> "NewtoExpressionWeb" <> wrote in
> message news:AE36572A-AE8B-41CE-99F7-...
> > So even though the stations have a second DNS server listed, it won't use
> > that DNS server to query? Or are you saying the other DNS servers cannot
> > answer them?
>
> It depends on "how" the DC is down. If it is completely powered down, or
> the network cable is uinplugged, or the DNS Service is shutdown,...then
> after an annoying timout period the Client will drop to the next DNS on the
> list. However that DC/DNS may not have the FSMO Roles that might be needed
> at that moment,...so there could be failures or delays.
>
> Beasically it come down to these two options:
>
> 1. Get the DC fixed as quick as possible
>
> OR
>
> 2. Seize the FSMO Roles with the remianing DC as quickly as possible and add
> the IP# of the dead DC to the remaining DC as a "secondary IP" so that the
> Client will find it using the same IP# they were previously using. When
> the dead DC is fixed then you can drop that IP# off and give it back to the
> original DC and move the FSMO Roles back to where they were.
>
> There are a few MS articles describing the behavor, but I can find any of
> the links. Maybe one of the other guys knows of some.
>
> --
> Phillip Windell
>
> The views expressed, are my own and not those of my employer, or Microsoft,
> or anyone else associated with me, including my cats.
> -----------------------------------------------------
>
>
>

"NewtoExpressionWeb" <> wrote in
message news:6B40D48E-B987-409C-80C7-...
> Both replies make sense. The DC was off for about 20 minutes. The
> affected
> workstations did not end up ever using the other DNS servers. I'll look
> for
> a way to configure that timeout in the DHCP settings to push to the
> clients.
> I had just assumed the DNS on the other two servers had a problem. LoL

The timeout resolver setting is actually a reg setting that has to be
changed on all client and not through DHCP, and is additional administrative
overhead, but I don't think the benefit will be there compared to how often
a DC is planned or even unplanned, to go down.

Good luck!

Ace

"NewtoExpressionWeb" <> wrote in
message news:6B40D48E-B987-409C-80C7-...
> Both replies make sense. The DC was off for about 20 minutes. The
> affected
> workstations did not end up ever using the other DNS servers. I'll look
> for
> a way to configure that timeout in the DHCP settings to push to the
> clients.
> I had just assumed the DNS on the other two servers had a problem. LoL

Don't.....Mess....With...The...Timeouts!!!

They are there for a reason,...and they are what they are for a reason.

This is not simply about timeouts,...it is about functionality and
design,...I thought I made that clear.

I already gave you the two *proper* options to deal with this.

--
Phillip Windell

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------