A Win2K DNS/DC System Points to Itself
I just told you to configure intranet DNS servers to refer to themselves, but you might find yourself with a special case—running a Win2K-based AD implementation and configuring your forest's root domain as Active Directory-integrated. For a DNS server to host an Active Directory-integrated zone for a forest root, that DNS server must be both a DNS server and a DC for the forest root domain. Now, if you configure all your DNS/DC systems to use themselves as preferred DNS servers, you'll get a problem called "island DNS," in which each of those DNS servers loses the knowledge of any other DNS server but itself. For more information about this error, see the Learning Path box, page 46.
To fix this problem, you can either upgrade your DCs to Windows 2003, which doesn't have this problem, or elect not to use Active Directory-integrated zones on the root domain. (Remember, only the root domain can experience the problem.)
You can also work around the problem as follows: Choose a DNS server to be the "master" DNS server. Then, configure a preferred DNS server for this server, and point it to itself. Finally, have the other servers all point to this DNS server as their preferred DNS server. You can configure alternate DNS servers for any DNS server except the "master," but never point any of the DNS/DC servers to themselves.
The moral of this story: If you're using Active Directory-integrated zones on Win2K-based DCs in a forest root domain, don't point DNS servers to themselves. (This problem doesn't affect Windows 2003-based systems.)
An Old HOSTS File Keeps You from Finding a Server
Recently, a reader asked for my help with a mysterious DNS problem. One computer—only one!—in his intranet couldn't connect to a particular DC. The computer had no troubles with other DCs in the network, and no other systems had trouble connecting to this DC. What was the trouble?
I ran through a list of possible problems and solutions, but none helped. Unhappily, I admitted that I was out of ideas. He emailed me back a few weeks later with the answer: a HOSTS file!
In \winnt\system32\drivers\etc (on Win2K systems) or \windows\system32\drivers (on Windows XP and Windows 2003 systems), you'll find a text file named HOSTS (no file extension). Before DNS, HOSTS files answered such questions as "What's the IP address of a machine with this name?" HOSTS is just a simple list of IP address/computer name combinations and explanatory comments starting with a number sign (#). HOSTS is largely unused now save for the occasional troubleshooting need, but every TCP/IP stack I've ever seen still supports HOSTS. Your HOSTS file probably contains only one non-comment line—"127.0.0.1 localhost"—which will cause your system to recognize the name "localhost" as itself. (The IP address 127.0.0.1 is the special IP "loopback" address, so pinging "localhost" causes your system to ping itself.)
However, suppose you had a local DC called dc4.bigfirm.biz at 192.168.4.2. If you queried a DNS server for the IP address of dc4.bigfirm.biz, you'd get an answer of 192.168.4.2. But now suppose that someone has put a record such as 10.0.0.5 dc4.bigfirm.biz in your client PC's HOSTS file. Whenever your system tries to resolve the name dc4.bigfirm.biz, your client PC might get two answers: 192.168.4.2 from DNS and 10.0.0.5 from HOSTS. Who wins? HOSTS. In fact, your system first asks HOSTS, and if HOSTS has an answer, your system doesn't even bother checking with DNS. For some reason, the aforementioned reader's PC had a HOSTS file entry that referred to the DC in question, but the HOSTS file had the wrong IP address for that DC.
The moral of this story: When just one system has trouble finding a particular server and no other system has that trouble, look at the troubled system's HOSTS file.
Dcpromo Did the Work
Here's a typical email note: A reader has created an AD implementation with one DC, and that DC works fine, but the reader can't get AD to join any workstations to the domain, nor can the reader get Dcpromo to run on another server to add a second DC. The problem? Dcpromo strikes again.
Dcpromo checks whether you have a sufficient DNS infrastructure—that is, a zone whose name matches your AD implementation's name and that accepts dynamic DNS registration—before it sets up AD. That's a good move, and I'm glad Microsoft designed Dcpromo to perform that check. Unfortunately, the company went further and designed Dcpromo to offer to set up DNS for you. Never let Dcpromo set up DNS. Dcpromo doesn't point the first DC to itself, nor does it instruct you to point all your internal systems to intranet DNS servers, nor does it address any of the other items covered in this article.
The moral of this story: If Dcpromo complains that DNS isn't correctly set up, your best bet is to stop Dcpromo and recheck your DNS infrastructure. You don't want to create an AD implementation atop a wobbly DNS foundation.
Avoid AD Horror
DNS provides a simple function in your network: It connects machines' names and their IP addresses. AD adds to DNS's task the job of keeping lists of DCs and GC servers. But the simplicity of those tasks belies their importance. Without DNS, AD simply won't function. Keep an eye out for these common DNS configuration problems, and your DNS implementation will be trouble-free.
End of Article
)
)
)
Register
Thank you
jmalantonio September 02, 2004 (Article Rating: