1. Before you Begin

Make sure that you have the following information decided.

  • The name of your domain. See the Selecting a Name below.
  • The names and IP addresses of the servers that will run the DNS service. Generally these will be your domain controllers; it's preferable to have two or more if you can. Similar rules for server NetBIOS names apply as for domain names.

1.1. Selecting a Name

The first thing that you need to do is to choose a name (or names) for your domain(s).

For this option to work, you must use a name that doesn't exist in the public DNS (in the whole world) and is never likely to exist (or if it ever does, it will belong to your unit).

There are two main ways to do this.
  • use a subdomain of your DNS name (e.g. oucs-ad.oucs.ox.ac.uk)
  • Use a subdomain of a top level domain that isn't registered and is never likely to be (.local is a popular choice, e.g. oucs-ad.local); the other candidate is .internal.

The former is strongly recommended by Microsoft. Using the latter might cause problems for Bonjour which also uses .local (it's unknown how likely this is, but bear in mind that Bonjour is no longer just a Mac package; Adobe CS3 installs it, for example). The latter may also be a problem if you need to obtain certificates and you don't have your own certificate authority.

We would recommend using the former if you can, but if you are already successfully using a .local domain (as some units are), this configuration will usually work fine. When considering which name to choose, also bear in mind the following.

  • Do not use any made-up top level domain names apart from .local or .internal as these cause unnecessary traffic for the root name servers.
  • Do not make up a new subdomain of ox.ac.uk as this might be registered as a real subdomain in the future.
  • If you are using the central WINS service also make sure the first part of the name (oucs-ad in the example above) isn't going to clash with another unit's choice of name (either domain or server or client in fact). In other words, include some part of your unit name to make it unique. If you don't use the central WINS service you only need to ensure that the name is unique within your unit.
  • If you use a subdomain of your existing domain, make sure that the name you choose is not, and will never be registered as a hostname in the central DNS, or you may cause name resolution problems.

If you need more than one domain you can pick another subdomain (e.g. oucs-ad2.oucs.ox.ac.uk) or you could make a tree, e.g. use oucs-ad.oucs.ox.ac.uk and oucs-ad2.oucs-ad.ox.ac.uk. Again, take care if using the central WINS service.

For further information refer to the Background section.

2. Installing and Configuring DNS on the First Domain Controller

Check TCP/IP configuration
  • Configure the DNS servers in the TCP/IP configuration pages to use the central DNS servers.
  • Ensure that the server name and IP address are registered as usual in the central DNS servers.
Install Active Directory
  • Use dcpromo to install Active Directory onto the first server in a domain. With Server 2008 you can also use the Server manager to add the Active Directory Domain Services role; make sure you select [Use advanced mode installation] when the Active Directory Domain Services Installation Wizard (dcpromo) starts up.
  • When prompted about DNS (2000, 2003) or on the Additional Domain Controller Options page (2008), make sure that DNS will be installed and configured automatically as part of the Active Directory installation. On 2008 Server Core, use InstallDNS=Yes in an answer file, or /InstallDNS:Yes as a command-line switch to dcpromo.
Check DNS Zone Configuration
  • Once Active Directory and the DNS service are both installed, open the DNS management program ([Administrative Tools]). Open the Forward Lookup Zones folder and check that the correct zones have been created. You should see one entry with the same name as your Active Directory domain, and if this is the first domain in a forest (the forest root) you should also see a zone called _msdcs.YourADDomainName. (The latter is not created in Windows 2000-only domains.)
  • If by any chance the zones have not been created for you, you need to create them as follows.
    • In the Forward Lookup Zones folder create two Active Directory-integrated zones allowing secure dynamic updates. One should have the same name as the Active Directory domain. The other is only needed if this is the first domain in a forest (the forest root) but this is normally the case. It should be called _msdcs.ForestRootDomainName.This process is explained in more detail in the Appendix: How to Create and Configure a Zone.
    • Again, only do this in the forest root domain. Select the zone that has the same name as your Active Directory domain, right-click on it and choose [New Delegation...], then enter _msdcs as the name of the delegation.
    • Finally, again only in the forest root domain, select the _msdcs.ForestRootDomainName, right-click and choose [Properties]. On the [General] tab, change replication for the zone to the first option ([To all DNS servers in the Active Directory forest]).
Update TCP/IP configuration
  • Change the TCP/IP configuration of your server and remove the Oxford DNS server and replace with the address of your new DNS server (i.e. its own address). On 2008 server this should already have been done for you.
Register and check records
  • Reboot the server, or restart the NetLogon service, or wait a few hours to trigger the registration of records in the DNS.
  • Take a look in the file C:\Windows\System32\Config\netlogon.dns and compare the entries with the entries in the DNS management tool. You may need to refresh or even restart the latter before you can see them.
Configure forwarders
  • Configure your DNS servers to send all requests for information that they do not hold themselves to the DNS Caching Resolvers. This is recommended for security reasons and also speeds up queries for information in the ox.ac.uk domain. Configure this via the Forwarders tab in the [Properties] of the server object in the DNS management tool. Make sure there is an entry for All other DNS domains and add the addresses for each of the DNS Caching Resolvers to the forwarders list for this entry.
Run tests to check for errors
  • Check the event logs for errors.
  • Run netdiag /v /test:dns and dcdiag /v /test:dns using the Support tools included on the Windows server CD (the latter won't work on 2000) or installed by default on 2008. to check that everything looks good.
Configure Firewalls and Clients
  • Refer to the other sections in this document for details on updating the configuration of perimeter firewalls and clients.

3. Configuring the Second and Subsequent Domain Controllers

Carry out the following operations on the server you are adding to the domain, unless stated.

Check TCP/IP configuration
  • Configure the DNS servers in the TCP/IP configuration pages to use Windows DNS server that you configured as per the previous section .
Install Active Directory
  • Use dcpromo to install Active Directory adding the server as a new server in an existing domain.
  • This time, you shouldn't be prompted about DNS on Windows 2000 or 2003, but on 2008 you can again select to install the DNS server with Active Directory Domain Services on the Additional Domain Controller Options page. Again, on 2008 Server Core, use InstallDNS=Yes in an answer file, or /InstallDNS:Yes as a command-line switch to dcpromo..
Install the DNS Service
  • If you didn't install the DNS service as part of the domain controller installation (i.e. on 2000 or 2003), use [Add/Remove Programs] (Windows Components/Networking Services) or the Configure your Server wizard to install the DNS service.
  • Since you have configured DNS to use Active Directory-integrated zones, you don't need to configure the zones again.
Check that the Zones have replicated
  • Open the DNS management program and check that the zones shown below are visible.
    • ActiveDirectoryDomainName
    • _msdcs.ActiveDirectoryDomainName (only for the forest root domain)
Update TCP/IP configuration
  • Change the TCP/IP configuration of your server and its own IP address to the list of DNS servers. On 2008 server this should already have been done for you. Also add the addresses of any other internal DNS servers that you run. We'd recommend not putting its own IP address as the first in the list.
Register and check records
  • Reboot the server, or restart the NetLogon service, or wait a few hours to trigger the registration of records in the DNS.
  • Take a look in the file C:\Windows\System32\Config\netlogon.dns and compare the entries with the entries in the DNS management tool. You may need to refresh or even restart the latter before you can see them.
Configure forwarders
  • Configure your DNS servers to send all requests for information that they do not hold themselves to the DNS Caching Resolvers. This is recommended for security reasons and also speeds up queries for information in the ox.ac.uk domain. Configure this via the Forwarders tab in the [Properties] of the server object in the DNS management tool. Make sure there is an entry for All other DNS domains and add the addresses for each of the DNS Caching Resolvers to the forwarders list for this entry.
Run tests to check for errors
  • Check the event logs for errors.
  • Run netdiag /v /test:dns and dcdiag /v /test:dns using the Support tools included on the Windows server CD (the latter won't work on 2000) or installed by default on 2008. to check that everything looks good.
Update other domain controllers
  • On your other DNS servers, update the TCP/IP configuration, adding the IP address of the new DNS server to the list of DNS servers. Again we'd recommend any server's own IP address as the first in the list (but always include it on the list).
Configure Firewalls and Clients
  • Refer to the other sections in this document for details on updating the configuration of perimeter firewalls and clients.

4. Multi-domain Environments

If you have a forest with more than one domain, or you need to set up trusts between two domains in different forests, some extra work may be required to make sure that names can be resolved between the domains.

The problem is that you have two private domains for which no information is held in the public DNS, and each has its own self-contained DNS which contains no information about the other domain.

Solutions to this problem have not been tested, so we advise setting up a trial environment if this is what you need to do. There are a number of possible approaches as follows. In general you should adopt one of the following approaches.

  1. Where both domains are in the same forest, change the replication for the DNS zones to replicate [To all DNS servers in the Active Directory forest] (Windows 2003 and above).
  2. Configure the DNS servers for domain A to forward queries for zone B to the DNS servers for domain B and vice versa.
  3. Where you have two separate forests, configure secondary zones for domain A on the domain B DNS servers and vice versa.

If you have one domain that is using an existing external name, and a second that is using a private internal name, the solution is likely to be similar, but your main problem is ensuring that the internal names can be resolved; the external names should take care of themselves.

In all cases you need to ensure that your firewall configuration is correct, allowing all DNS servers to be able to query each other.

5. Configuring Firewalls

If you run a firewall for your unit, you need to allow outgoing requests to other DNS servers, but you don't need to allow any incoming DNS requests to your servers as no other DNS servers know about your internal names.

Source AddressSource PortDest. AddressDest. Port
Your internal DNS Servers Any Any TCP 53
Your internal DNS Servers Any Any UDP 53

6. Configuring Clients

In this configuration all clients that need to join the domain must be configured to use your Active Directory DNS servers rather than (or as well as) the central Oxford DNS servers. If you don't configure them in this way, they won't be able to resolve the names of services offered by your domain controllers including authentication. They may fall back on NetBIOS names, WINS and broadcasts, but this is less than ideal.

It can be a good idea to include at least one of the central resolvers in the list of name servers for resilience. This allows clients to locate internet services even if your domain controllers are unavailable.

In this setup you can configure your clients and servers to register their names and IP addresses dynamically in DNS. You must continue to use the normal mechanisms via the OUCS web pages to register them for addresses that can be resolved externally.

In this configuration you can also allow your clients to register their names automatically with your local DNS servers. Software that expects to locate clients by combining the Active Directory name of the client with the DNS suffix should work correctly, so long as it is installed on systems that are part of the domain.

7. Additional Points to Note

In this configuration you need to pay particular attention to any services that need to be available externally, or from machines outside of your Active Directory domain(s). This most often applies to certain websites, such as Outlook Web Access, Sharepoint etc. where you want to allow users to access the sites directly when away from the office.

Any servers running these types of services must be registered in the central DNS in the usual way, and you may need to configure them slightly differently so that they are aware of and return their external identity when required.

For example, SharePoint Services 3.0 allows you to configure different zones, such as Intranet, Extranet etc., and to configure URLs for each as required. If you run SharePoint, you may need an Intranet zone with a URL (for example) of http://servername.ad-domain.local/ but also an Extranet zone with a URL of http://servername.unitname.ox.ac.uk/.

For Outlook Web Access you need to make sure that the server returns the public name of the server, not its internal name. Similar configuration requirements may be necessary for other services. It may be difficult or impossible to access some services. For example, DFS namespaces that use the domain name.

8. Background

You may consider using this option if for some reason you can't use the same name as the DNS name assigned to your unit (such as oucs.ox.ac.uk, chem.ox.ac.uk, etc.)

The main decision to be made is how to name your internal Active Directory namespace. Microsoft makes a number of suggestions; which is recommended appears to have changed over the years. The two main options are as follows:

  1. Use a subdomain of the assigned DNS for your unit such as oucs-ad.oucs.ox.ac.uk, chem-ad.chem.ox.ac.uk
  2. Use a completely different domain name such as oucs-ad.local, chem-ad.local

In making your decision bear in mind that you must use a DNS name that cannot be resolved to a real DNS name that is in use, or may possibly be in use on the internet, or you will end up with total confusion for your clients. So don't use unit.com, unit.org, unit.ac.uk or anything along these lines.

Using adsubdomain.unit.ox.ac.uk is fine because currently subdomains of unit.ox.ac.uk are not generally used in the central DNS, so there is no danger of there being a clash. Also, if this situation changed, it is possible that any subdomains that you have set up could be configured on the main DNS servers.

If you use this configuration, then all of your servers and clients will usually still be registered in the central DNS with names of servername.unit.ox.ac.uk, clientname.unit.ox.ac.uk etc., but they will have a second identity of servername.adsubdomain.unit.ox.ac.uk, clientname.adsubdomain.unit.ox.ac.uk, etc. in DNS servers that you run on servers within your unit.

Using a Subdomain of unit.ox.ac.uk for your Active Directory Domain Namespace

Using a subdomain of .local is also common practice. The .local domain is unlikely ever to exist as a real top level domain. However be a little cautious as it is used by Apple's Bonjour services for name resolution, so you may need to take care if you have Macs and want to use a subdomain of .local, or if you use Bonjour on your Windows desktops. See Apple's Developer Connection Domain Naming Conventions notes for more information.

If you use this configuration, then all of your servers and clients will usually still be registered in the central DNS with names of servername.unit.ox.ac.uk, clientname.unit.ox.ac.uk etc., but they will have a second identity of servername.adsubdomain.local, clientname.adsubdomain.local etc. in DNS servers that you run on servers within your unit.

Using a Subdomain of .local for your Active Directory Domain Namespace

This configuration is likely to work best when used in a relatively self-contained environment where relatively little external access is required.

9. Appendix: How to Create and Configure a Zone

Start the DNS management console ([Start/Programs/Administrative Tools/DNS]). Open up your server (OUCS-PHANTOM in the example below) in the left hand window and you should see two folders — Forward Lookup Zones and Reverse Lookup Zones . There should be nothing in either of them.

If there is an entry under Forward Lookup Zones; (there may be one called unitname.ox.ac.uk) then delete it.

Now right-click on the Forward Lookup Zone folder and select [New Zone]. Click on Next and then choose [Primary] as the zone type and make sure the option to Store the zone in Active Directory is checked.

Click on Next and type in the name of the zone you want to create. The zones are as follows (replace unitDNSname with the appropriate name for your unit).
  • ActiveDirectoryDomainName
  • _msdcs.ActiveDirectoryDomainName (only for the forest root domain)

Click on Next, check that the details are correct and click on >Finish. You now should have an entry for the zone visible within the Forward Lookup Zones folder.

DNS Management Console showing _msdcs.oucs.ox.ac.uk forward lookup zone.

Right-click on this entry and select [Properties]. First check on the [General] tab that [Only secure updates] is the setting for [Allow dynamic updates? ]

Next click on the [Start of Authority (SOA)] tab and change the [Responsible person] entry. This box should contain a valid e-mail address which will be directed to the person responsible for the server. By convention you should substitute a. for the @ in the e-mail address. You should also include a . at the end of the address.

_msdcs.oucs.ox.ac.uk DNS Zone Properties — SOA Page