Jump to content

Recommended Posts

Posted

Hi folks,

 

We have an issue with DNS forwarders.

 

There are two DCs in our domain at the top level, both of which do DNS (and one does DHCP). It's a Hyper-V cluster so DC2 sits outside the cluster and DC1 sits within it. DC2 also has the FSMO role. As it's a Hyper-V cluster the primary DNS server (also a DC) has to be outside the cluster.

 

We sit behind an LA provided connection with lots of port blocks, so have to use the LA's forwarders. This isn't an issue per se as they seem to work fine. The problem is that DC2 is extremely slow at responding to DNS requests, whereas DC1 is fine. The only difference I can spot between the two is that when the respective DCs try to validate the forwarders DC1 gives an "OK" immediately whereas DC2 often can't validate them at all.

 

DNS has been removed from DC2, and it has been removed as a DC, then promoted back, with DNS reinstalled. This hasn't helped.

 

Anyone have any ideas as to what could be causing this?

 

TIA

Posted

Have you tried a nslookup against DC2.

 

If it times out then it may not have the proper forwarded configured, it may also be under heavy load (limiting it's ability to respond to requests).

  • Thanks 1
Posted

TheMinister: Yes, NSLOOKUP has timeout issues. I've used DIG which is a bit informative in that it gives the length of time taken to resolve an issue. On DC1 this is millseconds. On DC2 this can be several seconds.

 

Both DC1 and DC2 are configured with the same forwarders.

 

glennda: Both are using the same default gateway. Should the TRACERT be done to the forwarders?

Posted

I've checked the forwarders anyway with TRACERT. On DC1 they are found within 6 hops. On DC2 it takes 30 hops, and the request times out on every hop.

 

The $64 million dollar question is: why?

Posted

Yes, and they say the forwarders are used by hundreds of schools and the LA itself, hence if there were a problem with the forwarders it would be well known about.

 

The problem must be internal to us, but why is one DC behaving so differently to the other? That's the mystery.

 

The consultant involved with this for testing is thinking of creating a third DC which they will push between the two hosts to see if it behaves differently (as these are all VMs).

Posted

I'm guessing that the two servers are connected to different switches, even if they are joined together via fibre for example?

 

If they are linked via fibre, I would check the modules as well as the switch and cabling. From what you describe it doesn't specifically sound like an LA or server issue, but certainly a network or switch related issue.

  • Thanks 1
  • 2 weeks later...
Posted
I'm guessing that the two servers are connected to different switches, even if they are joined together via fibre for example?

 

If they are linked via fibre, I would check the modules as well as the switch and cabling. From what you describe it doesn't specifically sound like an LA or server issue, but certainly a network or switch related issue.

They are on a different area of the network, but this is part of the backup system which seems to be working fine, at least as far as the LAN is concerned. Unfortunately I didn't install the switches and I don't support them, so it's a tricky area to investigate.

On each DC check the network connections' TCP/IP settings. What have you got set up for DNS on each? This might help: Best practices for DNS client settings in Windows 2000 Server and in Windows Server 2003

DNS has essentially been mirrored on the two DCs, so they should be identical.

Can you post the tracert of DC1 and DC2 ?

I can, but there's not an awful lot to see. Basically the TRACERT for DC2 just doesn't show any connection for any of the hops. DC1 shows a valid TRACERT over the previously mentioned number of hops.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...