Tip

How to use DNS with Active Directory

James Michael Stewart, Contributor

Active Directory relies heavily on DNS to function, but not just any DNS. Active Directory requires the DNS service found on Windows 2000 Server or Windows Server 2003 systems or equivalents.

Microsoft first introduced a DNS service with Windows NT Server 4.0. However, that early version of DNS from Microsoft is not capable of supporting Active Directory. Windows NT Server 4.0 DNS lacks three specific features: Service Resource Records (SRV RR), Dynamic DNS (DDNS) and Incremental Zone Transfers (IXFR). Without these DNS three features, Active Directory cannot function.

Once you've ensured that you have an Active Directory supporting version of DNS installed on your network, then you can deploy an Active Directory domain. But there is still another important consideration with regard to DNS. If your network will be connected to the Internet in some way, you need to design and prepare your internal DNS structure to support Internet access (inbound, outbound or both). You have several options, including:

  • Deploy a new fully qualified domain name (FQDN) hierarchy (i.e., namespace) on your internal network that is registered with the InterNIC. This means your internal LAN and the Internet have no logical distinction.

     

  • Expand an existing InterNIC registered namespace, such as one for a Web or e-mail server, and expand it to support your private network. This is basically a

Requires Free Membership to View

  • variation of the first option.

     

  • Use a sub-domain of an existing InterNIC registered namespace that is not currently being used on the Internet.

     

  • Use a local namespace that exists only within your private network and that is not connected to a namespace on the Internet.

     

Using a namespace that exists both on your private network and on the Internet is not the most secure configuration. This configuration allows malicious users to easily obtain the names of your network servers and direct attacks against them. A simple NSLOOKUP command can provide anyone with a list of your registered systems. One method to help reduce this threat is to deploy dual DNS servers. Both DNS servers should be configured with primary zone authority over your namespace. Place one of the DNS servers inside your network (i.e., inside the firewall) and include all of your domain controllers and Internet servers in that zone. Place the other DNS server outside of your network (i.e., outside the firewall), and exclude all domain controllers from its zone.

Overall the most secure DNS namespace configuration is to deploy a unique local-only namespace inside your network and not to use a FQDN that would be supported on the Internet. This will ensure that your DNS information is not accessible from outside of your network and external DNS activity would not advertise your vulnerabilities.


James Michael Stewart is a partner and researcher for ITinfopros, a technology-focused writing and training organization.


 

This was first published in March 2003

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.