Example Configurations

Most corporate domains designs fall into one of the following models, the Single domain model, the Master domain model, the Multiple Master domain model or the Complete Trust domain model. For more information on each of these models refer to the Windows NT Adminstration guide.

In this section we are going to discuss two of these models, the Complete Trust model and the Multiple Master model. We will look at the models before DNS and the models after DNS. Hopefully, this will give you an understanding of how to implement DNS within your own environment.

Complete Trust Examples

Before DNS

Let's start with the following domain design (without DNS) and determine the best approach to a DNS design architecture. The following is an example of a Complete Trust domain model. There are 2 domains "Reno" and "Dallas." Let's assume the following:

There is a data-center in Dallas and Reno with a high speed link between both data-centers
Each data-center has a large number of remote sites (500 each with 20 users each) that it supports via 38K links direct connected to the appropriate data-center (in our diagram we only show two).
Each data-center has the primary domain controller (PDC) and WINS server that supports the remote locations.
Each remote site has one or more Windows NT backup domain controllers (BDCs) that get their security account management (SAM) database from their respective PDC in the data-center. This means that user account replication is going to occur over the slow (38K) link, hence there are few user accounts in the database and the password expiration is turned off. A Complete Trust model was used in this design because there is only one server per remote location and there were 20 users per location. If a master or multiple master domain design was in place there would be a requirement for two servers. If one domain was used then the user account database would have been too large. A domain in each location was not considered because the entire corporate network for this company consists of 1000 remote sites.
The remote BDCs contain a #PRE (preloads permanent entries into the NetBIOS cache—to view the cache type "nbtstat -c") entry for all Primary Domain Controllers in their LMHOSTS file (ex. 128.247.145.200 DALLAS_PDC #PRE #DOM:DALLAS). This is important because each remote BDC needs a secure session setup between its respective PDC and a PDC or BDC in all trusted domains. Because of the slow link to each of the remote locations and the fast link between data-centers it makes more sense to have the secure session setup between the local BDCs and the PDC of the other trusted domains.
Each remote site has a number of Mnode (broadcast first and then check the WINS server) TCP/IP client workstations (in our diagram we only show two) on the same LAN as the local Hnode (check the WINS server for name resolution before broadcasting) Windows NT-based server(s).

When designing a solution it is important to consider the traffic flow of "session setup" and "logon validation." You never want to design a solution that would keep a client from contacting its local server if the link between the remote location and its data-center was lost.

In our example logon validation will occur locally between the clients and the local servers. Session setup and name resolution to the "local" servers will also occur locally because the clients are set up as Mnode TCPIP clients. Session setup and name resolution between a client in one location and a server in another remote location will take a much different path and include both the WINS server in the data-center and the clients domain PDC. In our example (note that in our example some of the devices were removed to make the diagram easier to view), the Windows NT Workstation-based machine in the Dallas domain location 200 is connecting to the server \\BDC100 in the Reno domain location 100. The client first contacts the WINS server in its data-center to get the IP address of the \\BDC100 server (1 and 2). It then tries to establish a session to the \\BDC100 server (3). The \\BDC100 server in turn uses its secure session to the clients PDC for "pass through authentication" purposes (4 and 5). If the security is verified, the client is allowed to establish the session and proceed (6). In this example, there are three physical points of failure, the link between Location 200 and the Dallas data-center, the link between the Dallas data-center and the Reno data-center, and the link between Location 100 and the Reno data-center.

After DNS

Now that you understand the current architecture, how would you design a Windows NT 4.0 DNS implementation?

Here is a possible solution. There are four zones, four domains (com, acme.com, reno.acme.com and dallas.acme.com) and a DNS server in each remote location in the following design.

The following are facts about the design:

The DNS servers that contain the reno.acme.com and dallas.acme.com zone files are located in their respective data-centers and the DNS server that contains the acme.com zone file is located in one or the other data-center depending on which data-center has the most client-side remote location session setup traffic. Each DNS zone should also have a WINS record that points to its respective WINS server. There is also a DNS cache only server in each of the remote locations for the same zone.
Since there was a server located in the remote location, a DNS server was put there as well. Since the link is so slow it makes more sense to make this a cache only server. If there were no servers in the remote location then a DNS probably would not really be necessary, however each case is different and fast name to IP address resolution is a business decision that has to deal with the cost of adding another server versus the cost of slow name resolution.
In our case reno.acme.com and dallas.acme.com are going to be domains on the root server in the data-centers. One of the root servers, probably the one in Dallas, will also house domains com and acme. Each of the caching servers in the remote locations will have these servers listed in their cache file.
DNS WINS lookup should be configured on the DNS servers in each data-center.
We may want to consider a secondary to each primary located in the data-center for fault tolerance purposes.
Since there are no secondary servers in the remote sites there will be no reason to add these to the notify list. However, the secondary servers in the data-centers should be in the notify list.

With this design in place a client from a remote location can now establish a session via HOST name rather than NetBIOS name. For example, instead of typing

Net use * \\BDC100\public

they can type

Net use * \\BDC100.reno.acme.com\public

Let's follow the path of traffic if the client chooses to connect via the HOST name mechanism,

The client contacts its local DNS server with a recursive query (1). The dallas.acme.com cache-only DNS server checks its local memory cache, if the IP address for BDC100.reno.acme.com is not cached, the dallas.acme.com DNS server sends an iterative query to the ROOT server, then to "COM," then to "DOMAIN.COM" (that is Acme.com) (2). The acme.com server will respond back (3) and tell dallas.acme.com to contact reno.acme.com (4). When dallas.acme.com contacts reno.acme.com, the DNS server reno.acme.com will check the WINS server (5) defined in its WINS record (6) and the reno.acme.com responds with the IP address (7) and the directed name query and session setup can continue (8,9,10,11 and 12). If the IP addresses were not cached, it would take eight frames for IP address to name resolution (compared to two frames in the WINS design).

If the dallas.acme.com DNS server was configured with a "Forwarder" the request to acme.com would have still been iterative. However, if the dallas.acme.com DNS server was configured as a "Slave" server the request to acme.com would have been recursive.

Once Dynamic DNS and Enhanced Directory Services become a reality, the WINS servers in this enterprise can be removed and NetBIOS can be turned off. From this point on DNS will be used as the index into the directory to find machine objects such as computers and domain controllers.

Multiple Master Example

In the following section we are going to go through a very simple "well architected" Windows NT 4.0 Multiple Master domain model and show how to implement DNS within that environment for a safe migration to future versions of Windows NT.

Before DNS

Here is the typical Multiple Master layout with two master domains and six resource domains:

Let's use the "Reno" and "Dallas" domain structure and assume the following:

There is a data-center in Dallas and Reno with a high-speed link between both data-centers (something like a T1).
Each data-center has a number of remote sites that it supports via 512KB links (in our diagram we only show two, one for location 100 and another for location 200)
Each data-center has the primary domain controller (PDC) for the data-centers Master domain, a WINS server and a backup domain controller (BDC) for the other Master domain.
Each remote site has 1 Windows NT backup domain controller (BDC) for each Master domain (account domain) and a PDC (and an undetermined number of BDCs) for the resource domain (no user accounts defined).
There is a WINS server, that is a push-pull partner to the WINS server in the respective data-center, in each remote location. The WINS servers in the data-centers are push-pull partners with each other as well.
All clients and servers are Hnode because of the local WINS server.
All Windows NT-based workstations in the Resource domains have their machine accounts in their respective resource domains, however the users log on to the Master domains.
A router separates all clients from the servers in the remote locations.

The following figure shows the current layout:

Let's look at the traffic flow for logon validation and session setup name resolution. In most Multiple Master domain scenarios, the client Windows NT-based machine accounts exist in the resource domain and the user logs onto the Master domain. All logon validation will be done locally within the site. A Windows NT Workstation-based client upon bootup queries the local WINS server for a list of BDCs (via name query for DOMAIN <1C>). The WINS server will respond with a list of up to 25 BDCs (the list contains the PDC and all of the BDCs for the master domain that registered with it, as well as others that were replicated to it). The client then sends a request to each server on the list and uses the first server to respond (which normally will be the local master domain BDC) as its server that it sets up a secure channel with and uses to do logon validation.

Remote session setup from a client running Windows NT client in a resource domain to a server in another resource domain occurs as follows as is shown in the next diagram.

The client running Windows NT Workstation will query the WINS server for the address for the server in the domain it wants to contact (1). The WINS server will reply with the address (2) because it was replicated to it previously. The Windows NT-based workstation will then contact the server directly (3). That server will see that the session setup request is from a user in a trusted master domain and use its secure channel to a trusted domain BDC or PDC to verify the credentials (5) and then the server will either allow the client to connect or reject the request (6).

After DNS

Now that you understand the current architecture, how would you design a Windows NT 4.0 DNS implementation? The first thing we have to determine is how to structure the DNS domains. We know that for future migration purposes DNS domains should equal Windows NT 4.0 domains. The first and most important question is now answered—that is, how many domains do I need? The answer is, one for each Windows NT domain—ten.

The second question is, how should the domain names map? For example, should we have L100.reno.acme.com or L100.acme.com? In any design it's important to keep it simple! That means in our case, keep the name as short as possible. There is another part to this second question and that is, what DNS domain should the clients and servers be part of? In the Multiple Master scenario, the logical solution is to put all workstations within a DNS domain called L100.Acme.Com and L200.Acme.Com and so on, then put all servers within a domain called Reno.Acme.Com and Dallas.Acme.Com (this may require changes to each clients TCPIP configuration). This will allow for easy migration to both Dynamic DNS and Enhanced Directory Services.

The third question is, how many servers will we need to support this? There will be 10 DNS domains (the eight expected + acme.com and com) and eight DNS servers, just like there are eight Windows NT domains and domain controllers (PDCs and BDCs). This will require that the DNS server service be running in each of the locations. The service can run on the existing PDC or BDC within the remote location assuming there is adequate capacity. The DNS servers in the locations that house the resource domains will be primaries for their Windows NT resource domain names such as L100. Acme.Com and secondaries to their respective Windows NT Master domains such as Reno.Acme.Com.

With all of this said, the DNS domain hierarchy might look something like the following:

With this design in place, a client from a remote location can now establish a session via HOST name rather than NetBIOS name. For example, instead of typing

Net use * \\WKS100\public

they can type

Net use * \\WKS100.L100.acme.com\public

If the client chooses to connect via the HOST name mechanism, let's follow the path of traffic and compare it to the path via WINS (note that in our example some of the devices were removed to make the diagram easier to view).

The client contacts its local DNS server with a recursive query (1) for the "NT workstation.domain." The local DNS server checks its local memory cache, and if the IP address for WKS100.L100.acme.com is not cached, the local DNS server sends an iterative query to the ROOT server, then to "COM," then to "DOMAIN.COM" (that is acme.com) (2). The acme.com server will respond (3) back and tell the local DNS server to contact L100.acme.com (4). L100.acme.com will check the WINS server (5 and 6) (the DNS server asks itself, "I should have the IP address for host WKS100.L100.acme.com because I am authoritative for domain L100.acme.com, but I don't, so check WINS") defined in its WINS record and responds with the IP address (8) and the directed name query and session setup can continue (9,10,11,12). If the IP addresses were not cached, it would take eight frames for IP address to name resolution (compared to two frames in the WINS design).

Both zones on the DNS server within the remote location should point to the same local WINS server.

The local DNS server authoritative for reno.acme.com did not contact its local WINS server because the DNS name being asked for was not a direct child of its DNS domain reno.acme.com. It was only a direct child of a DNS server that was authoritative for L100.acme.com.

A client from a remote location can also establish a session with a remote server via the HOST name rather than NetBIOS name. For example, instead of typing

Net use * \\PDC100\public

they can type

Net use * \\PDC100.reno.acme.com\public

The client contacts its local DNS server with a recursive query (1) for the "NT workstation.domain." The local DNS server checks its local memory cache, and if the IP address for PDC100.reno.acme.com is not cached, the local DNS server sends an iterative query to the ROOT server, then to "COM," then to "DOMAIN.COM" (that is acme.com) (2). The acme.com server will respond (3) back and tell the local DNS server to contact reno.acme.com (4). When the local DNS server contacts reno.acme.com, the DNS reno.acme.com will check the WINS server (5 and 6) (the DNS server asks itself, "I should have the IP address for host PDC100.reno.acme.com because I am authoritative for domain Reno.acme.com, but I don't, so check WINS") defined in its WINS record and respond with the IP address (7). The local DNS then returns that address to the client (8) and the directed name query and session setup can continue (9,10,11,12). If the IP addresses were not cached it would take eight frames for IP address to name resolution (compared to two frames in the WINS design).

The local DNS server did not contact its local WINS server because the DNS name being asked for was not a direct child of a DNS domain L200.acme.com or dallas.acme.com it was only a direct child of a DNS server that was authoritative for reno.acme.com.

Once Dynamic DNS and Enhanced Directory Services become a reality the WINS servers in this enterprise can be removed and NetBIOS can be turned off. From this point on, DNS will be used as the index into the directory to find machine objects such as computers and domain controllers.

It may seem like there are more points of failure for name resolution (eight frames via DNS versus. two frames via WINS), however with this architecture there will be less Dynamic DNS replication than there is WINS replication today and the flat 16 character NetBIOS name space will be history!