What are DNS Configuration Errors?

Download Top 3 Registry Cleaners

RegCure of ParetoLogic (TechJocks Pick!)
Registry Mechanic of PCTools
Registry Booster of Uniblue

Stop your DNS Server Civil War now

Configuration errors breed discontent. But configuration errors on your DNS servers won’t just stop there. They will continue from there and wreak havoc upon and within your organization’s Intranet, especially in a large and growing organization. More often than not, problems with Active Directory updates and replication are the cause behind those wonderful “no domain controller” errors we all so love so much and, more often than not, they can be directly attributed to cross-zone DNS errors.

Unfortunately, DNS in this Windows World of ours can be quite a complicated matter. And anything but a laughing matter, too, I might add. The complex Active Directory interaction between Global Catalog servers, Exchange servers and Domain Controllers, especially when it comes to traffic meant to cross between DNS zones, will only work properly if “everybody is on the same sheet of music.” And DNS can only furnish this music to everybody if it has been tuned properly.

Active Directory has to find its DNS servers in order to locate any of those other machines out there. And most of the problems that AD has to wrestle with usually stem from problems it is having with DNS or, to be more exact, with DNS problems which are caused by what are generally very simple-to-make and easy-to-correct configuration errors; “zoning” errors.

As I said, for Active Directory to do its job inside your organization, it needs a properly-functioning DNS infrastructure. The problem is, not every internal DNS server necessarily contains the DNS records pointing to your Domain Controllers and the other member servers. You see, most of the time DNS implementations are designed to be “seen” in the public Internet. So when it gets implemented within an organization, this “split personality” effect usually brings along with it settings which, though intended to protect your internal systems, can also prevent them from finding one another.

It gets down to this: Every DNS server within an Intranet needs to have a local copy of the DNS zone file. And this zone file will also contain the needed information for all of the other domains and zone files within your forest. In other words: If you want everything to run smoothly, all DNS servers within your intranet must be either primary or secondary DNS servers for every domain within your forest.

If when creating your company’s DNS space you decide to add an additional domain or two just to insure that your company will have room to grow in the future, you must also remember that for AD, each of these “empty” domains needs a DNS zone. You must therefore set up these domain’s servers (first servers) as primary DNS servers for their corresponding dynamic zones and have these systems use themselves as the preferred DNS servers. Repeat this process for all secondary DNS servers in each of these domains. Now that two DNS servers (and DCs) are in place, everything is in place within the forest root domain. The stage is set, so-to-speak.

Once all of this is done, the last and most critical step is still left: Always remember to put these newly-created zones on every DNS server within your Intranet. Otherwise these domain’s all-important GC servers will appear only within the DNS zone for each particular root domain and remain unreachable for everybody else.