TCP/IP is technically made up of two protocols. The upper layer, Transmission Control Protocol, is responsible for breaking data down into smaller packets to be transmitted over the network from a sending system (local and Internet), and the TCP layer on the receiving system reassembles the packets it receives into the original data structure. The lower layer, Internet Protocol, addresses each packet so that it gets delivered to the correct remote system. Each routing device on the network, be it a hardware router or a server system performing routing functions, checks the destination address to see where to forward the message.

The TCP/IP protocol suite maps to a four-layer conceptual model, which parallels the seven-layer Open Systems Interconnect (OSI) protocol model described in the following list:

The four-layer conceptual model for the TCP/IP protocol suite is as follows:

IP version 4 (IPv4) addresses are made up of four 8-bit fields (octets)—32 bits total. There are five IPv4 address classes: A, B, C, D, and E.

IPv4 addresses consist of a network ID and a host ID. The network ID identifies the numeric network name of the physical network where the hosts exist. The host ID identifies the numeric network name of the individual TCP/IP host on a network. For example, in the Class A IP address 10.0.0.1, 10 represents the network ID and 0.0.1 represents the host ID. The numeric host ID must be unique on the internal network—that is, no two nodes on a network can have the same network ID and host ID. Using the previous example, only one host can be assigned the host ID of 0.0.1 on the given network.

A subnet mask is used to divide an entire TCP/IP address in an effort to define which part of the address is the network number and which part is the host system’s numeric identifier. The bits in a subnet mask are set consecutively from left to right. For example, the subnet mask 255.128.0.0 is valid because all eight bits are set in the first two octets and the first bit of the next octet is also set (11111111.10000000.00000000.00000000). The subnet mask 255.64.0.0 is not valid because it has a “missing” bit, which is not allowed (11111111.01000000. 00000000.00000000).

When assigning IP addresses, each host requires a subnet mask to determine which part of an IP address to use as the network ID and which to use as the host ID.

The default subnet masks for the three IP address classes are

For example, the default subnet mask for a Class C address is 255.255.255.0, which means the first three octets identify the network and the last octet indentifies the host.

The subnet mask is also used to determine whether the destination host is on the local subnet or a remote subnet. The subnet mask of the local host is compared against the IP address of the destination host and, through a process known as anding, it is determined whether the destination IP address is the local or a remote network. If the destination IP address within a packet is on a remote network, the packet is sent to the default gateway.

Basically, the number of 1’s in the binary address of the subnet mask are masked against the IP address to determine if the address is on the local network or a remote network. When the bits of the subnet mask are compared against the bits in the IP address, all combinations of 1’s and 0’s result in a value of 0, except for 1 and 1, which results in a value of 1.

Let’s take at an example of how this process works. The source host has an IP address of 192.168.0.10 and a subnet mask of 255.255.255.0. The destination host has an IP address of 192.168.20.2.

IP address 11000000 10101000 00000000 00001010 (192.168.0.10)

Subnet mask 11111111 11111111 11111111 00000000 (255.255.255.0)

Results 11000000 10101000 00000000 00000000

IP address 11000000 10101000 00010010 00000010 (192.168.20.20)

Subnet mask 11111111 11111111 11111111 00000000 (255.255.255.0)

Results 11000000 10101000 00010010 00000000

As you can see from the preceding example, the source IP address is anded against the subnet mask. The destination address is anded against the subnet mask assigned to the source host. If the results are not the same, the destination host is on a different network or subnet. Conversely, if the results are the same, it is determined that the destination host is on the local network.

The original IP definitions set five classes of IP addresses, from A through E. (A, B, and C are for general-purpose use, D is used for multicasting, and E is reserved.) These classes made it possible to use one portion of the 32-bit IP address scheme for the network address and the remaining portion for nodes on the network.

In the past, some networks needed more addresses for systems than the 254 a Class C address supplies. This was a major contribution to the shortage of IP addresses. Organizations often requested a Class B range that offered 65,534 available addresses rather than a few Class C ranges that might have suited their needs. The result was that many addresses within their allotted Class B blocks went unused.

However, Classless Inter-Domain Routing (CIDR) addressing is now used more often for IPv4 addressing schemes. It effectively “removes” the class from an address for the purpose of combining ranges, so it makes better use of the limited number of remaining available IPv4 addresses. A CIDR network address looks like this:

222.175.14.00/18

The network address is 222.175.14.00. The /18 specifies that the first 18 bits of the address are the network part of the address, which leaves the last 14 bits for the network hosts’ address.

Both Border Gateway Protocol (BGP) and OSPF support CIDR. Older gateway protocols, such as Exterior Gateway Protocol (EGP) and Routing Information Protocol version 1 (RIPv1), do not support CIDR. Because CIDR supports multiple subnet masks per subnet, it requires routers that support more advanced interior routing protocols, such as RIPv2 and OSPF.

Implementing subnets helps control network traffic and enables network administrators to create smaller collision domains. Every node on the same physical ethernet network sees all data packets sent out on the network, which results in multiple collisions and affects network performance. Routers or gateways separate networks into subnets. Subnet masks on each node allow nodes on the same subnetwork to continue communicating with one another and with the routers or gateways they use to send their messages.

Subnet masking enables you to identify the network ID and host (node) ID of an IP address. The following example is a default Class B subnet mask:

10110110.10100101.00110111.01100010 182.165.55.98
11111111.11111111.00000000.00000000 255.255.000.000
---------------------------------------------------
10110110.10100101.00000000.00000000 182.165.000.000
IP Address       : 182.165.55.98
Address Class    : B
Network Address  : 182.165.0.0

Subnet Address   : 182.165.48.0
Subnet Mask      : 255.255.240.0
Subnet bit mask  : 11111111.11111111.11110000.00000000
Subnet Bits      : 20
Host Bits        : 12
Possible Number of Subnets : 16
Hosts per Subnet : 4094

Selected Subnet  : 182.165.0.0/255.255.240.0
Usable Addresses : 4094
     Host range  : 182.165.0.1  to  182.165.15.254
     Broadcast   : 182.165.15.255

To subnet networks further, more bits can be added to the subnet mask for a class of addresses.

The following example is a Class B address using an additional bit subnet mask of 240. Notice that instead of having the single subnet and 65,534 hosts per subnet allowed under the default subnet mask, you can have up to 16 subnets with up to 4,094 hosts per subnet by using a subnet mask of 255.255.240.000 (Table 3.1 shows a sample IP addressing scheme):

10110110.10100101.00110111.01100010 182.165.55.98
11111111.11111111.11110000.00000000 255.255.240.000 Subnet Mask
--------------------------------------------------------
IP Address       : 182.165.55.98
Address Class    : B
Network Address  : 182.165.0.0

Subnet Address   : 182.165.48.0
Subnet Mask      : 255.255.240.0
Subnet bit mask  : 11111111.11111111.11110000.00000000
Subnet Bits      : 20
Host Bits        : 12
Possible Number of Subnets : 16
Hosts per Subnet : 4094

Selected Subnet  : 182.165.0.0/255.255.240.0
Usable Addresses : 4094
     Host range  : 182.165.0.1  to 182.165.15.254
     Broadcast   : 182.165.15.255

When you use standard subnet masks in classful IP addressing schemes, you can plan how many hosts you can support per subnet and how many subnets are available for use. Table 3.2 shows classful IP addressing schemes and uses 255.x.0.0 as the default mask for Class A addresses, 255.255.x.0 as the default mask for Class B class addresses, and 255.255.255.x as the mask for Class C addresses. In these classes, the X is the subnet mask variable in the table’s Subnet Mask column. The table identifies how many subnets ID are supported by each subnet mask and the maximum number of hosts per subnet.

IP addresses are organized into different address classes that define the number of bits out of the 32 that are used to identify the network and which are used to identify hosts on a network. By examining the address classes, you can also determine the number of networks and the number of hosts.

A number of well-known ports (0–1023) are used by different services on computers. For a single IP address on one system to offer all possible services to a network, each service must function on its own TCP or UDP port from that IP address.

You can find a helpful table at http://www.networksorcery.com that includes links to definitions and additional notes for some services. The following ports and associated protocols are the most important ones to remember for the certification exam:

Before you can successfully and effectively implement a TCP/IP network infrastructure, you have to identify your IP addressing requirements. Some of the things that you need to consider include

IP Address Assignment

IP addresses can be dynamic or static. With static IP addressing, a computer (or other device) always uses the same IP address. With dynamic addressing, the IP address changes.

There are several ways of configuring a host with an IP address. You can do so manually or automatically, using a service such as DHCP or Automatic Private IP Addressing (APIPA).

Manual IP Addressing

For manual IP address assignment, an administrator or similarly delegated person manually enters a static IP address and other information, such as the subnet mask and default gateway, DNS server, WINS server, and so forth.

Dynamic Host Configuration Protocol

DHCP dynamically assigns randomly available IP addresses from available scopes to DHCP clients. This allows administrators to automatically assign IP addresses to clients without actually having to set all the parameters (default gateway, DNS servers, and so on) for each system, as with manual IP address assignment.

The DHCP lease process begins over UDP ports 67 and 68 as a broadcast message from the client system. For DHCP clients to contact DHCP servers on remote networks successfully, the IP routers must be RFC 1542–compliant. These routers support forwarding DHCP broadcasts off the local subnet. If the routers are not compliant, a DHCP Relay Agent must be in use on that subnet.

The DHCP Relay Agent is available through the Routing and Remote Access MMC on Windows Server 2003 (see Figure 3.1). Systems configured in the role of a DHCP server should not be configured as DHCP Relay Agents because both services use UDP ports 67 and 68 and degrade each other’s services if they are installed together. On a single subnet, there is no practical need to do this because the DHCP server should simply respond to user requests on the subnet.

Figure 3.1. The first step in configuring the DHCP Relay Agent service in the Routing and Remote Access MMC.

Figure 3.2 shows the available routing protocols in the New Routing Protocol dialog box: DHCP Relay Agent, IGMP Router and Proxy, Open Shortest Path First (OSPF), and RIP Version 2 for Internet Protocol.

Figure 3.2. You can add routing protocols through the New Routing Protocol dialog box.

When a client first starts, it sends out a DHCPDISCOVER broadcast message to all addresses (255.255.255.255). The message contains the client’s hardware (MAC) address and hostname. (The client also sends this message when its original lease has expired and cannot be renewed.) All available DHCP servers configured to respond receive the DHCPDISCOVER broadcast and send a DHCPOFFER broadcast message back with the following information:

• The client’s hardware address

• An offered IP address

• Subnet mask

• Length of the lease

• A server identifier (the IP address of the offering DHCP server)

The DHCP client selects the IP address from the first offer it receives and responds with a DHCPREQUEST broadcast message that includes the IP address of the server whose offer was accepted. All the other DHCP servers then retract their lease offers and mark those addresses available for the next IP lease request.

The DHCP server whose lease was accepted responds with a DHCPACK broadcast message, which contains the valid lease period for that IP address and other configuration information outlined in the scope, such as router information (default gateway), subnet mask, and so forth. After the DHCP client receives this acknowledgment, TCP/IP is completely initialized, and the client can use the IP address for communication.

Automatic Private IP Addressing

When a DHCP client sends out the DHCPDISCOVER broadcast message, it waits 1 second for an offer. If the client does not receive a response from a DHCP server, it rebroadcasts the request three times at 9-, 13-, and 16-second intervals, with a random offset length of 0ms and 1000ms. If an offer is not received after the four requests, the client retries once every five minutes.

Beginning with Windows 98, DHCP clients can configure themselves by using APIPA and the DHCP client service. After the four attempts to receive an IP address have failed, the DHCP client auto-configures its IP address and subnet mask using the reserved Class B network address 169.254.0.0 and the subnet mask 255.255.0.0. No default gateway is used, so systems that use APIPA are not routable.

The DHCP client tests for an address conflict to make sure that the IP address it has chosen is not already in use on the network. To do this, it broadcasts its selection from the range to the local subnet. If a conflict is found, the client selects another IP address and continues this process up to 10 attempts.

After the DHCP client makes sure that the address it has chosen is not in conflict with another system on the subnet, it configures its network interface with the IP address. The client then continues to check for a response from the DHCP server every five minutes. If a DHCP server becomes available, the client drops its APIPA settings and uses the address the DHCP server offers at that time.

So far you have learned about subnetting and configuring network systems in address class ranges in an effort to optimize TCP/IP configuration, but some other points should be mentioned as well. You need to be sure, above all else, that you understand your network configuration and behavior. Although you can take a few steps to fine-tune TCP/IP traffic, network topology plays a big role.

For TCP/IP specifically, there is the TCP/IP Receive Window Size setting, which is the buffer threshold for inbound packets. The default setting for ethernet networks is 17,520 bytes; when this threshold is met, the receiving system sends out an acknowledgement that the data has been received. This process of sending and acknowledging during a data transmission session repeats every 17,520 bytes until all data has been transmitted. As an administrator, you can adjust this acknowledgement setting to optimize transmissions.

Other settings on the network’s Physical and Data Link layers are beyond normal administrative control. Maximum Transmission Units (MTUs), for example, are based on the type of network that is installed. For example, 16Mbps token-ring networks have an MTU setting of 17,914 bytes; 4Mbps token-ring networks have an MTU setting of 4,464 bytes. Ethernet deployments are limited to a 1,500 byte MTU setting. As an analogy, think of the MTU as an envelope in which data is carried.

The Maximum Segment Size (MSS) setting determines the largest segment that can be carried in the MTU. (Think of it as the pages of a letter in an envelope.) This setting also varies depending on the framework. Obviously, the MSS for token-ring networks will be larger than the MSS for ethernet networks.

Networks must consider application requirements when implementing certain services and protocols to optimize bandwidth. Quality of service (QoS) can also be implemented on networks to optimize bandwidth. The main issue on most networks is that all the associated networking equipment needs to support the Resource Reservation Protocol (RSVP). Networks also have certain application requirements to consider, such as the following:

The PING command can be used to test network connectivity from a local system by sending an ICMP message to a remote host or gateway. On external networks such as the Internet, the use of PING might be somewhat limited, depending on how routers and firewalls are configured; many do not allow ICMP traffic. If the remote host receives the message, it responds with a reply message. PING notes the IP address, the number of bytes in the message, how long it took to reply (in milliseconds [ms]), and the length of Time –to Live (TTL) in seconds and shows any packet loss in terms of percentages, as shown here:

D:>ping 192.168.1.225
Pinging 192.168.1.225 with 32 bytes of data:
Reply from 192.168.1.225: bytes=32 time<10ms TTL=128
Reply from 192.168.1.225: bytes=32 time<10ms TTL=128
Reply from 192.168.1.225: bytes=32 time<10ms TTL=128
Reply from 192.168.1.225: bytes=32 time<10ms TTL=128
Ping statistics for 192.168.1.225:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milliseconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms
Usage: ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS]
[-r count] [-s count] [[-j host-list] | [-k host-list]]
[-w timeout] target_name

The following list describes the switches available for use with PING:

The ARP command displays and modifies the IP-to-physical address translation tables used by Address Resolution Protocol (ARP), as shown here:

ARP -s inet_addr eth_addr [if_addr]
ARP -d inet_addr [if_addr]
ARP -a [inet_addr] [-N if_addr]

The following list describes the switches available for use with ARP:

For example, the following code adds a static entry:

> arp -s 157.55.85.212 00-aa-00-62-c6-09 ....

The following displays the ARP table:

> arp -a

IPCONFIG is a command-line tool for getting basic IP configuration information, including the IP address, subnet mask, and default gateway. The IPCONFIG /all switch produces a detailed configuration report for all interfaces on a system, including any configured remote access adapters, as shown here:

ipconfig [/? | /all | /renew [adapter] | /release [adapter]
| /flushdns | /displaydns | /registerdns | /showclassid adapter
| /setclassid adapter [classid] ]

The following list describes the switches available for use with IPCONFIG:

The default is to display only the IP address, subnet mask, and default gateway for each adapter bound to TCP/IP. For /release and /renew, if no adapter name is specified, the IP address leases for all adapters bound to TCP/IP are released or renewed.

NetBT Statistics (Nbtstat.exe) is a command-line tool that can be used to view and troubleshoot network NetBIOS over TCP/IP (NetBT) name resolution. It displays protocol statistics and current TCP/IP connections that are using NetBT.

Nbtstat resolves NetBIOS names to IP addresses by using several options for NetBIOS name resolution, including local cache lookup, WINS server query, broadcast, LMHOSTS and HOSTS file lookup, and DNS server query. It also displays protocol statistics and current TCP/IP connections using Nbtstat.

NBTSTAT [ [-a RemoteName] [-A IP address] [-c] [-n] [-r] [-R] [-RR] [-s] [-S] [interval] ]

The following list describes the switches available for use with NBTSTAT:

NETSTAT (Netstat.exe) is a command-line tool that displays TCP/IP statistics and active connections to and from the local system. It can also display all connections and listening ports and has an option to display the number of bytes sent and received and any network packets dropped (if applicable).

NETSTAT [-a] [-e] [-n] [-o] [-s] [-p protocol] [-r] [interval]

The following list describes the switches available for use with NETSTAT:

The ROUTE command-line tool displays the current IP routing table for the local system, and it can be used to add or delete IP routes and to add persistent routes.

ROUTE [-f] [-p] [command] [destination] [MASK netmask] [gateway] [METRIC metric] [IF interface]

The following list describes the switches available for use with ROUTE:

The following list describes the commands available for use with ROUTE:

Names used for the destination command are looked up in the NETWORKS file on the local system. Names used for the gateway command are looked up in the HOSTS file on the local system. If the command is PRINT or DELETE, the destination or gateway can be a wildcard (*), or the gateway entry can be left blank. Invalid MASK entries, such as (DEST & MASK) != DEST, generate an error.

HOSTNAME is a command-line tool for showing the local computer’s hostname. It can be used for authentication purposes by the Remote Copy Protocol (RCP), Remote Shell (RSH), and Remote Execution (REXEC) tools.

TRACERT is sometimes used to verify that IP addressing has been correctly configured on a client. It basically shows the route taken to reach a remote system.

tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] target_name

Here is a list of available switches for the TRACERT command:

Like TRACERT, PATHPING shows the route taken to reach a remote system, but PATHPING does so with more detail and offers more functionality.

pathping [-g host-list] [-h maximum_hops]
[-i address] [-n] [-p period] [-q num_queries]
[-w timeout] [-P] [-R] [-T] [-4] [-6] target_name

Here is a list of available switches for the PATHPING command:

FTP is used to transfer files from system to system over TCP ports 20 and 21 (by default), but it can also help you diagnose problems on your TCP/IP network. By using Internet Explorer with FTP, users experience a Windows Explorer-type of GUI environment for the FTP file transfer by having features such as file and folder views, drag-and-drop, and copy-and-paste available.

The command-line FTP allows for more functionality. FTP is considered a connected session that uses TCP. FTP commands are as follows: !, delete, literal, prompt, send ?, debug, ls, put, status append, dir, mdelete, pwd, trace ascii, disconnect, mdir, quit, type, bell, get, mget, quote, user, binary, glob, mkdir, recv, verbose, bye, hash, mls, remotehelp, cd, help, mput, rename, close, lcd, open, and rmdir. Here is an example of the syntax:

FTP [-v] [-d] [-i] [-n] [-g] [-s:filename] [-a] [-w:windowsize] [-A] [host]

The following list explains the options you can use with the FTP command:

Trivial File Transfer Protocol allows for connectionless transfer of files to and from systems using UDP. Although TFTP is limited in functionality, there are still some command-line switches that can be used to tailor its performance:

TFTP [-i] host [GET | PUT] source [destination]

Definitions for these switches are as follows:

Telnet is a command-line terminal emulation program that enables an administrator to perform commands on a remote computer from a command window on a local system. Here is an example of the syntax:

telnet [-a] [-e char] [-f filename] [-l user] [-t term] [host] [port]

Definitions for TELNET switches are as follows:

Remote Copy Protocol (RCP) uses TCP to copy files to and from systems running the RCP service. It can be scripted in a batch file and does not require a password. The remote host must be running the Remote Shell Daemon (RSHD) service, and the user’s username must be configured in the remote host’s .rhosts file. Microsoft’s implementation of TCP/IP includes the RCP client software but not RSHD services. RCP is one of the r-commands available on all UNIX systems.

RCP [-a | -b] [-h] [-r] [host][.user:]source [host][.user:] pathdestination

The following list explains the options you can use with the RCP command:

Remote Shell (RSH) enables clients to run commands directly on remote hosts running the RSH service without having to log on to the remote host. Microsoft’s implementation of TCP/IP includes the RSH client software but not the RSH service. If a user on a computer running in a Windows domain tries to use RSH to run a command on a remote UNIX server running RSH, the domain controller is required by the RSH client to resolve the user’s username. RSH is one of the UNIX r commands that is available on all UNIX systems.

Remote Execution (REXEC) runs commands on remote hosts running the REXEC service and authenticates the username on the remote host before executing the specified command.

REXEC host [-l username] [-n] command

The following list defines options to use with the REXEC command:

Before you install the DHCP service, you need to identify where on the network the DHCP servers will be placed. Consider the following points when determining where you should place the DHCP servers:

One of the ways that you can secure a DHCP implementation is to implement only Active Directory authorization. This would require all DHCP servers to be running Windows 2000 or later and be a member of an Active Directory domain. That way, when a DHCP server starts, it requests the server authorization list. If the DHCP server is not in the list of authorized servers, the DHCP service will fail to start. In order to authorize a DHCP server, your user account must be a member of the Enterprise Admins group.

Another way that you can secure your DHCP servers is to follow the principal of least privilege. Windows Server 2003 includes two built groups called the DHCP Users and the DHCP Administrators group. Members of the DHCP Users group have read-only access to the DHCP server while DHCP Administrators have full access. By placing users in the DHCP Users group, you can prevent unauthorized changes from being made to the server.

Each DHCP scope is configured with a lease duration. This specifies how long a DHCP client can use an IP address before it must be renewed by a DHCP server. By default, this value is set to eight days. However, you might want to change this depending on the number of IP addresses available as compared to the number of DHCP clients.

The lease duration can be customized to meet the requirements of your network. If the number of IP addresses exceeds the number of DHCP clients on the network, you can configure a longer lease duration. However, if the number of IP addresses available in the scope is comparable to the number of DHCP-enabled clients, you should configure a shorter lease duration. Also, if your network consists of a number of mobile users who move between subnets, consider creating a shorter lease time. By shortening the lease duration, you might also see a slight increase in network traffic because IP addresses are renewed at a more frequent interval.

There are two types of DNS lookup queries: forward and reverse. A forward lookup query resolves a DNS name to an IP address and is the most common DNS query. When you perform a forward lookup, such as entering http://www.zandri.net into a browser, your client looks up the website’s IP address with the assistance of a DNS server behind the scenes. A reverse lookup query resolves an IP address to a name. A DNS name server can resolve a query only for a zone for which it has authority. When DNS servers receive a name resolution request, they attempt to locate the requested information in their own cache and local database.

DNS servers cache all external name resolution data for a specific interval called Time to Live (TTL). The default TTL for DNS resolution is one hour; for WINS lookups via DNS, the default is 15 minutes.

DNS administrators can adjust the default settings for the DNS cache by going to the zone’s Properties dialog box and selecting the Start of Authority (SOA) tab. To change the 15-minute default setting for WINS, select the WINS tab and click the Advanced Settings button.

Configuring a shorter TTL interval ensures that DNS and WINS information is more up to date, but it also increases the load on your DNS server, your WINS server, and your network. You can increase the interval when network resources are a higher premium than “freshness” of name resolution.

Two types of queries can be performed in DNS: iterative and recursive. An iterative query happens when a client makes a DNS resolution query to a DNS server, and the server returns the best answer it can provide based on its local cache or stored zone data. If the server resolving the iterative query does not have an exact match for the name request, it provides a pointer to an authoritative server in another level of the domain namespace. The client system then queries that server, and continues this process until it locates a server that is authoritative for the requested name or until an error is returned, such as “name not found,” or a timeout condition is met.

A recursive query happened when a client makes a DNS resolution query to a DNS server, and the server assumes the full workload and responsibility for providing a complete answer to the query. If the server cannot resolve the query from its own database, it performs separate iterative queries to other servers (on behalf of the client) to assist in resolving the recursive query. The server continues this process until it locates a server that is authoritative for the requested name or until an error is returned, such as “name not found,” or a timeout condition is met.

In most cases, client computers send recursive queries to DNS servers, and usually the DNS server is set up to make iterative queries to supply an answer to the client. In the following query example, a client computer makes a request to a DNS server to resolve the web address http://www.zandri.net:

When DNS clients make a request for a reverse DNS lookup, they are effectively making a request to resolve a hostname of a known IP address. In the standard DNS namespace, there is no connection between hostnames and IP addresses, and only a thorough search of all domains allows for reverse resolution.

Often, DNS servers are called on to resolve the same query multiple times within a short time. As an example, if a number of AOL users (arguably the largest ISP in the world) get an email reporting that new articles have been posted to www.2000trainers.com and immediately go to this site to read the new articles, the AOL DNS servers must continually recall the resolved address many times within a short period and use their local cache to do so.

DNS servers cache resolved addresses for a specific duration, specified as the TTL in the returned data. The DNS server administrator of the zone containing the data decides on the TTL setting. Therefore, the administrator of the 2000trainers.com domain and the DNS servers for that domain sets the TTL value. This value tells the resolving AOL DNS servers how long to hold that information in their cache. The lower the TTL, the “fresher” the resolution data is on the resolving AOL DNS servers.

After a DNS server caches data, it decreases the TTL from its original value so that it knows when to flush data from its cache. If another resolution query comes to the DNS server for the URL, the cached data is used and the TTL is reset (in most cases) to the original TTL. (The only time the TTL value isn’t reset to its original value is if the administrator sets a different TTL.)

The in-addr.arpa domain was created to avoid query overloads on DNS servers. System names in the in-addr.arpa domain are listed by their respective IP addresses. Because IP addresses are designed so that they become more significant as you move from left to right in the address, and domain names get less significant from left to right, IP addresses in the in-addr.arpa domain are listed in reverse order.

Pointer (PTR) records are added to IP addresses and corresponding hostnames. To perform a successful reverse lookup of an IP address, such as 121.41.113.10, the DNS server performing the query looks for a PTR record for 10.113.41.121.inaddr.arpa, which has the hostname and IP address 121.41.113.10.

Before you can effectively implement DNS, you need to take some time to plan the infrastructure. This includes determining where your DNS servers are placed, how many DNS servers are required, what type of DNS server role best meets your requirements, and so on. The following section looks at some of the important topics that need to be considered when implementing DNS.

A DNS zone is a contiguous portion of the domain namespace for which a DNS server has authority to resolve DNS queries. DNS namespaces are almost always divided into zones, which store name information about one or more DNS domains or portions of a DNS domain.

In the Windows Server 2003 Active Directory domain structure, there are three different zone types: Standard Primary zones, Standard Secondary zones, and stub zones.

Active Directory Integrated Zones

Active Directory Integrated zones store DNS zone information in the Active Directory database rather than a text file. The Active Directory Integrated option is not available in the Change Zone Type dialog box unless the DNS server is also a domain controller. If the DNS server is not configured as a domain controller in your environment, the option to create the zone as Active Directory Integrated is grayed out during the creation of the zone (see Figure 3.3).

Figure 3.3. The option to create the DNS zone as Active Directory Integrated is grayed out because the server is not installed in the role of a domain controller.

Zone Data Replication

When replication is considered for Standard zone types, Primary zones are the only read/write copy of the DNS zone database, and only one Standard Primary zone exists. You can replicate the zone to any number of Standard Secondary DNS zones as needed, and these zones are read-only copies of the zone information. The only place where updates to the DNS zone database can occur is on the Standard Primary copy of the zone. The changes recorded there are replicated incrementally by incremental zone transfer (IXFR) or by transferring the entire zone database via full zone transfer (AXFR).

Although a Standard Primary DNS server with multiple Standard Secondary servers is fault tolerant and load-balanced to a degree, the loss of the Standard Primary DNS server prevents updates to the DNS database until an administrator can intervene. The administrator needs to repair the downed Standard Primary DNS server or promote a Standard Secondary DNS server to a Standard Primary DNS server. Name resolution still occurs for the first 24 hours with only the Standard Secondary servers functioning then all the records on the secondary servers will expire.

DNS zone transfers occur on a preconfigured basis, which is set to 15 minutes by default. This preconfigured basis is called a refresh interval, and its setting is found in the Start of Authority (SOA) tab of a zone’s Properties dialog box. When the refresh interval expires, DNS servers request a copy of the current SOA record for their zone.

The DNS server then compares the serial number of the source DNS server’s current SOA record with the serial number in its own local SOA record. If the responding DNS serial number is higher, the DNS server requests a zone transfer from the Primary DNS server. If a network issue or some other error prevents the zone transfer, the requesting DNS server retries the request for a zone transfer at a preconfigured interval, which is called a retry interval and is set to 10 minutes by default.

If the failure is persistent and a zone transfer cannot be completed, the requesting DNS server quits making requests for a zone transfer after the expire interval (default setting is one day) has been exceeded. Active Directory–integrated DNS zones store zone information in Active Directory and are multimaster in nature, which enables administrators to configure systems so that updates to the DNS database can occur on any domain controller hosting the DNS zone. This type of setup is fully load balanced and fault tolerant; the loss of any single DNS server does not affect DNS name resolution or updates to the DNS database because any DNS server can receive updates.

Because Active Directory–integrated zones store zone information in Active Directory, the DNS information is replicated along with other Active Directory data. This configuration also enables administrators to establish permissions using Access Control Lists (ACLs) to allow only authenticated systems, groups, or users to make updates to the DNS zone.

Note

ACL permissions to update the DNS zone are made in the DNS zone container within Active Directory and can be assigned for the entire DNS zone or for individual resource records within the zone. They can also be assigned to systems, groups, or users.

Active Directory–integrated zones can be configured for the following types of replication (see Figure 3.4):

• Replication can be configured so that all DNS servers in the Active Directory forest can replicate DNS zone data to all DNS servers running on domain controllers within the Active Directory forest. (For the most part, this is the Active Directory–integrated DNS zone replication in Windows 2000 Server.)

• Replication can be configured so that all DNS servers in the Active Directory domain can replicate DNS zone data to all DNS servers running on domain controllers in the local domain. This is the default Active Directory–integrated DNS zone replication setup in Windows Server 2003.

• Replication can be configured so that all domain controllers in the Active Directory domain can replicate DNS zone data to all domain controllers in the Active Directory domain. You can use this setting if you need Windows 2000 DNS servers to load a specific Active Directory zone.

• Replication can be configured so that all domain controllers in a specified application directory partition can replicate DNS zone data according to the replication scope of the specified application directory partition. For a zone to be stored in the specified application directory partition, the DNS server hosting the zone must be enlisted in the specified application directory partition.

Figure 3.4. There are three options for changing the scope of DNS replication in Active Directory.

Note

Active Directory–integrated DNS zone data replicated to application directory partitions is not replicated to the forest’s Global Catalog. The domain controller containing the Global Catalog can also host application directory partitions, but it does not replicate this data to its Global Catalog.

Active Directory–integrated DNS zone data replicated to domain partitions is replicated to all domain controllers in its Active Directory domain, and a portion of this data is stored in the Global Catalog. This setting is used to support Windows 2000.

Tip

The default configuration of the Windows Server 2003 DNS service allows zone transfers only to servers listed in a zone’s Name Server (NS) resource records. Administrators can increase the security of the zone transfer process by changing the setting to allow zone transfers to the specified IP addresses of those servers only.

If DNS zone transfers must take place over a public network, such as the Internet, you can protect replication data by using VPNs and IPSec encryption. Using Active Directory–integrated zones exclusively for replicating DNS zone data adds another layer of security to zone transfers.

DNS zone files contain the name resolution data for a zone and include resource records with database entries containing various attributes of network systems. The most common resource records are discussed in the following sections.

server1        IN A 121.41.113.10
localhost      IN A 127.0.0.1

www           CNAME Server1
ftp           CNAME Server1

@ IN NS server2.zandri.net

10.113.41.121.in-addr.arpa. IN PTR Server1.Zandri.net.

@ IN SOA server1.zandri.net. (
                               1        ; serial number
                               7200   ; refresh [2h]
                               900     ; retry [15m]
                               86400 ; expire [1d]
                               7200 ) ; min TTL [2h]

SRV (Service) Records

Sometimes referred to as Service Location records, SRV (Service) records contain registered services within the zone so that clients can locate these services by using DNS. SRV records are mainly used to identify services in Active Directory.

The CACHE.DNS file contains the records of the root DNS servers. The cache file is basically the same on all name servers and must be present for a DNS server to handle a query outside its zone. The file provided by default with the Windows 2003 DNS server has current records for all the root servers on the Internet. This file is stored in the %SystemRoot%System32Dns folder when you install DNS on your Windows Server 2003 server.

If you are running DNS for internal use, not for connections for forwarding to the Internet, the CACHE.DNS file should be replaced to contain the name server’s authoritative domains for the root of the private network. In certain situations, you replace the CACHE.DNS file in the %SystemRoot%System32Dns folder, and it does not update the root hints listed in the DNS Manager. This can happen because the DNS server is a domain controller configured to load zone data on startup from Active Directory and the Registry. If the root hints specified in Active Directory have been deleted, modified, incorrectly entered, or damaged, this behavior occurs. There is more information on CACHE.DNS in “Need To Know More?” at the end of this chapter.

Root hints consist of a list of resource records that the DNS service can use to locate other DNS servers that are authoritative for the root of the DNS domain namespace tree in your enterprise. For DNS servers that have been deployed to resolve names external to your environment, root hints host addresses for the Internet root servers. When a new server is added or removed from your DNS structure, administrators might need to update the root hints list.

For a current copy of the root hints file for Internet root servers, you can download a copy of the named.root file from ftp://ftp.internic.net/domain/. Figure 3.5 shows the DNS files you can download from InterNIC for DNS use.

Figure 3.5. You can download DNS files from InterNIC to use with DNS.

You must take a number of considerations into account when you are planning your DNS namespace design. When setting up DNS in your environment, you should register a unique parent (second-level) DNS domain name that can be used for hosting your organization on the Internet, such as “zandri” in zandri.net or “2000trainers” in 2000trainers.com. Even if you are not currently connected to the Internet via your proposed domain name or are not considering it in the near future, you should still make an effort to register your DNS domain name because you can’t accurately predict what course your company might take in the future. If your company does decide to establish an Internet presence, you might find that the name you are currently using is registered to someone else. In that case, not only will you be unable to use it, but you will have to redesign your entire DNS deployment.

Also, you need to consider to which top-level domain name you will tie your second-level name. Table 3.3 shows the original top-level domain names currently available on the Internet. Keep in mind that 2 letter country codes and many new top level domain names are not available.

After your parent domain name is in place, you can configure other child names as needed. For example, forums.2000trainers.com can be created as a child of 2000trainers.com for resources the forums section of 2000trainers uses, and additional child domains could be established as needed. The domain might be broken down by geographical region, in which us.forums.2000trainers.com is one child domain and canada.forums.2000trainers.com is another.

Active Directory domains often correspond directly with DNS names. When choosing DNS names to use for Active Directory, starting with the registered DNS domain name suffix your organization has reserved for use on the Internet is best. Effectively, it means that internal and external namespaces are the same. For example, Zandri.net is what you can reach from the Internet and the intranet. The main benefit is that users access one domain name when they need to find resources, regardless of where those resources exist.

This common naming scheme causes a certain amount of additional administration to make certain that appropriate DNS and SRV records are stored on internal and external DNS servers. You could also use a delegated namespace internally, so that 2000trainers.com is reachable from the Internet and the Active Directory namespace is set up with something along the lines of corp.2000trainers.com.

This configuration offers better security because users and computers outside the organization cannot access the private DNS namespace from standard Internet connections with the proper segmentation of DNS zones. There is also less administrative overhead for DNS and SRV records because the zones for both namespaces are independent of each other. This setup could cause some confusion for internal users, however, if they need to access certain network resources from the external domain.

Optionally, the entire internal Active Directory namespace can be totally separate from the external namespace, so that zandri.net is used from the Internet and mcmcse.com is used internally. This configuration also offers better security because users and computers outside the organization cannot access the private DNS namespace from standard Internet connections with the proper segmentation of DNS zones. There is also less administrative overhead for DNS and SRV records because the zones for both namespaces are independent of each other. This setup could also cause confusion for internal users, however, if they need to access certain network resources from the external domain.

Delegation is the process of designating a portion of the DNS namespace for another zone. It gives administrators a way of dividing a namespace among multiple zones. For example, an administrator might place the bayside.net domain in one zone and place the sales.bayside.net subdomain in another delegated zone. The bayside.net zone would contain all the records for the sales subdomain if it is not delegated. Through delegating, the bayside.net zone contains only information for bayside.net, as well as records to the authoritative name servers for the sales.bayside.net zone. The host entries for any machines in sales.bayside.net are contained only on the delegated server.

In any case, when deciding whether to delegate, keep the following points in mind:

Administrators can optimize DNS servers in the enterprise by disabling local subnet prioritization and round-robin rotation. Local subnet prioritization is used so that clients on the same subnet as the available DNS server, based on IP address location, have priority over other DNS clients. Round-robin rotation of available DNS servers provides network load balancing. Disabling either or both settings reduces and balances client response time, for the most part, across the entire enterprise. Both settings are enabled by default.

Other DNS configurations can be modified from their default settings in an effort to tailor preferences to a locale’s specific needs. To adjust these settings, right-click the DNS server in the DNS MMC, choose Properties, and select the Advanced tab of the Properties dialog box. Table 3.4 shows the properties that can be configured and the default settings.

You can configure DHCP servers in your enterprise to dynamically update DNS when the DHCP server assigns a DHCP client computer IP information, or you can allow clients to dynamically update DNS.

DNS clients running Windows 2000, Windows XP, and Windows Server 2003 operating systems can dynamically update DNS on startup. When DNS clients are allowed to update DNS, they connect to the DNS server on startup and automatically register the appropriate client information, such as the system IP address and the fully qualified domain name (FQDN), with the DNS server, regardless of whether their IP addresses are entered manually or assigned via DHCP.

To have clients dynamically update DNS, in the Network dialog box, select the client’s active network connection, and choose Properties. Select Internet Protocol (TCP/IP), and click the Properties button. In the General tab, click the Advanced button to open the Advanced TCP/IP Settings dialog box, and then select the DNS tab (see Figure 3.6).

Figure 3.6. The Register this connection’s addresses in DNS check box is enabled at the bottom of the Advanced TCP/IP Settings dialog box.

DNS dynamic update is enabled by default. You can configure additional dynamic update settings with the DHCP console. To do this, right-click the DHCP server in the left pane and choose Properties. In the DNS tab (see Figure 3.7), select the Enable DNS dynamic updates according to the settings below check box. Then choose whether to allow the DHCP server to make the updates or to override client settings and always perform updates.

Figure 3.7. The Always dynamically update DNS A and PTR records option has been set.

You can also set the DHCP server to update A and PTR records of clients that do not make any dynamic update requests, such as Windows NT 4 systems. On the DNS server, you specify the DHCP server as the only computer authorized to update DNS entries.

If you use multiple Windows Server 2003 DHCP servers on your network and configure your zones to allow secure dynamic updates only, you need to add your DHCP servers to the built-in DnsUpdateProxyGroup to grant all your DHCP servers secure rights to perform updates for your DHCP clients. The default Discretionary Access Control List (DACL) entries on the DNS zones stored in Active Directory are as follows:

In most cases, especially in larger environments, multiple WINS servers are running. Some clients might be configured to use one WINS server, and other sets of clients might be configured to use another. This causes a problem if a client using WINS1 needs to resolve the name of a system that registered on WINS2. Convergence time is the time it takes to replicate a new entry in a WINS database to all the other WINS servers in the environment.

When planning placement and replication for WINS servers, you must decide on an acceptable convergence time for your network. Replication is used to synchronize WINS databases across the different WINS servers.

WINS servers are configured to sync with replication partners. Those partner WINS servers can be configured as pull partners, push partners, or a combination push/pull partner. Pull partners pull database entries from their WINS replica partners at a predetermined time. This means that no matter how many (or how few) changes have been made to the WINS database, at the time of pull replication, the server gets the updates. Push partners work off a quota number. When a WINS server has accrued a predetermined number of updates to its database, it pushes those changes out to its replication partners. In other words, push partners send updates out as soon as they have enough accumulated database updates, regardless of how long it has been since the last updates were sent.

There are issues with both designs. Pull partners, which might be configured to get databases only once every hour, are not properly updated during high-volume registration hours, such as the beginning of the workday. Push partners, which might be configured to replicate only when they have 300 new records, do nothing if the count stops at 153. The solution is to set up push/pull partners. These WINS servers are normally paired up, or if there are enough of them, configured in a hub and spoke setup to push and pull their changes among each other, thus solving both problems mentioned previously.