通过

DNS auto-configuration during DCPROMO

  • 项目

Have you ever installed the DNS Server service as part of the promotion of a new DC, to end up wondering how this new DNS Server got automatically configured to use forwarders and root-hints? Have you noticed that this process also adds the loopback adapter of the server to the DNS search list in the resolver?

When DCPROMO installs the DNS Server service it also activates, by default, the auto-configuration of the DNS Server service. This auto-configuration process configures the forwarders list, the root-hints and the resolver, among other things, like creating the zones if required.

NOTE: this auto-configuration can be skipped by passing the SkipAutoConfigDns promotion parameter to dcpromo.

I wanted to give the information on how this auto-configuration is done regarding the forwarders list, root-hints and resolver. Remember that you can always edit these parameters after they are configured to match your DNS design.

Auto-configuration of Forwarders

The first step is to configure the forwarders list for the new DNS server. Two possible methods are used to build this list. The second method is skipped if the first one is successful.

  1. Try to copy the forwarders list from a peer DNS server. A peer DNS server is any DNS server that has a copy of this DC domain’s zone. To get the peer server list the process queries for the NS list of the domain’s zone and then contacts each server returned on the list until it finds one from which it can copy the forwarders list. Once the process finds a peer from which it can copy the forwarders list it skips the next step. If no peer is found (because the NS query returned empty), none of them could be contacted, or none of them has forwarders configured, then move to step #2.
  2. If the previous step was not able to provide a forwarders list, then use as forwarders all the DNS Servers that are currently listed in the resolver for all the adapters, without any specific order.
  3. If none of the previous two steps can provide a forwarders list, then the new DNS server will not have forwarders configured.

NOTE: remember that having a DNS server without forwarders is a valid configuration for the service. In this case the server will use its root-hints to resolve names in namespaces that it does not host.

Examples:

  1. Suppose you are promoting a new server in a new domain named contoso.local. The server is pointing to two DNS servers: 10.0.0.1 and 10.0.0.2. None of these servers have the zone contoso.local:
    1. The first method is to get the forwarders list from a peer. The server will issue a query to its DNS servers for the Name Servers list (NS record type) of the zone contoso.local. Because this zone does not exist yet then this query will return empty. As we cannot find a peer to copy the forwarders from we go to method #2.
    2. The forwarders list is built as 10.0.0.1 and 10.0.02 in the second method. This is because we are just copying the DNS servers listed in the resolver.
  2. Suppose you are promoting a new server in an existing domain named contoso.local. The server is pointing to three DNS servers: 10.0.0.1, 10.0.0.2  and 10.0.0.3 which are DCs with DNS for the same domain and have a copy of contoso.local. 10.0.0.1 does not have forwarders configured, 10.0.0.2 is forwarding to 10.1.1.1 and 10.1.1.2 and 10.0.0.3 is forwarding to 10.2.2.1 and 10.2.2.2 (this is a very weird, and probably unstable, DNS configuration but I just wanted to use it as an example):
    1. The query for the NS list of contoso.local will return 10.0.0.1, 10.0.0.2 and 10.0.0.3 (suppose that in this order). We first contact 10.0.0.1 to get its forwarders list, and we find that it is empty, then we contact 10.0.0.2 and query for its forwarders list, and we get 10.1.1.1 and 10.1.1.2. At this point we already got a list, then we skip querying any other server returned by the query (like 10.0.0.3), and also skip method #2.
  3. Suppose you are promoting a new server in a new domain named contoso.local. The server is not pointing to any DNS servers (probably because you are creating a new forest in an environment that does not have DNS yet):
    1. The query for the NS list of contoso.local will return empty, then we cannot use this method to get the forwarders list from a peer.
    2. We cannot create the forwarders list by copying the configuration in the resolver, because there are no DNS servers listed there.
    3. In this case the new DNS server will end-up with no forwarders configured.

 

Auto-configuration of Root-Hints

The second step is to configure the root-hints for the new DNS server. This is done by querying the root-hints list for all the servers that we have configured in the resolver, and use the list that has the largest number of servers on it; if more than one has the largest number of elements, then we choose the first one that we found with that number. Note that we are not merging the lists that we got from each server, we are just comparing the sizes of the lists and using the one with the largest number of elements on it.

One condition that should be met to accept the root-hints lists is that all the lists should “intersect” in at least one element, i.e., at least one DNS server should be present in all the lists to consider that the lists are valid. If no intersection occurs, then we do not copy any of the lists. This would be a very unusual, and probably wrong, configuration.

Remember that the DNS Server service comes pre-configured with a root-hints list (the Internet root-hints), then even if we cannot copy the list from another server our new DNS will still have a root-hints list to use.

This step is important in environments that have deployed an internal root zone (“.”) because the new DNS server will be auto-configured to use the servers hosting that zone as its root-hints. In the case that this server also hosts the root zone, then the root-hints list will be disabled once the service starts (a server hosting a root zone cannot have root hints).

 

Auto-configuration of the Resolver

The third step is to configure the resolver (DNS Client) to use the new DNS Server. This is done by adding the loopback address to the DNS search list. The position where the loopback is added is determined by whether we are creating a new forest, new domain, new tree, new replica RWDC or new RODC. The logic is like this:

  • The new DC is the first DC of the forest: replace the resolver list and set it to point only to the loopback.
  • The new DC is the first DC of a new tree in an existing forest: add the loopback as the first one on the resolver list. Existing entries in the list are maintained.
  • The new DC is the first DC of a new child domain in an existing forest: add the loopback as the first one on the resolver list. Existing entries in the list are maintained.
  • The new DC is an additional RWDC in an existing domain: add the loopback as the last one on the resolver list. Existing entries in the list are maintained.
  • The new DC is an RODC: add the loopback as the first one on the resolver list. Existing entries in the list are maintained.

 

Examples:

Suppose you are promoting a new server. The server is pointing to two DNS servers: 10.0.0.1 and 10.0.0.2. After the auto-configuration of the resolver the list will look like:

  1. If the server being promoted is the first DC in a new forest: 127.0.0.1 (the existing list is replaced with the loopback)
  2. If the server being promoted is the first DC in a new tree in an existing forest: 127.0.0.1, 10.0.0.1, 10.0.0.2 (the loopback is added to the beginning of the list)
  3. If the server being promoted is the first DC in a new child domain in an existing forest: 127.0.0.1, 10.0.0.1, 10.0.0.2 (the loopback is added to the beginning of the list)
  4. If the server being promoted is an additional RWDC in an existing domain: 10.0.0.1, 10.0.0.2, 127.0.0.1 (the loopback is appended to the end of the list)
  5. If the server being promoted is an RODC: 127.0.0.1, 10.0.0.1, 10.0.0.2 (the loopback is added to the beginning of the list)

 

Other auto-configuration Tasks

There are other tasks that are done by the auto-configuration process, like creating the zones when needed. This process is straight forward and well understood, so I will leave it out of this post for now. Let me know in the comments if you would like to read a post about the auto-creation of the zones during dcpromo.

 

As always, I hope that you find this information helpful.

Comments

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    April 11, 2012
    Excellent.... now I know from where those forwarders are comming...

  • Anonymous
    May 22, 2013
    The comment has been removed