Section 8.2. Planning, Implementing, and Maintaining a Network Infrastructure


8.2. Planning, Implementing, and Maintaining a Network Infrastructure

Administrators often have to fill multiple roles in the organization. To be successful in their role as network designers, administrators must have a strong understanding of network infrastructure planning and implementation. Network infrastructure planning requires developing:

  • A Network topology strategy

  • A TCP/IP addressing strategy

  • An Internet connectivity strategy

  • A name resolution strategy

When you have a sound strategy for these four areas of network infrastructure, you can confidently implement your organization's network infrastructure.

8.2.1. Planning and Modifying a Network Topology

Before you can create a strategy for your organization's network topology, you must first understand what is meant by the term "network infrastructure." Knowing this, you can then identify the network protocols to be used and plan the placement of physical components.

8.2.1.1. Understanding network infrastructure

The term "network infrastructure" encompasses everything required to provide networking, connectivity, security, routing, and management on a network. Network infrastructure has physical and logical components:

  • A network's physical structure is the physical design that defines its topology and the hardware components of which it is comprised. Common hardware components used on a network include cabling, routers, switches, workstations, and servers.

  • A network's logical structure is the logical design that defines the abstract architecture required for communications and the software that connects, manages, and secures hosts on the network. Common abstract components include networking protocols (such as TCP/IP) and security technologies (such as IPSec). The Windows operating system provides the required software components.

Planning your organization's network infrastructure is a complex task, whether you are implementing the initial network topology or modifying the network to meet current requirements. During planning, you must select the hardware and software components required to implement the desired network infrastructure, taking into account the requirements of managers, users, and organizational policies. If your organization doesn't have specific security policies, these policies should be developed first, as discussed earlier in this chapter in the section "Planning and Implementing Server Roles and Server Security."

You must identify all required resources as part of your planning, prior to implementation. Implementing your network infrastructure plan typically requires the help of and coordination with multiple departments within the organization. You may also need to hire outside contractors to complete portions of the implementation, such as network cabling.


Tip: Exam 70-293 doesn't test your coordination and resource allocation skills. Instead, the exam focuses on your ability to select the appropriate protocols, operating systems, applications, and security configurations.

Once you've implemented the network infrastructure plan, you'll need to maintain the network by monitoring the infrastructure, troubleshooting as necessary and updating the infrastructure when required. Monitoring the network includes reviewing logs, testing components, and analyzing network traffic. Troubleshooting involves diagnosing and resolving problems that occur during day-to-day operations of the network. As requirements change or network usage change, you may need to modify or update the network infrastructure to ensure performance and security requirements are met.

8.2.1.2. Identifying network protocols to be used

The Open Systems Interconnection (OSI) reference model defines the functions that are implemented in various networking protocols. The model has seven layers:

  • Application

  • Presentation

  • Session

  • Transport

  • Network

  • Data-link

  • Physical

Specific functions are defined for each of the seven layers defined from the lowest level (the physical layer) to the top level (the application layer). The critical layer for network communications is the data-link layer, which defines the interface between the network medium and the software running on a hardware device, such as a computer or router. The data-link layer is responsible for:


Packet addressing

Allows hardware devices to direct traffic to specific destinations on networks


Media access control

Allows multiple computers to share a single network medium


Data encapsulation

Allows data to be formatted as data frames for transmission

The data-link layer has two sublayers:


Logical link control (LLC) sublayer

Controls frame synchronizations, flow control, and error checking


Media access control (MAC) sublayer

Controls the transmission of data packets from one network interface card (NIC) to another across a network medium

In the role of network designer, you must choose the data-link layer protocol to use, such as Ethernet or Token Ring, and the protocol suite, such as TCP/IP or IPX, to implement. Because of the way the OSI model works, the data-link layer protocol encompasses the physical and data-link layers in its functions. The protocol suite implements the functions of the network and transport layers. The session, presentation, and application layer functions are provided by a protocol in the protocol suite, by a separate application-layer protocol, or both.

Few current networks use Internet Package Exchange (IPX) or NetBIOS Extended User Interface (NetBEUI) as their data-link protocols. Most current networks use Transmission Control Protocol/Internet Protocol (TCP/IP). IP operates at the network layer. TCP operates at the transport layer. There is an additional transport layer protocol included in the TCP/IP protocol suite called User Datagram Protocol (UDP). TCP and UDP are very different, as described next.


TCP:

  • Is a connection-oriented protocol, which ensures guaranteed delivery

  • Relies on specific connections being established between two hardware devices prior to communicating

  • Uses acknowledgements to ensure data is received


UDP:

  • Is a connectionless protocol

  • Allows two hardware devices to communicate without first establishing a connection

  • Doesn't use acknowledgments, which reduces overhead but introduces the possibility of data loss

TCP should be used when reliable communications are required and when large amounts of data needs to be transmitted. UDP should be used when reliability of communications is not a requirement and for brief exchanges of data, such as a request or acknowledgement.

Most TCP/IP communications use IP at the network layer and either TCP or UDP at the transport layer. To transmit data, IP uses datagrams. A datagram includes the address of the sender and the recipient so that it can be routed to the intended recipient and so that the recipient knows from where the datagram originated.

When selecting the data-link layer protocol to use, you need to consider many criteria, including the physical distance between hardware devices and the required transmission speed. The media type you choose largely determines how far apart computers on the network can be and the supported transmission speeds. Although there are many possible media types, most current local area networks use one of three media types or a combination of these media types:


Unshielded Twisted Pair (UTP)

Consists of four pairs of wires, each twisted together and contained inside protective shielding. Shielding protects cables from electromagnetic interface but doesn't eliminate the need to locate cables away from possible sources of electromagnetic interface.


Fiber Optic

Consists of a strand of plastic or glass that carries signals in the form of light pulses. Using light pulses ensures that fiber optic cables are not affected by electromagnetic interference.


Wireless

Uses wireless broadcasting and wireless transceivers instead of physical cabling. Because wireless signals are broadcast in the air, wireless signals are subject to a wide variety of environmental factors.

Each type of UTP cabling available has a category rating, which is an indicator of supported transmission speeds. With UTP cabling, a computer's network interface card uses an RJ-45 jack into which cables are connected. The two most commonly used categories are Category 3 (Cat 3) and Category 5 (Cat 5). Both categories support the Ethernet and Token Ring data-link layer protocols. The most commonly used data-link protocol is Ethernet.

Fiber optic cabling can use the same topology and data-link layer protocols as UTP cabling. Fiber optic cables use light pulses and are not affected by electromagnetic interference. With fiber optic cabling, a computer's network interface card uses a fiber optic connector into which cables are connected. Several types of fiber optic cables are available, including both single mode and multimode varieties.

Wireless networking uses wireless network adapters and wireless access points. Computer's configured with wireless network adapters transmit signals to wireless access points. Typically, the wireless access points, or base stations, are connected directly to the organization's network.

8.2.1.3. Planning the physical placement of network resources

Install UTP cabling using a star topology in which each workstation or server is connected to a central hub. Hubs can in turn be connected to each other to create a large network. On an Ethernet network using UTP cabling, the distance between workstations and hubs can be no more than 100 meters.

Ethernet has specific limitations for networks that you should be aware of:

  • On a standard Ethernet running at 10 megabits per second, you can connect computers together through no more than 4 hubs on a single local area network (LAN). Another way of saying this is that a single network can have no more than five network segments connected by four repeaters.

  • On a standard Ethernet running at 100 megabits per second, you can connect computers together through no more than 2 hubs on a single LAN. Another way of saying this is that a single network can have no more than three network segments connected by two repeaters.

  • On a standard Ethernet running at 1,000 megabits per second (1 gigabit), you can connect computers together through no more than 1 hub on a single LAN. Another way of saying this is that a single network can have no more than two network segments connected by one repeater.

Most network designers avoid these limitations by connecting computers to hubs and in turn connecting hubs to central switches and routers. In an extended campus, the 100-meter limitation is important to keep track of. With standard Ethernet running at 10 megabits per second using repeaters, the furthest a computer could possibly be from the central switch/router is 500 meters. With standard Ethernet running at 100 megabits per second using repeaters, the furthest a computer could possibly be from the central switch/router is 300 meters. With standard Ethernet running at 1,000 megabits per second using repeaters the furthest a computer could possibly be from the central switch/router is 200 meters.

Although fiber optic cabling is much more expensive than UTP cabling, it can be used over greatest distances. The exact distance supported depends on the cable type. As an example, 50/125 and 62.5/125 multimode cables supports distances of between 500 and 550 meters. Most fiber optic cables have a transmission speed of 1,000 megabits per second. Gigabit Ethernet is available for Category 5 UTP cabling as well.

Table 8-6 summarizes the most commonly used Ethernet variants. Workstations, servers, and peripheral devices should be placed within the network environment in a way that conforms to the chosen cable type and the applicable limitations. Don't overlook the importance of planning cabling runs around possible points of interface and the need to connect hubs to your organization's network backbone routers.

Table 8-6. Overview of Ethernet variants

Ethernet type

Designation

Cable type

Cable speed

Max. segment length

Standard Ethernet

10Base-T

Category 3 UTP

10 Mbps

100 meters

Fast Ethernet

100Base-T

Category 5 UTP

100 Mbps

100 meters

Gigabit Ethernet

1000Base-T

Category 5E UTP

1,000 Mbps

100 meters

Gigabit Ethernet

1000Base-LX

50/125 or 62.5/125 multimode fiber

10,000 Mbps

550 meters

Gigabit Ethernet

1000Base-SX

50/125 multimode fiber

1,000 Mbps

500 meters

Gigabit Ethernet

1000Base-SX

62.5/125 multimode fiber

1,000 Mbps

220 meters

Gigabit Ethernet

1000Base-LX

9/125 single mode fiber

1,000 Mbps

3,000 meters


Most wireless network adapters and wireless access points conform to standards based on the IEEE 802.1 specification. As Table 8-7 shows, there are multiple variants of the IEEE 802.1 specification, and the variant determines effective distances and transmissions speeds. While you might want to introduce some wireless connectivity options for user workstations, most servers and peripheral devices should be connected to the network using more reliable physical cabling techniques.

Table 8-7. Overview of wireless variants

Wireless standard

Transmission speed

Transmission frequency

Effective indoor range

802.11a

Up to 54 Mbps

5 GHz

Approximately 25 to 75 feet

802.11b

Up to 11 Mbps

2.4 GHz

Approximately 100 to 150 feet

802.11g

Up to 54 Mbps

2.4 GHz

Approximately 100 to 150 feet


8.2.2. Planning a TCP/IP Network Infrastructure Strategy

The three essential components of every TCP/IP network infrastructure are:

  • IP addressing

  • IP routing

  • IP subnetting

The TCP/IP protocols use IP addresses to identify computers on a network, subnet masks to determine the logical subnets within a larger network, and IP routing to route communications.

8.2.2.1. Analyzing IP addressing requirements

Windows XP Professional and Windows Server 2003 computers are configured automatically to use TCP/IP if the operating system detects a network adapter during installation. With TCP/IP, three types of IP addresses can be used:


Static IP addresses

Static IP addresses are those manually assigned to computers. When you manually assign an IP address, you must manually assign other TCP/IP options as well, including the subnet mask and default gateway.


Dynamic IP addresses

Dynamic IP addresses are automatically obtained from a DHCP server and are the default type of IP addresses for both Windows XP Professional and Windows Server 2003. When a DHCP dynamically assigns an IP address, the server can also assign other TCP/IP options, including the subnet mask and default gateway and the addresses of DNS servers.


Automatic private IP addresses

Automatic private IP addresses (APIPA) are used when a computer is configured for DHCP but no DHCP server is available or an IP address lease expires and cannot be renewed. The default automatic addressing allows broadcasting on the local subnet, but does not allow access to remote subnets.

When determining which IP addressing type to use, keep in mind that in most cases you'll want workstations and members servers to use dynamic IP addressing. This makes it easier to manage IP addressing, since you can make changes centrally through DHCP rather than make changes on each individual computer. While some types of servers, including DHCP servers, require static IP addressing, most others can use either static or dynamic IP addressing.

The way IP addresses are used on a network depends of the version or versions of TCP/IP that are implemented. Most current networks use TCP/IP version 4. In order to determine your organization's IP addressing needs, you must consider the following:

  • How many networks do you need?

  • How many computers on each network?

  • Will computers need to connect directly to the Internet?

The answers to these questions will determine your IP addressing needs. All IP addresses are either public or private. Public IP addresses are routable over the Internet and must be assigned by Internet Service Providers (ISPs). Private IP addresses are reserved for use on internal networks and are not routed over the public Internet. If you're connecting a computer directly to the internet and you've been assigned an IP address, you can use a public IP address. Otherwise, you should use a private IP address.


Tip: Public and private IP addresses can also be referred to as registered and unregistered IP addresses. Public (registered) IP addresses must be registered with an ISP. Private (unregistered) IP addresses do not need to be registered with an ISP.

The available IP addresses are divided into network class ranges. For TCP/IP version 4, the standard IP classes are Class A, Class B, and Class C. These network classes are used with unicast IP addresses; which class you use is based on the anticipated number of networks and hosts per network.

TCP/IP version 4 IP addresses are comprised of sets of 32-bit numbers. When you assign IP addresses, each 8-bit section, or octet, of this 32-bit number is entered in decimal format with each set of numbers separated by periods.

With Class A networks, the first octet identifies the network, and the last three octets identify the computers on the network, allowing millions of hosts but a small number of networks. Usable Class A networks have addresses that begin with a number between 1 and 126. Private Class A network addresses have a network ID of 10.0.0.0 and an assignable IP address range of 10.0.0.1 to 10.255.255.254.


Tip: The Class A address 127 has special meaning and isn't available for assignment. IP addresses with this network address are local loopback addresses. Any packets sent by a computer to this address are handled as if they've already been routed and reached their destination. In other words, any packets addressed to the 127 network are addressed to and received by a computer's local network interface.

With Class B networks, the first and second octet identify the network, and the last two octets identify the computers on the network, allowing an equal number of networks and hosts. Class B networks have addresses that begin with a number between 128 and 191. Private Class B network addresses have a network ID of 172.16.0.0 and an assignable IP address range of 172.16.0.1-172.31.255.254.

With Class C networks, the first three octets identify the network, and the last octet identifies the computers on the network, allowing many networks and relatively few hosts per network. Class C networks have addresses that begin with a number between 192 and 223. Private Class C network addresses have a network ID of 192.168.0.0. and an assignable IP address range of 192.168.0.1-192.168.255.254.

Table 8-8 provides an overview of the standard network classes, showing the bits for the subnet mask and the network prefix of each. The table also lists the maximum number of nodes for each IP address class without subnetting. You can use this information to help you plan which IP address class to use, taking into account any possible future expansion needs.

Table 8-8. Overview of standard network classes bits and prefixes

Address class

Bits for subnet mask

Network prefix

Maximum nodes

Class A

11111111 00000000 00000000 00000000

/8

16,777,214

Class B

11111111 11111111 00000000 00000000

/16

65,534

Class C

11111111 11111111 11111111 00000000

/24

254


Table 8-9 provides an overview of IP addresses by class. The first and last IP addresses of a subnet are not usable and cannot be assigned to client computers. The first IP address of a subnet is the network ID. The last IP address of a subnet is the network's broadcast address . With standard network configurations, the network ID is the .0 address of the subnet, such as 192.168.1.0, and the broadcast address is the .255 address of the subnet, such as 192.168.1.255.

Table 8-9. Overview of private and public IP address classes

Network class

Network ID

Subnet mask

Public Class A

1.0.0.0-126.0.0.0

255.0.0.0

Private Class A

10.0.0.0

255.0.0.0

Special Class A

127.0.0.0

255.0.0.0

Public Class B

128.0.0.0-191.0.0.0

255.240.0.0

Private Class B

172.16.0.0

255.240.0.0

Public Class C

192.0.0.0.0-223.0.0.0

255.255.0.0

Private Class C

192.168.0.0

255.255.0.0


Most organizations use private IP addresses for all networking equipment, workstations, servers, and peripherals on their internal networks. If the organization has devices that connect directly to the Internet, such as routers or firewalls, those devices are assigned public IP addresses. Public IP addresses are also used for the organization's web servers and others servers accessible on the public Internet.

You'll use public IP addresses with NAT. NAT allows multiple client computers to access the public Internet, sharing a single public IP address or a pool of public IP addresses. NAT separates your organization's internal private network from the public network so that you can use private IP addresses internally and use public IP addresses when client computers need to access the Internet.

You'll also use public IP addresses with proxy servers. Proxy servers are used to make requests to Internet servers on behalf of internal clients. Unlike NAT, a proxy server is not a type of routing and is instead a software product that runs at the application layer. When an internal client sends a proxy server a request, the proxy server sends a request to a destination server on the public Internet. When received by the proxy server, the reply from the public Internet server is forwarded to the internal client. Each proxy server you configure must have a public IP address.

8.2.2.2. Planning an IP routing solution

On TCP/IP networks, IP routers are used to connect local area networks and can be hardware or software devices. IP routers connect networks by relaying traffic between the connected networks as necessary. Routing works like this:

  • If the destination address is on the same LAN as the sender, the packet travels directly to the destination.

  • If the destination address is on a different LAN than the sender, the sender transmits the packet to a router instead. This router is specified as the computer's default gateway.

As part of the standard TCP/IP configuration, every computer is assigned a default gateway to use for routing communications across subnets. The router's job is to connect network segments. When it receives a packet bound for another subnet, the router reads the destination address and compares the address to the entries in its routing table. The routing table entries tell the router where to send the packet. If the router is directly connected to the destination subnet, the router transmits the packet directly to the destination. Otherwise, the router sends the packet to another router, which in turn routes the packet.

Routers obtain their routing information using either static routing or dynamic routing. With static routing, an administrator manually creates routing entries. With dynamic routing, routers can automatically determine routes from other routers.

With Windows Server 2003, the IP routing protocols you'll work with the most are:


DHCP Relay Agent routing protocol

Enables routing of DHCP broadcast messages between subnets. DHCP Relay Agent routing protocol is essential for organizations with centralized DHCP servers and multiple subnets.


Routing Information Protocol (RIP) version 2 for Internet Protocol

Enables dynamic routing between subnets. RIP is an easily managed routing protocol, but limited to a maximum hop count of 15. For successful communications, source and destination computers can have no more than 15 routing devices between them.


Open Shortest Path First (OSPF)

Enables extended dynamic routing between subnets. With OSPF, source and destination computers can have more than 15 routing devices between them, but OSPF is more complex to configure and maintain than RIP.


Network Address Translation (NAT)

Enables internal client computers with private IP addresses to access the public Internet using a public IP address. NAT provides Internet connectivity to internal clients through a single interface and includes the Basic Firewall, which can be used to block external traffic from entering the internal network.

IP routing and subnets become increasingly important as an organization grows. Most small organizations have a single network and don't necessarily need IP routing to manage internal routing needs. Most medium and large organizations make extensive use of IP routing and have networks divided into multiple subnets. One of the primary reasons for creating multiple subnets is to help manage the traffic on the network, especially for broadcast messages.

Computers use broadcasts for all types of communications, including DHCP server discovery. All computers on the same subnet receive broadcasts transmitted by all other computers on the subnet. When any two computers on a subnet transmit a packet at the exact same time, a collision occurs and both packets are destroyed, forcing the computers to retransmit the packet. Thus, as the network grows, you can reduce the amount of broadcast traffic received and the possibility of collisions, by splitting the network into multiple subnets.


Tip: If two devices on the network try to communicate at the same time, a collision occurs. As a result of the collision, both devices must try to send their message again.

When working with broadcast and multicast traffic, it is important to understand what are broadcast domains and collision domains. A network segment in which all devices on the segment can hear broadcast and multicast traffic is a broadcast domain. A network segment in which all devices on the segment can hear when a collision happens is a collision domain. In your network planning, broadcast and collision domains are important.

Networks can use hubs, bridges, switches, and routers. In the OSI model, the Data Link Layer (Layer 2) forms the border of broadcast and collision domains. All hubs and bridges work at Layer 2. Some switches operate at Layer 2, while others operate at Layer 3. Routers are also Layer 3 devices.

Since broadcast and multicast messages are found at Layer 3, these messages pass across any device communicating at Layer 2. Thus, if network segments are connected with hubs, bridges, or Layer 2 switches, the network segments are in the same broadcast and collision domains.

To set the boundaries of network segments, use Layer 3 devices, such as a Layer 3 switch or a router. Network segments on opposite sides Layer 3 switches or routers are in different broadcast and collision domains.

8.2.2.3. Creating an IP subnet scheme

With TCP/IP, a subnet mask specifies how many bits of an IP address to use for the network ID and how many bits to use for the host ID. On a network that follows the standard class rules (also referred to as a classful network), the network ID bits are fixed. A network that doesn't follow the standard rules is referred to as a classless network.


Tip: The routing protocol you use with subnetting must support Classless Inter-Domain Routing (CIDR). Both RIP version 2 and OSPF support CIDR. However, RIP version 1 does not support CIDR.

Table 8-10 provides an overview of standard subnet masks. As the table shows, with Class A networks, the first 8 bits of the 32-bit IP address identify the network ID and the final 16 bits are the host ID. With Class B networks, the first 16 bits of the 32-bit IP address identify the network ID and the final 8 bits are the host ID. With Class C networks, the first 24 bits of the 32-bit IP address identify the network ID and the final 8 bits are the host ID.

Table 8-10. Standard subnet masks

Network class

Bit length

Subnet mask

Prefix notation

Class A

8

255.0.0.0

/8

Class B

16

255.240.0.0

/16

Class C

24

255.255.0.0

/24


Rather than writing out a network ID followed by a subnet mask, you can use a prefix notation when referring to IP addresses. In this notation, the network ID is followed by the number of bits in the network ID. Thus, rather than writing or saying that the network 10.0.0.0 has a network mask of 255.0.0.0, you could say the network 10.0.0.0 is a "slash 8" network. This is written in network prefix notation as:

 10.0.0.0/8 

Like IP addresses, subnet masks can be written as a 32-bit value. Bit values are assigned in a specific order, from the most significant bits to the least significant bits. From left to right the values of each bit are 128, 64, 32, 16, 8, 4, 2, and 1. Each bit that's set is noted by a 1, which means the bit is on. When you add the bits together, you get the subnet mask. For example, the binary equivalent of 255 is:

 11111111 

And the binary equivalent of 128 is:

 10000000 

Bits in the subnet mask are always set consecutively from left to right. The subnet mask 255.240.0.0 is valid because all eight bits are set in the first octet and the next four bits are set in the second octet, as shown here in the binary equivalent of the subnet mask:

 11111111 11110000 00000000 00000000 

The subnet mask 255.255.64.0 is invalid because it is missing a bit, as shown here in the binary equivalent of the subnet mask:

 1111111  1 11111111 01000000 00000000 

If you want to create logical networks within the standard network class ranges, you can use subnetting to subdivide the network. When you use subnetting, you determine which bits apply to the network ID and which bits apply to the host ID by the subnet mask. For example, you might want to subnet so that the first 26 bits refer to the network ID and the final 6 bits refer to the host ID.

  • On a Class A network, this allows you to create up to 262,144 subnets that have up to 62 nodes each.

  • On a Class B network, this allows you to create up to 1,024 subnets that have up to 62 nodes each.

  • On a Class C network, this allows you to create up to 4 subnets that have up to 62 nodes each.

Class C networks are some of the most commonly subnetted network classes. Table 8-11 provides an overview of how Class C networks can be subnetted.

Table 8-11. Overview of subnetting Class C networks

Maximum subnets

Bits for subnet mask

Network prefix

Decimal

Maximum nodes

1

11111111 11111111 11111111 00000000

/24

255.255.255.0

254

2

11111111 11111111 11111111 10000000

/25

255.255.255.128

126

4

11111111 11111111 11111111 11000000

/26

255.255.255.192

62

8

11111111 11111111 11111111 11100000

/27

255.255.255.224

30

16

11111111 11111111 11111111 11110000

/28

255.255.255.240

14

32

11111111 11111111 11111111 11111000

/29

255.255.255.248

6

64

11111111 11111111 11111111 11111100

/30

255.255.255.252

2


Following the table, you could create eight /27 subnets for the Class C network 192.168.1.0. Excluding the subnet ID and subnet broadcast address, each of these subnets could have up to 30 nodes.

Once you've decided how you want to subnet the network, you need to calculate the network address of each subnet, and from that, determine the usable IP addresses for each subnet. The easiest way to do this is to extract the octet that contains both the subnet bits and host identifier bits and subtract it from 256. The result is the network address of the second subnet.

For example, the /27 network mask is 255.255.255.224. The result of 256 minus 224 is 32. If you are subnetting the 192.168.1.0 network, this means the second subnet ID is 192.168.1.32. To determine the network address of each successive subnet, increment the result of the previous subtraction by itself. Thus, the network IDs for the 192.168.1.0/27 network are:

 192.168.1.0 192.168.1.32 192.168.1.64 192.168.1.96 192.168.1.128 192.168.1.160 192.168.1.192 192.168.1.224 

You can use the formula 2^x to calculate the number of subnets, where x is the number of additional network bits in the network mask from the standard network bits in the network for the IP address class. In the previous example, you are working with Class C network addresses. With standard Class C network addresses, there are 24 bits in the network mask. You are creating a /27 network, meaning you are using three additional bits for the network ID. Using the formula (2^3 = 8), you can determine there will be eight subnets.

You can use the formula 2^x - 2 to calculate the number of nodes on a subnet, where x is the number of host bits in the network mask. For example, in the previous example, the /27 network mask means there are five bits for hosts. Using the formula (2^5 - 2 = 30), you can determine there will be 30 hosts on each subnet.

In each case, the first IP address after the network ID is the first usable IP address on the subnet, and the IP address prior to the next subnet ID address is the broadcast IP address for that subnet. Table 8-12 provides a summary of the subnets and IP addresses for the 192.168.1.0/27 network.

Table 8-12. Subnetting the 192.168.1.0/27 network

Subnet ID

First usable IP address

Last usable IP address

Broadcast IP address

192.168.1.0

192.168.1.1

192.168.1.30

192.168.1.31

192.168.1.32

192.168.1.33

192.168.1.62

192.168.1.63

192.168.1.64

192.168.1.65

192.168.1.94

192.168.1.95

192.168.1.96

192.168.1.97

192.168.1.126

192.168.1.127

192.168.1.128

192.168.1.129

192.168.1.158

192.168.1.159

192.168.1.160

192.168.1.161

192.168.1.190

192.168.1.191

192.168.1.192

192.168.1.193

192.168.1.222

192.168.1.223

192.168.1.224

192.168.1.225

192.168.1.254

192.168.1.255


8.2.3. Troubleshooting TCP/IP Addressing

Exam 70-293 tests your ability to troubleshoot TCP/IP addressing with respect to two specific objectives:

  • Diagnosing and Resolving Issues Related to Client Computer Configuration, which was previously covered in "Troubleshooting TCP/IP Addressing" in Chapter 5.

  • Diagnosing and Resolving Issues Related to DHCP Server Address Assignment, which was previously covered in "Troubleshooting DHCP" in Chapter 5.

8.2.4. Planning an Internet Connectivity Strategy

Just about every organization, regardless of size, will want to configure the internal network so that users can access the Internet. The Internet has a wealth of resources that users will want to access, and users will also want to be able to send and receive email. Since it is pretty much a given that administrators will need to configure Internet connectivity, the question to answer when developing an Internet strategy isn't whether Internet connectivity is needed but rather how should it be configured. The answer to this question should:

  • Address the security policies and requirements of the organization

  • Address the needs of users within the organization

In most cases, you'll need to balance the security policies and requirements of the organization, the needs of its users, and the costs of implementing the connectivity strategy. While some small business may be able to install a cable or DSL solution to meet connectivity requirements, most medium to large organizations will need to install a WAN connection to an ISP and share the connection with all users on the internal network. To connect the internal network with the ISP, you need a WAN router. The job of the WAN router is to forward all traffic not addressed to the internal network over the WAN connection. At the ISP, the traffic is then routed to the Internet.

NAT and firewalls provide solutions for securing your internal network and safeguarding the organization from attacks. Using NAT and firewalls, you can create a clear separation of the internal network from the Internet. NAT allows users with private IP addresses on the internal network to access the public Internet using public IP addresses. Firewalls protect the internal network from attack. Once you've planned the NAT and firewall deployment, the primary question you must answer before choosing an Internet access solution is how much bandwidth is required to meet the organization's needs.

8.2.4.1. Understanding bandwidth requirements

The bandwidth requirements of the organization will determine the type of Internet access solution you use and how much this solution will cost. Most organizations require two types of bandwidth:

  • One for internal users

  • One for the organization's web presence

Ideally, you'll have a strategy for connecting internal users to the Internet and a separate strategy for the organization's web presence. The connectivity strategy for users is the focus of the exam.

While most organizations centrally manage their overall Internet connectivity strategy in terms of acceptable costs, reliability objectives, and security requirements, each office or branch within the company typically has a separate Internet connectivity solution that is based on the needs of that office or branch.

To determine the bandwidth requirements for an Internet connection, you'll need to:


Determine how many users on average will simultaneously access the Internet

Regardless of the organization's size, not all users will access the Internet at the same time. To determine needs, you'll to determine how many users are working at one time and how much of that time they spend accessing the Internet. For example, in a company with 500 employees, you might find that on average, only 50 simultaneously access the Internet.


Determine when Internet bandwidth is need

Determining usage times goes hand in hand with determining the number of average users connecting to the Internet. You should plan to provide sufficient bandwidth to support peak usage times. To do that, you'll need to understand the schedule of workers at the location for which you are developing an Internet connection strategy. For example, 9 to 5 workers may only require bandwidth from 8 to 6, and use the most bandwidth just prior to, during, and just after regular business hours. On the other hand, shift workers will need bandwidth around the clock and may have peak usage periods throughout their 24-hour a day schedule.


Determine the relative importance of Internet access as compared to the cost of the access

In most organizations, cost is a key factor in choosing an Internet connectivity solution. Cost should be weighed against the relative importance of access. You'll have a different solution when 100 percent reliability and 100 percent accessibility are requirements than when reliability and accessibility are weighed equally with cost and efficiency. When cost and efficiency are determining factors, you may choose a connectivity solution that is sufficient to meet most but not all usage conditions.


Determine the categories of users relative to the types of Internet applications users run

Email, web browsers, FTP, and streaming media are all types of Internet applications. While the types of Internet applications that will be used are important, don't overlook the value of categorizing users according to how they use those applications. For example, you might classify users as low-, moderate-, and high-bandwidth consumers where: low-bandwidth users send email messages without attachmentsor perhaps small text attachmentsand occasionally browse the Internet; moderate-bandwidth users frequently send email messages with attachments and frequently browse the Internet; and high-bandwidth users routinely send emails with large multiple-megabyte attachments or routinely use streaming media in cases such as for teleconferencing over the Internet.


Determine where users are located

You should always carefully consider the location of the computers that will be accessing the Internet. While you may be configuring Internet access for a single remote office or division within the company, computers may be spread over many buildings, as with a corporate campus, or the computers may be on many different floors of a single building. In either case, you are working with multiple locations that may possibly need separate Internet connectivity strategies. If possible, locate the Internet connection in the same area as the computers that will be using that connection.

8.2.4.2. Choosing an Internet access solution

Every Internet access solution requires a WAN connection, a WAN router, and an ISP to provide connectivity. For security, the connection should be protected with NAT and firewall technology at a minimum and possibly proxy technology as well. Table 8-13 provides a summary of key Internet access solutions. Pay particular attention to the number of simultaneous users and applications supported for each solution. These values are based on simultaneous usage of email, web, and file transfer applications.


Tip: Cable and DSL modems offer asymmetrical solutions. The modem connections run faster downstream than upstream.

Table 8-13. Overview of Internet access solutions

Connection type

Transmission speed

Simultaneous users/application

Dial-up/Dual dial-up Modem

Up to 56 Kbps/Up to 128 Kbps

8-10 email users

2-3 web users

1-2 large files/attachments

ISDN (Basic Rate Interface)

Up to 128 Kbps

8-10 email users

2-3 web users

1-2 large files/attachments

ISDN (Primary Rate Interface)

Up to 1.544 Mbps

50-70 email users

20-30 web users

12-20 large files/attachments

Cable Modem

Up to 7 Mbps downstream and 768 Kbps upstream

100-150 email users

50-75 web users

30-50 large files/attachments

DSL Modem

Up to 5 Mbps downstream and 768 Kbps* upstream

90-120 email users

40-60 web users

24-40 large files/attachments

T-1

1.544 Mbps

50-70 email users

20-30 web users

12-20 large files/attachments

Fractional T-1

Up to 1.544 Mbps in 64 Kbps increments

Varies depending on bandwidth

T-3

44.736 Mbps

1500-2500 email users

600-900 web users

360-600 large files/attachments

Fractional T-3

Up to 44.736 Mbps in 1.544 Mbps increments

Varies depending on bandwidth



Tip: It is important to point out that cable and DSL capabilities have changed considerably and are evolvingand the exam may not take these changes into consideration. When originally implemented, cable modem speeds were up to 1.544 Mbps, and DSL speeds were up to 640 Kbps, with cable modem being the more reliable solution. That is no longer the case, as the table points out. However, cable and DSL solutions typically are limited severely by their upstream capabilities, which reflect the bandwidth available for sending data.

Once you choose what the WAN technology to use, you'll need to choose a WAN router and an ISP to provide connectivity. Both hardware routers and software routers are available, and your ISP may have a preference as to which type you use. The ISP may also require you to use a specific type of router. Choose an ISP based on the services they offer, the cost of the service, and the support capabilities.

Hardware routers are standalone hardware devices that connect your network over the WAN to the ISP. Many hardware routers can be configured with components to provide NAT, DHCP, and firewall capabilities. For medium to large enterprise solutions, however, each of these components will typically be separate hardware devices.

Software routers are routers configured through software running on a computer. A computer running Windows Server 2003 can be configured as a router using Routing And Remote Access Service. When you also configure NAT and Basic Firewall, the server acting as a router can provide NAT and firewall capabilities as well.

Most WAN connections must be terminated using a separate piece of hardware. For a dial-up connection, a modem is used to terminate the WAN connection. ISDN, Cable, and DSL connections are terminated with a device that typically acts as both a terminator and a router. For a leased T-1 and T-3 line, a CSU/DSU is used to terminate the WAN connection.

8.2.5. Troubleshooting Connectivity to the Internet

Without a clear plan, diagnosing and resolving problems with connectivity to the Internet can be a significant challenge. When users report problems with Internet connectivity, your first task should be to determine the location and scope of the problem. Start troubleshooting with the client computer. If the problem is reproducible on other computers, it could be a problem with name resolution, NAT, firewalls, or proxies. Beyond this, the problem may be on the WAN itself.

8.2.5.1. Diagnosing and resolving issues related to client configuration and name resolution

All Internet connections use TCP/IP so TCP/IP configuration issuesas discussed in "Troubleshooting TCP/IP Addressing" in Chapter 5may be an issue. Before you begin troubleshooting, try to determine the scope of the problem. Is this a problem with a single computer? Is this a problem with all computers in a specific location? Is this a problem with all computers in all locations?

If a specific client computer is having a problem, you can try to reproduce the problem on another computerpreferably one connected to the LAN in the same way as the computer experiencing the problem. If you are unable to reproduce the problem, it is likely isolated to a specific client's configuration and network connection. Check the computer's TCP/IP configuration and network connection. As discussed in "Troubleshooting TCP/IP Addressing" in Chapter 5, improper settings will cause communications problems. Some of the problems and symptoms are as follows:


Invalid gateway configuration

The computer may be able to communicate on a local subnet but not across subnets. The computer won't be able to access resources in other subnets or connect to computers in other subnets.


Invalid IP address

Except for broadcast communications, the computer may not be able to communicate on a local subnet or across subnets.


Invalid subnet mask

The computer may not know appropriate subnet boundaries and may not route communications through a gateway when it should.


Invalid DNS configuration

The computer may not be able to use name resolution or may fail to resolve computer names.


Invalid WINS configuration

Windows Internet Naming Service (WINS) is used with pre-Windows 2000 computers and resources. The computer may not be able to resolve NetBIOS computer names and therefore may not be able to communicate with pre- Windows 2000 computers and resources.

You should use ipconfig /all to determine the computer's IP addressing configuration. On a client, you can attempt to restore connectivity with the network using the Repair option on Support tab of the Local Area Connection Status dialog box (see Figure 8-6).

Figure 8-6. Click Repair to attempt to restore connectivity.


When you use Repair, the client attempts to refresh the stored data for its connection. The client does this by:

  1. Renewing the DHCP IP address lease and the related TCP/IP settings.

  2. Flushing the ARP cache, the NetBIOS cache, and the DNS resolver cache.

  3. Re-registering with WINS and DNS.

Name resolution problems can cause problems with Internet connectivity as well. When name resolution fails, client computers won't be able to access Internet resources using DNS host and domain names. You can determine if name resolution is the cause of the connectivity problem by trying to access an Internet resource using an IP address instead of its DNS name. If you can successfully connect to an Internet resource by its IP address, there's a DNS configuration problem with either the client's DNS configuration or the organization's DNS server.


Tip: DNS is an integral part of Active Directory. If the DNS Server service is not running, clients may also not be able to locate Active Directory objects in the domain.
8.2.5.2. Diagnosing and resolving LAN/WAN problems

Problems experienced by all clients connected to a specific part of the network may be due to the hub or switch through which they are connected. Problems experienced by all computers on the network can be due to problems with the WAN router or the WAN connection.

If multiple clients in the same area of the network have the same problem, try to determine whether the problem affects access to all resources or access to Internet resources only. If you can access internal resources but not Internet resources, the problem is related to the components providing the Internet connection. If you have access to neither internal nor Internet resources, the problem is related to the internal network.

Internal network problems that are not due to client configurations can be diagnosed by examining the Internet infrastructure components that provide services required for accessing the Internet. This means checking for name resolution issues as well as checking for NAT, firewall, and proxy issues.

NAT routers, proxies, and firewalls must have a routing interface that connects to the WAN using a public IP address assigned by your ISP. These devices use TCP/IP as well, and like any other TCP/IP client, they must be properly configured. Check the IP address, subnet mask, default gateway, and DNS server settings to ensure that they are correct.

For NAT, the NAT router must be configured to work with computers on your internal network. For firewalls and proxies, the firewall or proxy must be configured properly, and both may be configured to block access for various reasons. If user authentication fails or there is a specific policy that is blocking access, access will fail.

WAN problems can be due to:

  • A misconfigured or faulty WAN router

  • A misconfigured or faulty terminus, such as a bad CSU/DSU

  • A misconfigured or unavailable WAN connection

  • An outage at the ISP

The TRacert, ping, and pingpath commands can help you determine where a WAN problem originates. Try pinging the WAN router and then tracing a route to a known web site or a site set up for such purpose by your ISP. Provided that the ping/trace requests are not being blocked by firewalls or proxy servers, the failure point is the likely point of origin for the problem:

  • If you can ping to the WAN router, the router is available but not necessarily configured properly. Check the routes on the router to make sure they are configured properly.

  • If the route trace fails after your company's WAN router, the likely problem is the WAN connection or the ISPs WAN router. Check the terminus. If necessary, contact the ISP by phone to report the problem.

  • If the route trace fails after your ISP's WAN router, the likely problem is an outage at the ISP. Contact the ISP by phone to report the problem.

WAN routers have at least two interfaces: one connected to the internal network and one connected to the WAN. These interfaces must be configured properly. In the WAN router's routing table, there should be a default gateway entry that sends all traffic not bound for the internal network through the WAN interface and over the WAN.

The CSU/DSU terminating the WAN connection may also be the source of the problem. Cycle the power on the CSU/DSU or reset the CSU/DSU.

If the WAN and CSU/DSU are working properly, the likely problem is with your ISP. The ISP may have a problem with its network infrastructure or Internet connectivity. The problem could extend to the Internet backbone as well.


Tip: For the exam, you will need strong knowledge of ping, TRacert, and pingpath, and the differences between these commands. These commands are covered in "Troubleshooting TCP/IP Addressing" in Chapter 5.

8.2.6. Planning a Name Resolution Strategy

Name resolution is essential for all TCP/IP networks, and a key part of the network design process involves planning for the organization's current and future name resolution needs. As with other areas of network design, considerable planning should be performed prior to deploying a name resolution strategy. This strategy should be reviewed periodically and modified as necessary to meet changing requirements over time.

8.2.6.1. Understanding name resolution

When computer names are used, name resolution is critical to proper functioning of TCP/IP communications. A computer must be able to look up the IP address associated with a computer name, referred to as a forward lookup, or determine the computer name based on an IP address, referred to as a reverse lookup. With Windows computers, two name resolution technologies are used:

  • NetBIOS (Network Basic Input/Output System)

  • Domain Name System (DNS)

On Windows NT 4.0 networks, Windows Internet Naming Service (WINS) is used to resolve NetBIOS names. On networks running Windows 2000 and later computers, DNS is used to resolve DNS hostnames.

Both name resolution technologies have specific namespaces, which are used to locate computers on the network. NetBIOS uses a flat naming structure. Each computer has a single NetBIOS name of up to 16 characters, which must be unique on the network. Because Windows uses the 16th character for a reserved code that identifies the type of resource represented by the name, NetBIOS names for Windows computers can be no longer than 15 characters. Because NetBIOS uses a flat namespace, it is not very scalable and is intended for use on private networks only, and not on the public Internet.

Unlike NetBIOS, DNS uses a hierarchical namespace. With DNS, computers are grouped by name within domains. Domains establish a hierarchical naming structure so a computer's place within the domain structure can be determined.

In a standard configuration, a computer's fully qualified domain name or FQDN is its hostname combined with the related domain name. For example, the FQDN for the computer CorpSvr18 in the WilliamStanek.com domain is CorpSvr18.WilliamStanek.com.

Since DNS domain structure is hierarchical, DNS domains can have subdomains. For example, the WilliamStanek.com domain might have Tech and Eng subdomains. The computer Workstation41 in the Tech domain would have a FQDN of Workstation41.Tech.WilliamStanek.com.

When the network is not fully configured for DNS name resolution, you might need NetBIOS name resolution. NetBIOS is also required for some applications, such as the Computer Browser service. While NetBIOS and the DNS Client service are enabled by default in Windows XP Professional and in Windows Server 2003, name resolution is not fully functional unless the server components for name resolution are configured as well. This means to fully configure NetBIOS name resolution, you must install WINS servers; to fully configure DNS name resolution, you must install DNS servers.


Tip: If no WINS server is configured or available, NetBIOS name resolution uses broadcasts. These broadcasts are limited to the local subnet only.
8.2.6.2. Planning a DNS name resolution strategy

DNS is the primary name service used with networks running Windows 2000 and later computers. DNS provides name resolution for client systems by translating computer names to IP addresses and vice versa so that computers can locate each other. DNS uses host (A) records to resolve computer names to IP addresses for forward lookups, and uses pointer (PTR) records to resolve IP addresses to computer names for reverse lookups. In the standard configuration of DNS and DHCP, DHCP clients running Windows 2000 or later update their host (A) records in DNS automatically whenever an IP address is assigned or renewed, and DHCP servers update the PTR records on behalf of clients.

DNS names can be up to 255 characters.

Active Directory domains and DNS domains can, and usually do, share common naming structures. For example, the computer DataServer03 in the williamstanek.com Active Directory domain typically would have a fully qualified hostname in DNS as DataServer03.williamstanek.com. It should be noted, however, that the Active Directory and DNS naming structures can be completely different. For example, you may have an Active Directory domain structure that includes multiple subdomains, but have a DNS domain structure where all computers use the parent domain name for the purposes of name resolution.

DNS uses both iterative and recursive queries to resolve queries. With an iterative query, a DNS server attempts to resolve the query from its records or from its cache. If it is unable to resolve the query, the server refers the client, based on the server's root hints, to an authoritative server in another part of the domain namespace.


Tip: For DNS servers running Windows 2000 or later, root hints are stored in the %SystemRoot%\System32\Dns\Cache.dns file. For most internal DNS servers, the root hints do not need to be modified. For an internal root server (name ".") on private networks, however, you should delete the Cache.dns file.

With a recursive query, the DNS client requests that the DNS server respond directly an answer that resolves the query. The DNS server cannot refer the client to another DNS server and, instead, queries other DNS servers on behalf of the client. The server continues until it locates a server that is authoritative for the requested name, until an error is returned (such as "Name not found") or until the query times out.

By default, Microsoft DNS servers use recursion to query other DNS servers on behalf of clients. However, on the Forwarders tab of the DNS server's properties dialog box, shown in Figure 8-7, the option Do Not Use Recursion For This Domain can be used to disable recursion. If recursion is disabled, the client performs iterative queries using the root hints from the DNS server. Iterative queries mean that the client will make repeated queries of different DNS servers.

Figure 8-7. Control recursion on the Forwarders tab.


When you configure a DNS client, you specify the primary and alternate DNS servers to use. Each DNS server is responsible for name resolution within specific administrative areas known as zones. A zone is a portion of the DNS database that is being managed. A single zone can contain a single domain, or it can span multiple domains.

DNS servers are said to be either authoritative or nonauthoritative for a zone. An authoritative DNS server for a zone is responsible for the related portion of the DNS database and is the primary source from which other DNS servers resolving any quests for that zone. A nonauthoritative DNS server for a zone may cache information related to the zone, but ultimately, must rely on an authoritative DNS server to keep its cache up to date.

8.2.6.2.1. Planning a DNS namespace design

DNS servers store zone information in zone files. Zone files contain resource records that are used to resolve queries and primarily map hostnames to IP addresses. By default, zone files are created as standard text files on the DNS server. When the DNS Server service is installed on an Active Directory domain controller, the zone data can be stored in Active Directory by creating an Active Directory-integrated zone.

Zones always consist of entire domains or subdomains. While you can create a zone that contains multiple domains, those domains must be contiguous in the DNS namespace. Following this, you can create a zone that includes a parent domain and subdomains of the parent domain because the parent domain and the subdomains share a contiguous namespace. You cannot, however, create a zone containing two subdomains of a parent domain without also including the parent domain. This is because the subdomains of a parent domain are not connected and share a contiguous namespace via the parent domain only.


Tip: Subdomains of a parent domain are also referred to as child domains.

Three types of zone files are used with DNS:


Primary

The master copy of a zone, and as such, it is the only writeable copy and the one that must be updated when you want to modify or maintain records. A primary zone can be integrated with Active Directory to create an Active Directory-integrated primary zone.


Secondary

A copy of a primary zone, and as such, it is a read-only copy that is updated when the primary DNS server for a zone sends a copy of the zone file to a secondary server.


Stub

Lists authoritative name servers for a zone so that DNS servers hosting a parent zone are aware of authoritative DNS servers for the related child zones. A stub zone can be integrated with Active Directory to create an Active Directory-integrated stub zone.


Tip: Because DNS data is replicated to domain controllers, Active Directory-integrated zones do not have any secondaries. You can, however, configure Active Directory-integrated zones to replicate zone information with third-party DNS servers.

In every DNS domain structure, you'll want to have primary and alternate name servers. All changes to zones are made in the primary zone and replicated to secondary zones. Use secondary zones to make copies of existing primary zones and to distribute the DNS name resolution workload.

Stub zones list authoritative name servers for a zone. Servers hosting stub zones do not answer queries directly, and instead direct related queries to any of the name servers specified in the stub zone's NS resource records. Stubs zones are most often used to track authoritative name servers for delegated zonesand the parent DNS servers of delegated zones are the ones to host the related stub zones.

Windows Server 2003 DNS servers can support and manage 200,000 zones on a single servers. While you can host a DNS namespace divided into multiple zones on a single DNS server, you'll usually want to create multiple zones on a server and then delegate most of the zones to other servers.

Control over zones can be delegated to make it easier to manage the DNS namespace in large enterprises. When you delegate a zone, you assign authority over a portion of the DNS namespace, and in this way, pass control from the owner of the parent domain to the owner of a subdomain. For example, if you have hr.domain.local and finance.domain.local subdomains, you may want to delegate control over these subdomains so they can be managed separately from the organization's parent domain.

Delegation allows remote offices, branches, and departments within the organization to manage their own DNS namespace. It also helps to distribute the workload so that, rather than having one large DNS database, you have multiple DNS databases. Delegating a zone is a two-part process: you must first create the domain to be delegated on the server that will be hosting the delegated zone, and then you must run the New Delegation Wizard on the server hosting the parent zone to specify the zone to delegate.

DNS servers can be configured in the following roles:


Primary

Maintains one or more primary zone files. A DNS server acts as a primary server if you've installed the DNS Server service and created a primary zone on the server.


Secondary

Maintains one or more secondary copies of zone files. A DNS server acts as a secondary server if you've installed the DNS Server service and created a secondary zone on the server.


Forwarding-only (caching-only)

Maintains a cache of resolved queries; contains no zones and hosts no domains. A DNS server acts as a forwarding-only server if you've installed the DNS Server service on a server but have not configured DNS zones. Another name for a forwarding-only server is a caching-only server.

A single DNS server can have multiple roles. When file-based zones are used, most DNS servers act as both primaries for one or more zones and as secondaries for other zones.

8.2.6.2.2. Planning zone replication requirements

Most organizations will want to have multiple DNS servers to provide fault tolerance and distribute the name resolution workload. With file-based zones, this means having primary and secondary DNS servers, and replicating zone data from primary DNS servers to secondary DNS servers. With Active Directory-integrated zones, the zone database is replicated automatically.

When you configure standard primary and secondary zones, you must configure zone transfers. Zone transfers are used to send a copy of a zone to requesting servers. Zone transfers ensure secondary servers are kept up to date with changes in the primary zone, which enables secondary servers to perform authoritative name resolution for domains in the zone in the same way that the primary server can. You can configure zone transfers to occur when changes are made to the resource records in the primary zone or at specific intervals.

By default, zone transfers are not allowed or restricted only to the DNS servers specified in the Name Servers tab. If you've configured secondary name servers for a domain, you should enable zone transfers using the Zone Transfers tab of a zone's Properties dialog box (see Figure 8-8). Select the Allow Zone Transfers checkbox, and then specify the servers permitted to make zone transfer requests. To maintain the integrity and security of the network, you'll usually want to limit the list of servers that can make zone transfer requests to the servers listed on the Name Servers tab or to a specific list of designated name servers.

Figure 8-8. Limit zone transfers to enhance security.


Windows Server 2003 DNS servers can use complete transfers as well as incremental transfers. Typically, complete transfers take place when you first configure secondary zones and incremental transfers take place thereafter. As the name implies, a complete transfer copies a complete copy of the master zone file to the secondary server, and an incremental transfer copies only the data that has changed since the last zone transfer.

When zone files change, secondary servers can be notified automatically. In the default configuration, automatic notification is enabled but to a designated list of name servers only. You must specify the designated name servers. To configure notification, click the Notify button on the Zone Transfers tab of the zone's properties dialog box. You can also allow automatic notification to the name servers listed on the Name Servers tab of the zone's properties dialog box.

When you install the DNS Server service on an Active Directory domain controller and select Store The Zone In Active Directory when creating a zone, the server does not use a file-based zone. Instead, zone data is stored in the Active Directory database and replicated automatically along with other data stored in Active Directory. The default replication technique is to replicate DNS zone data to all other domain controllers acting as DNS servers in the Active Directory domain where the primary server is located.

You can modify zone data replication in several ways. You can:


Replicate to all other domain controllers acting as DNS servers in the Active Directory forest, which replicates the data

This option replicates zone data throughout the enterprise. Any domain controller acting as a DNS server in the Active Directory forest in which the primary DNS server is located will get the zone data.


Replication to all other domain controllers in the Active Directory domain

This option replicates zone data to all domain controllers in the Active Directory domain in which the primary DNS server is located. Any domain controller, regardless of whether it is also configured as a NS server, gets the zone data.

You can configure Active Directory replication of zone data using the General tab of the zone's properties dialog box (see Figure 8-9). Click the Replication: Change . . . button.

Figure 8-9. Configure replication for Active Directory-integrated zones using the replication options.


Like file-based zones, Active Directory-integrated zones are replicated completely and incrementally. Typically, complete replication occurs when you first configure an Active Directory-integrated zone, and incremental replication of zone changes are replicated thereafter. Because Active Directory-integrated zones are automatically replicated, configuring secondaries is not a prerequisite for replication. There is, in fact, no such thing as an Active Directory-integrated secondary zone. That said, however, you can create file-based secondary zones for Active Directory-integrated primary zones. Situations where you might want to do this are as follows:

  • If no other domain controllers are running DNS in the Active Directory domain.

  • If no other domain controllers are in the Active Directory domain.

  • If no other DNS servers in the organization ar running Windows Server 2003.

Once you configure secondaries, you must also configure zone transfers for the secondaries.

8.2.6.2.3. Planning a forwarding configuration

Most DNS servers rely on forwarders. A forwarder is not to be confused with a forwarding-only (caching-only) DNS server. A forwarder is a DNS server that receives queries from other DNS servers. Use forwarders to regulate the flow of name resolution traffic and to limit the number of servers that transfer name resolution queries outside the internal network.

In the default configuration of a Windows Server 2003 DNS server, a DNS server can forward queries to DNS servers in all other DNS domains and thereby allow all internal name servers to forward queries outside the local network. As this may not be the desired configuration, you'll typically want to use specifically designated forwarders, which forward queries inside or outside the organization's network as necessary. This configuration serves to control the flow of DNS queries and funnel queries through specifically designated name servers. As the designated forwarders also cache lookups, many lookups can be resolved without having to look outside the network, which reduces the flow of network traffic.

When forwarders are used, the DNS query resolution process changes as depicted here:

  1. When a DNS server receives a query, it first attempts to resolve the query using its local zone information or its local cache.

  2. If the query cannot be resolved, the DNS server forwards the request to the designated forwarder.

  3. The forwarder attempts to resolve the query using its local zone information or its local cache. If the forwarder is unable to resolve the query, the DNS server attempts to contact the appropriate name server (as specified in its root hints data).

  4. When an answer is returned to the forwarder, the forwarder returns the response to the originating DNS server, which in turn passes the response on to the client.

There are several forwarder variations that are used, including chaining forwarders and conditional forwarders. When you chain forwarders, you configure a DNS server acting as a forwarder so that it can also forward queries to another forwarder. As an example, you might configure DNS servers at remote offices to forward queries to DNS servers at the central office, and then have the central office DNS servers forward queries to the Internet through the enterprise firewalls.

Queries can also be forwarded conditionally, based on the domain name specified in the name resolution request. Conditional forwarding can allow direct forwarding of requests to an authoritative server for a domain rather than using recursive querying. In some cases, conditional forwarding can reduce network traffic for name resolution and eliminate the need for name servers to query the root name server to determine the authoritative servers for a particular domain. However, conditional forwarding typically requires more time and resources to maintain as you need to configure all DNS severs with the forwarder addresses for all the domains in the namespace and maintain those addresses as the network configuration changes.


Tip: Conditional forwarding is a new feature of Windows Server 2003. To help you prepare for the exam, you need hands on practice and should implement conditional forwarding in several different configurations.

With Windows Server 2003, DNS servers require no special configuration to act as forwarders. However, other DNS servers must be explicitly configured to send queries to the forwarder. To configure a DNS server to use a forwarder, follow these steps:

  1. Open the DNS Management console.

  2. Right-click the DNS Server entry, and then click Properties.

  3. Click the Forwarders tab. Under DNS Domain, the entry All Other DNS Domains is used to configure forwarding for all domains other than domains serviced by zone files on the name server.

    • To limit forwarding to all other domains and specify a designated forwarder, click All Other DNS Domains, enter the IP address of the forwarder, and then click Add.

    • To configure conditional forwarding for a specific domain, click New, type a domain name, and then click OK. Under DNS Domain, click the related domain entry, enter the IP address of the forwarder, and then click Add.

  4. Click OK.

To configure your designated forwarders, simply allow the forwarder query all other DNS domains and do not designate the IP address of any specific name servers to use. With this in mind, the typical configuration is achieved by completing these steps:

  1. Open the DNS Management console.

  2. Right-click the DNS Server entry, and then click Properties.

  3. Click the Forwarders tab.

  4. Under DNS Domain, click the All Other DNS Domains entry and remove any associated IP addresses.

  5. Under DNS Domain, click any other entries, each in turn, and then click Remove.

  6. Click OK.

8.2.6.2.4. Planning for DNS security

In the standard configuration of DNS and DHCP, DHCP clients running Windows 2000 or later update their host (A) records in DNS automatically whenever an IP address is assigned or renewed, and DHCP servers update the PTR records on behalf of clients. Dynamic updates can only occur when the client computer is configured with a domain suffix that matches a zone name hosted by the preferred DNS server. Thus, for a computer named Workstation93 to be dynamically updated in the hr.williamstanek.com zone, the FDQN of the computer must be Workstation93.hr.williamstanek.com.

In the DHCP console, you can control the way dynamic DNS updating works through the properties of the DHCP server. Right-click the DHCP server entry, and then select Properties. The options on the DNS tab determine how dynamic DNS updating works with DHCP. When clients register their own A records, they do not use a secure method to create and update records. This allows any client or server, with appropriate credentials, to modify or delete the records. On the other hand, if a DHCP server dynamically updates A and PTR records on behalf of clients, the server uses secure dynamic updates.

DNS records created using secure dynamic updates can only be updated by the server that created the record (the record owner). While this improves security, this can lead to stale (old) records on the DNS server if the DHCP server that owns a record fails and a client is later assigned a lease from a second DHCP server, as shown in the following scenario:

  1. DHCP Server 1 performs a secure dynamic update of the A and PTR records for a client.

  2. DHCP Server 1 is the owner of those records.

  3. If DHCP Server 1 fails, neither the client nor DHCP Server 2 will able to update the previously created records.

When DHCP servers update both the A and PTR records, you can prevent problems due to stale records by making your organization's DHCP servers members of the DnsUpdateProxy security group. Any objects created by members of this group do not have security settings and thus have no owners. This allows any DHCP server to modify the record. However, if the DHCP server is not a member of the DnsUpdateProxy group, the DHCP server becomes the owner, and no other DHCP servers can modify the record.

The DnsUpdateProxy group should not be used in configurations where clients update A records and DHCP servers update PTR records. In most cases, domain controllers should not be configured as DHCP servers. If DCs are configured as DHCP servers and those servers are members of the DnsUpdateProxy group, records created by the Netlogon service for the DC are not secure.

In DNS, each zone has settings for dynamic updates. Configure these options on the General tab of the zone's properties dialog box. The Dynamic Updates selection list has three options:


Secure Only

Secure DNS updates can be made. If you choose this option, you should configure DHCP so your DHCP servers update DNS records on behalf of clients.


Nonsecure and secure

Clients can make nonsecure updates of their DNS records and DHCP servers can make secure updates of DNS records on behalf of clients.


None

Dynamic updates are disabled. Neither clients or DHCP servers will be allowed to dynamically update DNS records.

The most secure configuration is to use the Secure Only option, which is only available with Active Directory-integrated zones. DNS is vulnerable to many other types of security threats, including denial-of-service attacks, IP spoofing, and redirecting. To help secure DNS from outside threats, you can:


Configure redundant DNS servers

Multiple DNS servers provide fault tolerance and protection for name resolution. To ensure your internal name resolution functions properly in case one or more DNS servers fail, you should configure both primary and secondary DNS servers or configure multiple Active Directory-integrated primary servers. You may also want to place redundant DNS servers on multiple subnets or on multiple sites.


Tip: Small to medium organizations may want to configure DNS clients to use their ISP's DNS servers as alternates. This ensures that external name resolution works if internal name resolution fails. It also allows users to continue to access Internet resources if internal name resolution fails.

Limiting zone transfers

If zone transfers are allowed, zone transfers should be limited to a specific list of name servers or to the servers listed on the Name Servers tab. This improves security for DNS by restricting the servers that have access to zone data. If you do not limit zone transfers, any DNS server can request a complete copy of your zone data. When zone transfers are allowed, you can configure zone transfers using the Zone Transfers tab of the zone's properties dialog box. Select the Only To Servers Listed On The Name Servers tab or Only To The Following Servers radio buttons to restrict zone transfer requests.


Limiting DNS interface access

By default, DNS servers listen for DNS requests on all IP addresses for which they are configured. To prevent possible unauthorized access to DNS data, you can specify that the DNS server should listen only to selected IP addresses. On the Interfaces tab of the DNS server's properties dialog box, select the Only The Following IP Addresses radio button, and then specify the IP addresses to listen on.


Preventing cache corruption

By default, the Secure Cache Against Pollution option is selected on the Advanced tab of the DNS server's properties dialog box. This option ensures that attackers cannot load the DNS server's name cache with incorrect data in an effort to redirect clients DNS queries and gather information about the internal network.

Table 8-14 provides a summary of the types of attacks that can be prevented using a particular configuration option.

Table 8-14. Types of attacks prevented using Secure DNS configurations

Secure DNS configuration

Type of attack prevented

Configure redundant DNS servers

Secures against denial-of-service attacks and other types of intrusion

Limiting zone transfers

Secures against footprinting and unauthorized access to DNS information

Limiting DNS interface access

Secures against IP spoofing and unauthorized access from the Internet

Preventing cache corruption

Secures against redirection and loading cache with incorrect information


8.2.6.2.5. Examining the interoperability of DNS with third-party DNS solutions

The DNS server included with Windows Server 2003 is compliant with most of the RFCs used to define the DNS protocol, including RFC 1034 and RFC 1035. This compliancy ensures that Windows Server 2003 DNS servers can be used with third-party DNS servers.

The DNS server included with Windows Server 2003 can be used with third-party DNS solutions in several ways:

  • Windows Server 2003 DNS servers can act as primaries for secondary DNS servers using third-party solutions.

  • Windows Server 2003 DNS servers can act as secondaries for primary DNS servers using third-party solutions.

In either configuration, you'll need to configure zone transfers between the primary and secondary servers. Using zone transfers, Active Directory-integrated primaries running on Windows Server 2003 DNS servers can replicate data to third-party DNS servers acting as secondaries.


Tip: Windows Server 2003 DNS servers provide basic support for the DNS Security Extensions (DNSSEC) protocol. This support ensures that Windows Server 2003 DNS servers can act as secondary DNS servers for existing DNSSEC-compliant zones.

While Windows Server 2003 DNS servers support the use of Unicode characters in UTF-8 format, this is not the standard character set used by RFC 1123-compliant DNS servers. RFC 1123, which specifies the requirements for Internet hosts, applications, and support, limits DNS names to uppercase characters (A-Z), lowercase characters (a-z), numerals (0-9), and hyphens (-). To ensure RFC 1123 compliance, you can modify the Name Checking server option on the Advanced tab of the DNS server's properties dialog box. As shown in Figure 8-10, set Name Checking to Strict RFC (ANSI) to ensure RFC 1123 compliance.

Figure 8-10. Control RFC 1123 compliance using the Name Checking selection list.


8.2.6.3. Planning a NetBIOS name resolution strategy

NetBIOS computer names are used for backward compatibility with pre-Windows 2000 computers. On networks with computers running Windows 2000 or later, WINS is primarily used to allow pre-Windows 2000 systems to browse lists of resources on the network and to allow Windows 2000, Windows XP, and Windows Server 2003 systems to locate NetBIOS resources.

8.2.6.3.1. Planning NetBIOS name resolution by using the LMHOSTS file

By default, computers that use NetBIOS for name resolution use broadcast messages to resolve computer names on the local subnet to IP addresses and, in this way, locate computers. Because broadcast transmissions are not routed, they are suitable for small networks with a single subnet only. For all other networks, you'll need a better solution, which is provided in the form of LMHOSTS files and WINS servers.

LMHOSTS is a text file that can be created with any standard text editor, and then stored in the %SystemRoot%\System32\Drivers\Etc folder of the Windows computer. Like the LMHOSTS file itself, entries in the LMHOSTS file must be manually created. A basic entry consists of an IP address followed by at least one space and the NetBIOS name associated with that IP address. Each entry must be on a separate line, and comments can be inserted using a pound (#) symbol. Everything on the line after the pound symbol is ignored. The following sample LMHOSTS file provides three commented entries:

 192.168.10.11   FileServer18    #Primary File Server 192.168.10.18   PrintServer18   #Primary Print Server 192.168.10.23   MailServer12    #Primary Mail Server 

Because LMHOSTS files must be manually configured on each computer that needs NetBIOS for name resolution, they aren't practical for use on medium to large networks. To provide NetBIOS name resolution for medium to large networks, Windows Server 2003 includes the Windows Internet Name Service (WINS) Server service, which can be used to resolve NetBIOS names to IP addresses and vice versa.

8.2.6.3.2. Planning a WINS replication strategy

Enable WINS name resolution on a network by configuring WINS clients and servers. To configure WINS clients, install WINS servers and configure the clients with the IP addresses of the WINS servers. Using the WINS server IP addresses, clients can communicate with WINS servers anywhere on the network, even if the servers are on different subnets.

WINS servers require no configuration to register and resolve names. Name registration is automatic with WINS. When a WINS client starts, it transmits its NetBIOS name using the configured name resolution method. Four name resolution methods are available:


B-node (broadcast)

Clients use broadcast messages to resolve computer names to IP addresses. When a client needs to resolve a computer name to an IP address, the client sends a broadcast message on the local subnet.


P-node (peer-to-peer)

Clients use WINS servers to resolve computer names to IP addresses. When a client needs to resolve a computer name to an IP address, the client queries a WINS server.


M-node (mixed)

This mode combines the b-node and p-node name resolution methods. Clients first try to use broadcasts for name resolution. If this fails, they query a WINS server.


H-node (hybrid)

This mode is a variant of the b-node and p-node name resolution methods. Clients first query a WINS server. If this fails, they try to use broadcasts for name resolution.

If WINS servers are available on the network, Windows clients use the p-node method for name resolution by default. If no WINS servers are available on the network, Windows clients use the b-node method for name resolution by default.


Tip: When client computers are dynamically configured using DHCP, you can set the name resolution method using the DHCP option for the 046 WINS/NBT Node Type. For optimal performance, you'll typically want WINS clients to use h-node. This method also reduces broadcast traffic on the network.

When WINS clients communicate with WINS servers, they establish sessions by attempting to register their computer name and IP address in the WINS database. If the computer name and IP address aren't already in use, the WINS server accepts the request and registers the client in the WINS database. The client then has use of the name for a specified lease period and must reregister the name with the WINS server during the renewal interval. If the client can't or doesn't renew the lease, the WINS server releases the name and IP address, allowing another system on the network to use the computer name or IP address. WINS clients automatically release their names when they are shut down.

While a single WINS server can provide services for thousands of clients, you'll want to have multiple WINS servers on the network to provide fault tolerance and load balancing. When you use multiple WINS servers to provide name resolution services for the same clients, you need to configure replication so that name registration entries in one server's WINS database are replicated to other WINS servers.

WINS servers can replicate their databases using push partners, pull partners, or both. A push partner is a WINS server that notifies other WINS servers of changes on the network. A pull partner is a WINS server that requests replicas from a push partner. When a push partner notifies a pull partner regarding changes to the WINS database, the pull partner responds by requesting an update, and then the push partner sends the changes. You can configure any WINS server as a push partner, a pull partner, or both (see Figure 8-11).

Figure 8-11. When you configure replication partner properties, you can set the replication partner type.


Pull partners pull database entries from their replication partners at a specific interval, known as the replication interval. By default, the replication interval for pull replication is every 30 minutes after the pull partner is started.

Push partners use the version ID on the WINS database to determine when to notify replication partners of changes. The version ID is incremented each time a change is made, and replication partners can be notified after a specific number of changes have been made. However, by default, the Number Of Changes In Version ID Before Replication option is set to zero, which specifies that no push triggers are sent to replication partners.

When WINS servers provide services for the same clients, you'll usually want the servers to be push and pull partners with each other. Because of this, the default replication partner type is push/pull, meaning both push and pull replication are to be used. Why is this important? Consider the following example: You have two WINS servers. You make each WINS server the push and pull partner of the other. This configuration ensures changes to the first server's database are replicated to the second, and changes to the second server's database are replicated to the first.

For increased replication reliability, you can configure persistent connections between replication partners. Persistent connections between replication partners are always open even when no data is being transmitted, and help to ensure quick and efficient communications.

8.2.6.4. Troubleshooting hostname resolution

To diagnose name resolution issues, you must first determine whether the problem is due to the client configuration or the server configuration. If a client reports a Name Not Found error when resolving a name, you should first determine whether the client has connectivity to the network. If connectivity isn't a problem, you should check the client's configuration. As discussed in the section of "Troubleshooting TCP/IP Addressing" in Chapter 5, there are a variety of troubleshooting techniques that can be used.

Dynamic updates can only occur when the client is configured with a domain suffix that matches a zone name hosted by the preferred DNS server. Thus, for a computer named Workstation18 to be dynamically updated in the eng.williamstanek.com zone, the FDQN of the computer must be Workstation18.eng.williamstanek.com.

If the client is unable to ping a DNS server or resolve names, the problem could be on the DNS server. Once you've ruled out the client configuration as the source of the problem, you can try to diagnose and resolve the problem on the name server. Start by making sure that the server is running and that the DNS Server service itself is running. When you check the DNS Server Service in the Services utility, the service should be running and configured with the Startup Type set to Automatic.

In the DNS console, check the event viewer node, which accesses the DNS event logs, for errors that may indicate a problem with the DNS server or its configuration. If the DNS server gets its TCP/IP configuration from a DHCP server, you should confirm that the DHCP server has a properly configured reservation for the DNS server. A reservation is required to ensure that the DNS server always uses the same IP address.

In some cases, name resolution may be working properly, but the DNS server may be providing incorrect data. Problems can occur if resources records are configured incorrectly, if dynamic updates fail, or if zone transfers fail. To resolve this problem, check the resource record for the resource the client is trying to reach. If the record was manually corrected, check the record for typos or invalid settings. If the record was dynamically created, check the dynamic DNS update configuration of DHCP and DNS. If the DNS server is incorrectly resolving names from a secondary zone, check the zone transfer configuration.

You can log detailed debugging information by enabling Debug Logging in the DNS server's properties dialog box. As Figure 8-12 shows, you enable Debug Logging on the Debug Logging tab. Select Log Packets For Debugging, and then configure the logging options.

Figure 8-12. Enable Debug Logging to log details information for troubleshooting DNS.





MCSE Core Required Exams in a Nutshell
MCSE Core Required Exams in a Nutshell: The required 70: 290, 291, 293 and 294 Exams (In a Nutshell (OReilly))
ISBN: 0596102283
EAN: 2147483647
Year: 2006
Pages: 95

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net