Friday, November 7, 2008

Some Random Thoughts for AD & DNS best practices.





DNS as known as Domain name system and widely accepted and it is being used heavily with active directory and ADDS services. I have noticed most of the time administrators try to find the tune up the DNS or wonder what the correct way to deal with it is. I decided to put some best practices and tune up I use it all the time and share with you all here on my blog.

Before we dive into DNS I wanted to refresh some good information in regards to DNS ports.

  • Most of us do know DNS uses port 53 UDP and TCP it depends the query.
  • DNS Service uses dynamic UDP ports (above 1023) for all client standard query messages
  • The client requests from a random port above 1023 to server port 53
  • DNS Servers response from the port 53 to the originating port on the client (above 1023)
  • Only the server-to-server communication goes from port 53 to port 53. The requests as well as the responses.

What are the some of the best practices when it comes to configuring and tuning DNS servers in active directory? Please note that most of the experienced administrators will recommend using AD integrated DNS.

  1. Point DNS servers to itself in the TCP/IP properties as their Primary DNS. Pointing AD/DNS server to ISP DNS servers on the TCP/IP Properties is NO NO NO !!!!!!
  2. Install DNS on domain controllers and use Active directory integrated DNS option.
  3. Using more than 2 NIC on the DC's/DNS's are NO NO NO !!!!!!
  4. Every DC registers bunch of dynamic records in DNS and having two NIC will confuse the clients and applications who are trying to locate services from DCs, so avoid the trouble and don't let this happen. Most often I see genius idea of having second interface on the domain controller for backup purpose (backup VLAN)
  5. Disable all other interfaces if there are any and name them "Disabled do not enable" on the TCP IP properties of each disabled interface, on the advance tab "register this connection's addresses in DNS" Unchecked, in case the interface gets enabled and register itself to the DNS database.
  6. Forward the recursive queries which your domain is not authoritative for to the ISP DNS servers and let them do the heavy work. ( internet connectivity for the servers and clients)
  7. Enable the root hints option beside forwarders if the forwarders won't response the queries.
  8. On the NIC card properties of your DC/DNS make sure the option "register this connection's addresses in DNS" is checked, the box is ticked.
  9. Go to your DNS, forward lookup zone locate _msdcs.yourDomain.org , go to properties , click on name servers and make sure all the servers listed there are domain controller and they are functioning properly. Each IP listed there will claim to be the DNS name space for your domain and will response the queries. If there is an IP address no longer DC/DNS remove it from the list
  10. Go to your DNS, forward lookup zone locate _msdcs.yourDomain.org , on the bottom make sure "Secure only" is selected , or otherwise if you have UNIX servers updating DNS you will need to enable secure and none secure, but most of the cases "Secure ONLY" unless you really know the environment don't pock around with this settings and leave it secure.

    Make sure the zone Type is Active Directory-Integrated.

    You can enable dynamic updates from command line

    dnscmd ServerName /Config {ZoneName..AllZones} /AllowUpdate {10}


  11. Same goes for SOA and NS records make sure the IP addresses listed there are healthy valid DC/DNS servers
  12. Open DNS console at the very top where you see the computer icon , make a right click and go to properties
  • Interfaces, listen on
  • Select "Only the following IP Addresses"
  • Make sure there is one interface (Production) listening on DNS
  • I recommend renaming each NIC card as "Production" so you know by looking at the interface what it is.

  1. Click on forwarders
  • List the ISP IP addresses under forwarders for internet name resolution
  • Enable "Use root hints no forwarders are available"
  1. Click on Advance
  • Enable following
  • Fail on load if bad zone data
  • Enable round robin
  • Enable netmask ordering
  • Secure cache against pollution
  • Make sure "name Checking" is Multibyte (UTF8)
  • Load zone data from active directory and registry
  1. Click on monitoring
  • Select a test type
  • Simple query against this DNS server
  • A recursive query to other DNS servers
  • Make sure it passes

Couple things to remember

  • Never install any other application on the DC itself , DC' s are busy they do have ADDS database installed on them and they authenticate users, leave them alone.
  • Installing Exchange on Domain controller is NO NO NO !!!!!!
  • Installing any other application on DC is NO NO NO !!!!!!
  • Not following MS best practices on the physical and logical partition of the domain controllers NO NO NO !!!!!!

Best practices for DNS

Frequently Asked Questions About DNS

Troubleshoot DNS Name Resolution

10 DNS Errors That Will Kill Your Network

Troubleshooting Active Directory DNS Errors

Troubleshoot DNS Name Resolution

Oz ozugurlu

MVP (Exchange)

MCITP (EMA) , MCITP (EA ) MCITP(SA),

MCSE (M+,S+) MCDST, Security+, Server +,Project+

Blog: http://www.smtp25.blogspot.com

4 comments:

Anonymous said...

Please provide references for your comments. I feel like many of the things you've listed here may not be desirable, but also not as devastating as you suggest.

Oz Casey, Dedeal said...

Mike, as the article states these are Random thoughts and most of it is listed in the DNS best practices. I would love to know what information in the post you thing might be inaccurate, if you can leave detailed feedback, or specific questions I would love to go back and make the adjustments or give more information.
You can also e-mail me telnet25@gmail.com directly
Thanks again for reading my blog
Best
Oz

Anonymous said...

This is a good article overall, so take no offence to my comments! The main thing that I noticed is about installing exahcnage and/or other apps on DCs. this is not ideal, but it is supported, and can actually benefit in some situations. a prime example is small business server. DCs are often under-utilized and server-sprawl is a growing problem in the industry.

Oz Casey, Dedeal said...

Mike,
You are absolutely right , MS best practices states installing an sizing exchange is very important, on the other hand MS has SB version , not only exchange, the DC , ISA and SP all in the same box. To me this brings complexity, but this is what people get for less money (-:
I totally understand the budged strains and limitations driving factor and for small businesses getting SB version and thinking saving money, and running everything all together with 5 or 10 users, which is not a problem, but from my experience, it complex configuration is hard to manage, has limitations and does not have easy way to get out.
I never liked seeing multiple applications on the same box for stability reasons after working with Enterprise environment over years and seeing the results for dedicated correct setup for application server or DC is always happy.
Exchange is my patient and refuses to install Exchange with another application and avoid doing this if it is all possible.
Yes we all do things we don’t like time to time, installing SB is no of it for me. I know many people out there; SB experts will say correct setup will bring results and etc. I have seen SB working properly in a small environments but I still don’t like seeing exchange running on top of domain controller, to me this is no, no, no (- :

Thanks again for taking your time and reading my blog
--oz