1

On a Windows domain I recently had to do a "force removal" of a domain controller.
I was careful to remove all the metadata and did a metadata cleanup.

I also removed all references to the domain controller/dns server I removed on the remaining dns server.

I also moved the fsmo roles and global catalog server role to the new domain controller prior to the force removal.

Now dns is extremely slow to resolve internet websites. If I add the google dns server, to the speed is normal.

Is there a way to further troubleshoot the problem?

Have I missed something in removing the old domain controller?

Mark
  • 131
  • 2
  • 14
  • 2
    Does the remaining DNS servers still try to use that server as a forwarder? They would wait for timeout before trying next server or falling back to root hints. I'd check the forwarder configuration first. – Esa Jokinen Sep 12 '18 at 16:55
  • `Now dns is extremely slow to resolve internet websites` - From client machines, from the remaining DC, or both? `If I add the google dns server, to the speed is normal` - Add it where? Was the old DC the primary DNS server for clients? If so, have you changed that? – joeqwerty Sep 12 '18 at 17:40
  • Esa is correct. The forwarder was still pointing to the old dc but when I go to change it to the current dc/dns server (192.168.1.31 or 127.0.0.1) I get an error message that says "The server forwarders cannot be updated. The ip address is invalid" – Mark Sep 12 '18 at 19:02
  • I removed the old server and left the forwarder blank and checked the box that said "Use root hints if no forwarders are available". I do not know if there are any inherent problem with this configuration, but it seems to be working. The speed to websites has been restored without using the google dns server. If anyone knows of a problem with the mentioned configuration let me know, otherwise I would say our job is done. – Mark Sep 12 '18 at 19:29

1 Answers1

2

You also had the removed domain controller as a DNS forwarder for the other name servers. The slowing down was caused by waiting for those queries to timeout before falling back to root hints. (Microsoft's article on Reviewing DNS Concepts explains this in detail.)

This configuration wasn't following the best practices even before removing the server, as it made your whole network dependent on a single DC, that is opposite of the purpose of having multiple domain controllers for redundancy. It worked, but it would have caused this slowing down whenever that DC was down.

DNS with AD DS utilizes Directory-integrated DNS zones for synchronizing the authoritative zones between domain controllers, making them all have the local DNS records already.

  • If you use forwarders, you could use your ISP's DNS servers for the rest of the Internet. Using ISP's DNS servers as forwarders is favorable for getting better answers for services that use different server for different geolocations, if you first make sure those forwarders are actually near you (whereas general open DNS forwarders seldom are).

  • It's also possible to use the root hints instead of forwarders. That makes initial queries for new TLDs a little slower as they don't use a shared huge cache, but are usually cached for a longer time the closer to the root you are. The bigger network you have the better option this is.

Worth reading: DNS hell: The seven deadly sins helps in evaluating what's the best option for you.

Esa Jokinen
  • 46,944
  • 3
  • 83
  • 129
  • I do not understand your conclusion, "therefore use your ISP's DNDS servers as forwarders (...) when possible". That's not a logical conclusion from the "Directory-integrated DNS zones". Also, you link to a document worth reading which states that your conclusion is one of their seven deadly sins. – Tommiie Sep 13 '18 at 08:16
  • Thank's, Tom, for pointing that out! Do you find this better now? – Esa Jokinen Sep 13 '18 at 08:32
  • I think my pitfall was the lack of global perspective: in Finland, ISPs have quality name servers, our ISP even fully supporting DNSSEC. In many countries, however, you really must evaluate their reliability case by case. – Esa Jokinen Sep 13 '18 at 08:57
  • 1
    Now that you mention DNSSEC... This answer to my question has a comment about when using DNSSEC, you better resolve yourself instead of forwarding to your ISP: https://serverfault.com/a/927015/451507 – Tommiie Sep 13 '18 at 09:03
  • We will be adding back another domain controller soon. Thank you for all the information. It filled in a few of the holes in my networking knowledge. – Mark Sep 13 '18 at 20:34