Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
How should I configure DNS in my Active Directory environment?
DNS config. for AD domains
Ok GlenJohnson you asked for it so here it is....despite the lateness.....
From a replication standpoint, I say stay away from delegation of zones for child domains....I have pasted in a template for recommended DNS config that I send to customers...currently your DNS config is not what it should be...although it is workable...it still has many chances and glances to break you and bring your environment to its knees:
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
From a replication standpoint, I say stay away from delegation of zones for child domains....I have pasted in a template for recommended DNS config that I send to customers...currently your DNS config is not what it should be...although it is workable...it still has many chances and glances to break you and bring your environment to its knees:
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