New DNS install appears to hang machine

[Roeee]

All,

I have just installed a new DNS server and Active Directory domain. The DC / DNS server is currently one of two machines on the network.

DNS was installed and configured initally, by creating a new zone which has the same FQDN as the AD domain which I was yet to create. I have configured both forward and reverse lookups to accept dynamic updates. Prior to the install I configured the DNS settings locally on the NIC.

Once DNS was installed I configured the 2nd server with the correct IP and DNS settings. I tried a DSLOOKUP but received the error that the "default server was unavailable". I can ping the server but not resolve DNS.

Even with the DNs problem I continued to install AD by accepting defaults. The installation picked up the correct FQDN from DNS. Once installed I changed DNS to be AD integrated. I also noticed that the 4 SRV's were now created within the DNS zone.

However, now I experience 3 problems...

1) - The DC / DNS server appears to hang at boot up on the "preparing network settings" dialog box.

2) - I am unable to perform DNS lookups

3) - I can not add the 2nd server to the domain as it is "unavailable".

I know this is a DNS issue but am unsure what to change or where I have gone wrong?

............Can any one help?

Thanks,
Mike

 

[ITPangaeaArchitect]

you are right...DNS

follow the following outline for MS DNS config and you should be good to go:

DNS configuration (if you are running Windows 2000 and do not use this configuration, you may experience issues anywhere from replication to authentication of users, 2003 can also experience same issues):

**Note: I have included a custom method I use that I refer to as standardization. The standardization technique has the potential to decrease the frequency of “business down” issues that are caused by name resolution by approximately 80-90% (assuming long term downage here…examples are file replication, and user logons). The standardization method does take more time to initially set up/configure, but the downtime saved is easily worth the extra effort. To use the standardization method, you must take inventory of all DCs in your domain. Meaning, you will need the IP address, as well as the AD site they belong to. It is easiest to write this information down into a word or text document and then rearrange them in site order (this way you can go site by site instead of searching a list for site members). I would also make a mark by the PDCe so as to not confuse anything (example below). In the recommendations below, the standardization method will always be the method to follow the “-OR-“ (which follows the simple, acceptable method).
EX (servername – IP – sitename; PDC will be servername-PDC-IP-sitename)---
DOM1DC1 – PDC – 10.0.1.2 – Dallas
DOM1DC2 – 10.0.1.3 – Dallas
DOM1DC3 – 10.0.1.4 – Houston
DOM1DC4 – 10.0.1.5 – Houston

**this should make it substantially easier to go through the process without losing your place. It also has the additional benefit of creating DC documentation for later reference.

Standardization method PROS/CONS---
PROS:
-Has potential to decrease major issues caused by name resolution almost in their entirety (I have not seen any name resolution related problems whatsoever any of the times myself, or a customer I recommended the method to, performed this method). This method allows us to maintain DNS name resolution site by site because, for example, if a failure on the PDCe occurs, all members in the PDCe site, since they point to the same alternates in the same order, will fail back to the same DNS server, and begin registering there instead…if that replica DC fails, the same still goes…each time we have a failure all members of the site will fail to the same DNS server, thereby maintaining DNS name resolution almost indefinitely. I do not guarantee no failures at all, but it would substantially decrease the chances of them occurring at all.
CONS:
-Takes longer to configure
-If roles are transferred (specifically the PDC role), complete reconfiguration is required enterprise wide to reflect the new PDCe (this is a step that should be taken whether using standardization or simple method)


*****

Default advanced TCP/IP properties (settings should match these)---
DNS server address is listed
Append primary and connection specific DNS suffixes is marked (radio button)
Append the parent suffix of the primary DNS suffix is checked (checkbox)
Register this connections addresses in DNS is checked (checkbox)
Everything else should be blank
Ensure NetBIOS over TCP/IP is enabled and not set to default (mainly for Win2003)

Domain controllers---
PDCe faces itself and itself only for DNS, with defaults in advanced tcp/ip properties
Replica DCs in the enterprise (all sites) point to the PDCe for preferred DNS, and themselves as alternate, with defaults in advanced tcp/ip properties
-OR-
All replica DCs in site with the PDCe point to the PDCe for preferred, and all the same replica DCs in the same order beginning with the replica DCs in the site with the PDCe, and then out of site replicas (you choose alternate DNS order based on preference and site membership, there is no certain way you need to do this, although I would stick to site by site method…I normally base off of machine performance…such as a 3ghz processor w/ 4GB RAM would be listed before a 2ghz w/ 4GB RAM). Replica DCs in different sites than the PDCe should use the same methods, using the PDCe as preferred, and then the same order for alternates, beginning with replica DCs in the same site as first alternates, then moving to replica DCs in other sites.
EX (using server names and info from example above and adding on complexity):
DOM1DC1 – PDC – 10.0.1.2 – Dallas
DOM1DC2 – 10.0.1.3 – Dallas
DOM1DC5 – 10.0.1.6 - Dallas
DOM1DC3 – 10.0.1.4 – Houston
DOM1DC4 – 10.0.1.5 – Houston
DOM1DC6 – 10.0.1.7 - Houston


P: = preferred DNS A: = alternate DNS
DOM1DC1 – Dallas site - P: 10.0.1.2 & A: None
DOM1DC2 – Dallas site - P: 10.0.1.2 & A: 10.0.1.3, 10.0.1.6, 10.0.1.4, 10.0.1.5, 10.0.1.7
DOM1DC5 – Dallas site - P: 10.0.1.2 & A: 10.0.1.3, 10.0.1.6, 10.0.1.4, 10.0.1.5, 10.0.1.7
DOM1DC3 – Houston site – P: 10.0.1.2 & A: 10.0.1.4, 10.0.1.5, 10.0.1.7, 10.0.1.3, 10.0.1.6
DOM1DC4 – Houston site - P: 10.0.1.2 & A: 10.0.1.4, 10.0.1.5, 10.0.1.7, 10.0.1.3, 10.0.1.6
DOM1DC6 – Houston site - P: 10.0.1.2 & A: 10.0.1.4, 10.0.1.5, 10.0.1.7, 10.0.1.3, 10.0.1.6


Domain members (servers and workstations) in site with PDCe:
Face PDCe as preferred DNS, and replica DCs as alternates in the same order specified on replica DCs in that site
EX:
DOM1DC1 – PDC – 10.0.1.2 – Dallas
DOM1DC2 – 10.0.1.3 – Dallas
DOM1DC5 – 10.0.1.6 - Dallas
DOM1DC3 – 10.0.1.4 – Houston
DOM1DC4 – 10.0.1.5 – Houston
DOM1DC6 – 10.0.1.7 - Houston

WORKSTATION1 – Dallas (PDCe) site - P: 10.0.1.2 & A: 10.0.1.3, 10.0.1.6, 10.0.1.4, 10.0.1.5, 10.0.1.7


Domain members (servers and workstations) outside of PDCe site:
Choose a replica DC in that site to act like the PDCe’s DNS role for DCs (there is no special way to go about this…i.e.; if we choose DOM1DC3 to be preferred for all clients is fine, on the same note, so is choosing DOM1DC7 if we wanted). The top alternates will be replica DCs from the local site, then other sites replica DCs. The reason for not doing the same DNS config on clients outside of site of PDCe as we did on replica DCs in that remote site is to save time and bandwidth for DNS name resolution.
EX:
DOM1DC1 – PDC – 10.0.1.2 – Dallas
DOM1DC2 – 10.0.1.3 – Dallas
DOM1DC5 – 10.0.1.6 - Dallas
DOM1DC3 – 10.0.1.4 – Houston
DOM1DC4 – 10.0.1.5 – Houston
DOM1DC6 – 10.0.1.7 - Houston

WORKSTATION2 – Houston site – P: 10.0.1.4 & A: 10.0.1.5, 10.1.0.7, 10.0.1.2, 10.0.1.3, 10.0.1.6


-Brandon Wilson
MCSE00/03, MCSA:Messaging, MCSA03, A+
almost got a paragraph there