Saturday, July 30, 2011

Manually Setting the IPv6 Address on Windows Server 2008 R2

On many occasions, it is necessary to set the IP addresses manually. This is normally the case for servers, routers, and other devices that have static IP addresses.

To set the IPv6 addressing of a Windows Server 2008 R2 server, execute the following steps:
1. Launch Server Manager.

2. Click on View Network Connections from the options in the left pane of the window.

3. Right-click on the desired Local Area Connection, and select Properties.

4. Click Internet Protocol Version 6 (TCP/IPv6), and select Properties. If the item is not enabled, check the box first.

5. Click the Use the Following IPv6 Address option button.

6. In the IPv6 Address field, type in Fc00:1234:5678:9abc::2, and then press Tab. Notice that the Subnet Prefix Length field auto-populates with “64.” Leave that in place and press Tab to move to the Default Gateway input field.

7. Enter Fc00:1234:5678:9abc::1 for the default gateway.

8. Press Tab again to move to the Use the Following DNS Server Address field. Then press Tab to move to the Preferred DNS Server input field. For this example, use the IPv6 address for this server. In the Preferred DNS Server field, type in the sample IPv6 address Fc00:1234:5678:9abc::2 and leave the Alternate DNS Server field blank.

9. Click OK to close the IPv6 Properties window. Click Close to close the Local Area Connection Properties window.

The DNS server also needs to have a reverse lookup zone created to allow computers to register their IPv6 addresses. This is separate from the IPv4 reverse lookup zone created earlier in the chapter, although it serves the same purpose. To create the IPv6 reverse lookup zone, perform the following steps:

1. Launch Server Manager on the DNS server.

2. Expand the Roles node, DNS Server node, DNS node, and the server node, and select the Reverse Lookup Zones node.

3. Right-click the Reverse Lookup Zones node and select New Zone.

4. Click Next at the Welcome screen.

5. Ensure that Primary Zone and Store the Zone in Active Directory are selected, and then click Next.

6. Select to replicate to all domain controllers in the forest, and then click Next.

7. Select the IPv6 Reverse Lookup Zone option and click Next.

8. Enter FC00:1234:5678:9abc::/64 for the IPv6 address prefix. The reverse lookup zone name will be created automatically. Click Next.

9. Allow only secure updates and click Next.

10. Click Finish to complete the task.

Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)

Tuesday, July 26, 2011

The Teredo Tunneling Protocol

The Teredo tunneling protocol is a protocol that provides IPv6 connectivity through Network Address Translation (NAT) devices that are not IPv6 aware. The Teredo tunneling protocol is described in IETF RFC4380. The Teredo protocol gets around the requirement of the 6to4 tunneling protocol that the tunnel endpoint be a public IPv4 address. The reality of today’s IPv4 Internet is that there is a scarcity of public IPv4 address (the entire rational behind IPv6) and so most hosts will be behind a NAT device.

Teredo encapsulates the IPv6 packets twice: once to encapsulate the IPv6 packet in an IPv4 packet with the IPv4 protocol field set to 41, and a second time to put the resulting IPv4 packet in the message of a IPv4 UDP packet. This double encapsulation gets through the NAT but comes at a heavy cost in protocol overhead. In addition, the Teredo tunnel also exposes the host to scanning attacks because the Teredo tunneling adapter in effect opens a port on the host to entities through the firewall. This port can be discovered and attacked. Thus, due to the overhead and security concerns, the Teredo tunneling protocol is really a tunneling protocol of last resort.

Microsoft’s implementation of the Teredo protocol includes additional measures against IPv6 scanning attacks, including an option of which traffic to accept: from anywhere except the Teredo tunnel (the default), from anywhere including the Teredo tunnel, or only from the local Intranet. The default option prevents scanning of the Teredo tunnel interface. Of course, the host can initiate traffic through the tunnel.

Teredo clients use IPv6 addresses that start with the prefix 2001::/32, otherwise known as the Teredo prefix. The address is somewhat more complicated than the addressing for the other tunneling protocols. The elements of the Teredo address are the following:

» Teredo prefix (32 bits)—This is 2001 for all Teredo addresses, per IETF RFC4380.

» Teredo server IPv4 address (32 bits)—The IPv4 address of the Teredo Server in colon hexadecimal format.

» Flags (16 bits)—This includes a bit for the type of NAT. Microsoft uses two of the bits to set the Universal/Local flag and the Individual/Group flag for the enhanced security. The remaining bits are set to a random number to make scanning attacks more difficult.

» Obscured external port (16 bits)—This is the external UDP port that is assigned by the NAT, but is obscured by an XOR it with FFFF.

» Obscured external address (32 bits)—This is the IPv4 external address of the NAT, but it is obscured by an XOR with FFFFFFFF.

Because of the flag randomization, UDP port assignment, and the obscuring, the final Teredo addresses will vary considerably even within the same Teredo client.

Teredo tunneling components include the following:

» Teredo client—This is an IPv6/IPv4 device that has a Teredo tunneling adapter and communicates with other Teredo clients or IPv6 networks via a Teredo Relay. The Teredo client is typically behind a NAT.

» Teredo server—This is an IPv6/IPv4 device that is connected to both the IPv6 and IPv4 networks. The Teredo server assists with the configuration of Teredo clients.

» Teredo relay—This is an IPv6/IPv4 device that is connected to IPv6 and IPv4 networks. The Teredo relay routes between Teredo clients and IPv6 hosts in the IPv6 network.

» Teredo host-specific relay—This is an IPv6/IPv4 device that is connected to IPv6 and IPv4 networks. It can communicate with the IPv6 network, the IPv4 network, and Teredo clients without a Teredo relay. Windows Server 2008 R2, Windows Server 2008, Windows 7, and Windows Vista can all operate as Teredo clients and Teredo host-specific relays.

The Windows Teredo clients send Router Solicitation messages to Teredo servers. These responses to the router solicitation messages are used to build the Teredo address and what type of NAT is in place.

Once the Teredo address has been determined, the Teredo client can then communicate with Teredo clients. This is facilitated by the Teredo server, which brokers communications between the two Teredo clients during the initial start of communications. Following the initial setup of communications, the two Teredo clients communicate directly.

Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)

Thursday, July 21, 2011

The 6to4 Tunneling Protocol

The 6to4 protocol provides for automatic address assignment and tunneling of IPv6 across the IPv4 Internet. The protocol is detailed in IETF RFC3056. The 6to4 protocol uses the prefix 2002::/16—otherwise known as a 6to4 address. The global address prefix for a given organization takes the form 2002:WWXX:YYZZ::/48, where WWXX:YYZZ is the colon hexadecimal format of the organization’s public IPv4 dotted decimal address w.x.y.z assigned to the router.

The 6to4 protocol only supports IPv6 computer to IPv6 computer communications. It does not support communications between IPv6 and IPv4 computers. Both endpoints must support IPv6.

The 6to4 protocol allows organizations to assign globally routable IPv6 address without needing to connect to the IPv6 Internet or to request an assigned range of IPv6 addresses. Because the IPv6 address is derived from the public assigned IPv4 address, it is guaranteed to be unique.

In addition, the 6to4 address supports a subnet field for organizations with IPv4 subnet address ranges. The format of the 6to4 IPv6 address is shown in Figure 10.23. For example, the public IPv4 address 12.155.166.101 with subnet 255.255.255.128 would automatically generate the global IPv6 prefix 2002:C9B:A665:80::/64.

The 6to4 protocol defines several components that participate in the transmission of packets. These are as follows:

» 6to4 host—A IPv6 device that is configured with a 6to4 address (that is, a 2002::/16 prefix).

» 6to4 router—Routes IPv6 traffic over the IPv4 Internet using 6to4 tunneling.

» 6to4 host/router—An IPv6 device that is configured with a 6to4 address and can also use 6to4 tunneling to communicate with other 6to4 devices over the IPv4 Internet. However, it does not route traffic to other devices.

» 6to4 relay—Forwards 6to4 traffic between the IPv4 Internet and pure IPv6 devices.

Essentially, 6to4 and its components allow IPv6 devices to communicate while residing in the IPv4 world. Figure 10.24 shows the components of 6to4.

Windows Server 2008 R2, Windows 2008, Windows 7, and Windows Vista can function as a 6to4 host/router or a 6to4 router. By default, these operating systems operate as 6to4 host/router components. The Windows IPv6 protocol automatically does the following if there is a public IPv4 address assigned to a network interface:

1. Creates a 6to4 tunnel adapter and assigns it a 6to4 address in the form 2002:WWXX:YYZZ::WWXX:YYZZ for each of the public addresses.

2. Creates a 2002::/16 route to forward all 6to4 addresses to the tunnel adapter.

3. Does a lookup of the FQDN 6to4.ipv6.microsoft.com will give a 6to4 relay address. That address is set as the next hop for the 6to4 tunnel adapter.

The FQDN 6to4.ipv6.microsoft.com is the address of the 6to4 relay that is operated by
Microsoft and allows 6to4 access to the IPv6 Internet. This is a service that Microsoft provides to help with the integration of Microsoft operating systems with IPv6.

To have a system operate as a 6to4 router component, the Internet Connection Sharing
(ICS) feature must be enabled. If ICS is enabled on network interface with an IPv4 address, the IPv6 protocol automatically does the following:

1. Enables IPv6 forwarding on the 6to4 tunneling adapter and on any private network interfaces.

2. Assigns a 6to4 subnet prefix of the form 2002:WWXX:YYZZ:I::/64, where WWXX:YYZZ is the colon hexadecimal form of the IPv4 public IP address and I is the interface index of the private network interface.

3. Sends router advertisements on the private network interface. For any traffic forwarded to other 6to4 sites, the Windows 6to4 router uses the default 2002::/16 route.

Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)

Tuesday, July 19, 2011

The ISATAP Tunneling Protocol

The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) is an IPv6 transition protocol. It provides for the automatic conversion of an IPv4 address to an IPv6 address, as well as a mechanism for setting up a virtual IPv6 network that transmits over an IPv4 network. The protocol does not require any manual configuration.

The components of ISATAP are the following:

» ISATAP host—The ISATAP host communicates IPv6 over IPv4 networks with other ISATAP hosts and with ISATAP routers.

» ISATAP router—The ISATAP router advertises address prefixes to the local ISATAP subnet, forwards ISATAP traffic to IPv6 networks, and acts as the default route for ISATAP hosts.

Link-local addresses are network addresses that are only designed to communicate on a segment and basically allow communications with neighboring devices without needing a globally routable address. They are mandatory in IPv6 and are automatically assigned with the FE80::/10 prefix.

This is useful for deploying IPv6 without having to explicitly define and configure a IPv6 network addressing scheme because it allows IPv6 devices to communicate over IPv4 networks.

The Windows Vista RTM, Windows Server 2003, and Windows XP all automatically enable and configure the ISATAP tunneling adapter if the IPv6 protocol is installed. These operating systems use the name Automatic Tunneling Pseudo-Interface rather than ISATAP to identify the adapter.

The Windows Server 2008 R2, Windows 2008, Windows 7, and Windows Vista SP1 operating systems do not enable the ISATAP tunneling adapter unless they can resolve the name “ISATAP” in to an IPv4 address. The ISATAP address is the IPv4 address of the local ISATAP router. The name resolution can use any of the standard methods to resolve, including DNS, WINS, NetBIOS broadcast, or the LMHOSTS file. When these operating systems are able to resolve the ISATAP address, they configure the ISATAP tunneling adapter and add a default route of ::/0 to the link-local address of the ISATAP router.

ISATAP address IPv4 to IPv6 address translation is done by concatenating a 64-bit prefix with :0000:5EFE:w.x.y.z, where w.x.y.z is the IPv4 address in dotted decimal format. The prefix can be a link-local prefix (that is, FE80::/64), a global prefix (for example, FC00:1234:5678:9abc::/64), or even a global 6to4 prefix (for example, 2002:c9b:a602:1:0::/64), discussed in the next section. Table 10.3 lists some example values for IP address conversions in ISATAP.

The format FE80::5EFE:w.x.y.z is functionally equivalent to the format FE80::5EFE:WWXX:YYZZ, where the dotted decimal IPv4 address format is converted to hexadecimal format. Each decimal number (for example, w) is converted to a two-digit hexadecimal number (for example, WW). In the first example above, the IPv6 address FE80::5EFE:12.155.166.101 would be expressed as FE80::5EFE:0C9B:A665. This format is known as the colon hexadecimal format.

Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)

Friday, July 15, 2011

Comprehending IPv6 Addressing

Comprehending IPv6 addressing can become a steep uphill challenge, as well as hard on the fingers due to all the typing. The addresses are so long that abbreviation mechanisms and conventions are used to ease the burden. However, this makes learning the addressing that much more difficult. Here are a few rules and tips to assist with the future IPv6 change, as well as some conventions that reduce the typing needed to enter the addresses:

» IPv6 DNS records show as AAAA records (or quad A).

» With IPv6 prefixes, a / slash in IPv6 defines the network with addresses (for example, fc00:db8:1234::/48 is fc00:1234:5678:0000:0000:0000:0000:0000 through FC00:0db8:1234:FFFF: FFFF: FFFF: FFFF: FFFF). Thus, FC00:db8:1234::/48 implies that the first 48 bits are assigned to the network portion of the address—4 bits for each hexadecimal digit, visible or not, totaling 16 bits for each segment and 48 bits for three segments. This leaves 80 bits remaining out of a total of 128 bits in the address. 80 bits translates into five groups of four hexadecimal digits. Because each hexadecimal digit represents 4 bits, four multiplied by four, and then by five (for the five groupings), makes 80. After you get the hang of it, it is similar to dealing with “/24” being three groups of eight represented as 255.255.255.0 in IPv4.

» With IPv6 zero compression, consecutive groups of zeros can be subbed with a double “:” (colon). This means that FC00:db8:bc92:0000:0000:1293:91c2:0012 would be the same as FC00:db8:fb92::1293:91c2:0012.

» RFC 2732 dictates that IPv6 address can be used in a URL syntax. As an example, FBAC:FA9A:B6A54:3910:A81C:C1A8:B6A4:A2BB can be literally used in a URL as long as it is enclosed in brackets [ and ], as seen in this example: http://[FBAC:FA9A:B6A54:3910:A81C:C1A8:B6A4:A2BB].

» Loopback for IPv6 is ::1. This might be the only case where an IPv6 address is shorter than the equivalent IPv4 address.

These conventions make it much easier to enter the addresses, if not quite as easy as
IPv4 addresses.

The caveat is that there can be only one double colon used in an IPv6 address to compress consecutive groups of zeros. Otherwise, it would not be possible to determine how many zeros were compressed.

The fc00::/7 prefix is the private reserved IPv6 address range. The private ranges in IPv6 are called the unique local addresses (ULA) and are not globally routable. This is equivalent to the 10.x.x.x, 172.16-31.x.x, and 192.168.x.x IPv4 private addresses. The unique local address range (fc00::/7) is further divided into 2 /8 address ranges. The first is the fc00::/8 range, which is available for private use. The second is the fd00::/8 range, which is to include a random 40-bit string. The local link address is assigned the fe80::/10 range, which is from the second range.

Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)

Monday, July 11, 2011

IPv6 Introduction

The Internet is running out of IP addresses. To resolve this problem, a relatively new technology is being deployed to give us more addresses. This technology is IPv6 and is completely integrated into Windows Server 2008 R2.

You might wonder why there is need for more address space when good old IPv4 provides somewhere in the range of four billion addresses. Unfortunately, there are over 6 billion people on the planet and, thus, not enough IP addresses for each and every person. In this age of ever-advancing technologies and Internet-enabled devices, it isn’t uncommon for a single individual to utilize more than one IP address. For example, an individual might have an Internet connection at home, a workstation in the office, an Internet-enabled phone, and a laptop to use in a cafe. This problem will only become more exacerbated as devices such as refrigerators and coffeemakers become part of the wired world.

IPv6, Internet Protocol Version 6, not only brings a number of new features such as integrated IPSec, QoS, stateless configuration, and so on, but, more important, it will also provide over 340,000,000,000,000,000,000,000,000,000,000,000,000 unique addresses that’s 3.4 x 1038!

IPv6 provides a number of new features over IPv4: vastly improved address space, improved network headers, native support for auto address configuration, and integrated support for IPSec and QoS.

Windows Server 2008 R2’s networking advances are mostly due to the new TCP/IP stack introduced with IPv6 in Windows Server 2008. Highlighted in the following list are a few of the features that are included with Windows Server 2008 R2, derived from the new TCP/IP stack:

» Dual IP layer architecture for IPv6—Windows 2003 required a separate protocol to be installed to enable IPv6 support; whereas in Windows Server 2008 R2, IPv6 is enabled and supported by default. Windows Server 2008 R2 supports the new stack that integrates IPv4 and IPv6, leveraging the fact that IPv4 and IPv6 share common layers (transport and framing).

» Windows Filtering Platform—All layers of the TCP/IP stack can be filtered, enabling Windows Filtering Platform to be more secure, stack integration.

» Protocol stack off-load—By off-loading TCP and/or other protocols to the Network Driver Interface Specification (NDIS) miniport and/or network interface adapters, performance improvements can occur on traffic-intensive servers.

» Restart-less configuration changes—Leveraging the new TCP/IP stack’s ability to retain configuration settings, server restarts to enable configuration changes are no longer necessary.

In the United States, IPv6 is quietly making its way into the mainstream by starting at the edge. Broadband providers in California such as Comcast have already implemented IPv6 for their customers. Countries like China with their recent implementations have opted to move to IPv6 as a default.

From an implementation perspective, Microsoft Internet Acceleration Server (ISA) 2006 does not support IPv6. As a matter of fact, installing the IPv6 protocol stack on an ISA 2006 server is a security risk as it exposes the server directly to the Internet. This has made it difficult for many organizations to start deploying IPv6 in a meaningful way.

Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)

Thursday, July 7, 2011

Troubleshooting Windows Server 2008 R2 DNS

Much has been written about the complexity of DNS, and even more confusion and misconceptions have been written about it. In truth, however, DNS structure is logical, so you can easily troubleshoot it, if you use the proper tools and techniques. A good grasp of these tools and their functionality is a must for proper name-resolution troubleshooting with DNS.


Using the DNS Event Viewer to Diagnose Problems
As any good administrator will know, Event Viewer is the first place to look when troubleshooting. Windows Server 2008 R2 makes it even more straightforward to use because DNS events compiled from Event Viewer are immediately accessible from the DNS Manager Console. Parsing this set of logs can help you troubleshoot DNS replication issues, query problems, and other issues.

For more advanced event log diagnosis, you can turn on Debug Logging on a per-server basis. It is recommended that this functionality be turned on only as required, however, as this can affect server performance and the log files can fill up fast. To enable Debug Logging, follow these steps:

1. Launch Server Manager.
2. Expand the Roles, DNS Server, DNS nodes, and then select the DNS server name.
3. Right-click the server name and choose Properties.
4. Select the Debug Logging tab.
5. Check the Log Packets for Debugging check box.
6. Configure any additional settings as required, and click OK.

By default, the log file is named dns.log and is saved in the c:\windows\system32\dns\ directory. Listing 10.2 shows the debug of the DNS server dc1.companyabc.com of a lookup of the record www.cco.com from the server at 192.168.3.201. You can see from the log that the request was forwarded to the DNS server at 192.168.2.5 and that the results were then sent to the requesting server at 192.168.3.201.

LISTING 10.2 DNS Log File
9/27/2009 11:52:03 AM 0388 PACKET 0000000002425D80 UDP Rcv 192.168.3.201 0002
Q [0001 D NOERROR] A (3)www(3)cco(3)com(10)companyabc(3)com(0)
9/27/2009 11:52:03 AM 0388 PACKET 0000000002425D80 UDP Snd 192.168.3.201 0002 R
Q [8385 A DR NXDOMAIN] A (3)www(3)cco(3)com(10)companyabc(3)com(0)
9/27/2009 11:52:03 AM 0388 PACKET 000000000381E940 UDP Rcv 192.168.3.201 0003
Q [0001 D NOERROR] AAAA (3)www(3)cco(3)com(10)companyabc(3)com(0)
9/27/2009 11:52:03 AM 0388 PACKET 000000000381E940 UDP Snd 192.168.3.201 0003 R
Q [8385 A DR NXDOMAIN] AAAA (3)www(3)cco(3)com(10)companyabc(3)com(0)
9/27/2009 11:52:03 AM 0388 PACKET 00000000032FF460 UDP Rcv 192.168.3.201 0004
Q [0001 D NOERROR] A (3)www(3)cco(3)com(0)
9/27/2009 11:52:03 AM 0388 PACKET 0000000003C74A00 UDP Snd 192.168.2.5 95b5
Q [1001 D NOERROR] A (3)www(3)cco(3)com(0)
9/27/2009 11:52:04 AM 0388 PACKET 0000000003138020 UDP Rcv 192.168.2.5 95b5 R
Q [8081 DR NOERROR] A (3)www(3)cco(3)com(0)
9/27/2009 11:52:04 AM 0388 PACKET 00000000032FF460 UDP Snd 192.168.3.201 0004 R
Q [8081 DR NOERROR] A (3)www(3)cco(3)com(0)
9/27/2009 11:52:04 AM 0388 PACKET 0000000002425D80 UDP Rcv 192.168.3.201 0005
Q [0001 D NOERROR] AAAA (3)www(3)cco(3)com(0)
9/27/2009 11:52:04 AM 0388 PACKET 00000000032FF460 UDP Snd 192.168.2.5 1240
Q [1001 D NOERROR] AAAA (3)www(3)cco(3)com(0)
9/27/2009 11:52:04 AM 0388 PACKET 0000000002F30BE0 UDP Rcv 192.168.2.5 1240 R
Q [8081 DR NOERROR] AAAA (3)www(3)cco(3)com(0)
9/27/2009 11:52:04 AM 0388 PACKET 0000000002425D80 UDP Snd 192.168.3.201 0005 R
Q [8081 DR NOERROR] AAAA (3)www(3)cco(3)com(0)

The DNS log can be very detailed and tedious to read, but provides a wealth of information about exactly what the DNS server is doing. You can get even more detail by selecting the Details check box on the Debug Logging tab, which also enables you to see the data that was returned. Logging does add significantly to the load of the DNS server, so it should only be enabled when troubleshooting and disabled immediately afterwards.


Using Performance Monitor to Monitor DNS
Performance Monitor is a built-in, often-overlooked utility that allows for a great deal of insight into issues in a network. In regard to DNS, many critical DNS counters can be monitored relating to queries, zone transfers, memory utilization, and other important factors.


Client-Side Cache and HOST Resolution Problems
Windows 2000 and higher clients have a built-in client cache for name resolution that caches all information retrieved from name servers. When requesting lookups, the client resolver parses this cache first, before contacting the name server. Items remain in this cache until the TTL expires, the machine is rebooted, or the cache is flushed. In cases where erroneous information has been entered into the client cache, it can be flushed by typing ipconfig /flushdns at the command prompt.

By default, all clients have a file named HOSTS that provides for a simple line-by-line resolution of names to IP addresses. This file is normally located in \%systemroot%\system32\drivers\etc. Problems can occur when these manual entries conflict with DNS, and it is, therefore, wise to ensure that there are not conflicts with this HOSTS file and the DNS database when troubleshooting.


Using the NSLOOKUP Command-Line Utility
The NSLOOKUP command-line utility is perhaps the most useful tool for DNS client troubleshooting. Its functionality is basic, but the information obtained can do wonders for helping to understand DNS problems. NSLOOKUP, in its most basic operation, contacts the default DNS server of a client and attempts to resolve a name that is inputted. For example, to test a lookup on www.companyabc.com, type nslookup www.companyabc.com at the command prompt. Different query types can also be input into NSLOOKUP. For example, you can create simple queries to view the MX and SOA records associated with a specific domain by following these steps:

1. Open a command-prompt instance by choosing Start, All Programs, Accessories, Command Prompt.
2. Type nslookup and press Enter.
3. Type set query=mx and press Enter.
4. Type and press Enter.
5. Type set query=soa and press Enter.
6. Type and press Enter.

NSLOOKUP’s functionality is not limited to these simple lookups. Performing an nslookup /? lists the many functions it is capable of. NSLOOKUP is a tool of choice for many nameresolution problems and is a must in any troubleshooter’s arsenal.


Using the IPCONFIG Command-Line Utility
Another important tool for DNS resolution problems is the IPCONFIG utility, the same utility used for common TCP/IP issues. There are several key functions that IPCONFIG offers in regard to DNS. These functions can be invoked from the command prompt with the right parameter, detailed as follows:

» ipconfig /flushdns—If you experience problems with the client-side cache, the cache itself can be “flushed” through the invocation of the flushdns flag. This removes all previously cached queries that a client might be storing and is particularly useful if a server name has just changed IP addresses and particular clients have trouble connecting to it.

» ipconfig /registerdns—The registerdns flag forces the client to dynamically reregister itself in DNS, if the particular zone supports dynamic updates.

» ipconfig /displaydns—An interesting but not well-known parameter is displaydns. This flag displays the contents of the client-side cache and is useful for troubleshooting specific issues with individual records.


Using the TRACERT Command-Line Utility
The TRACERT utility is a valuable resource that gives you an idea of the path that a DNS query takes when being sent over a network. By directing TRACERT at www.microsoft.com, for example, you can get an idea of how many routers and DNS servers the packet is crossing. The way that TRACERT works is simple, but actually quite interesting. A DNS query that has a TTL of 1 is sent out. Because all routers are supposed to drop the TTL by 1 on each packet that they process, this means that the first router will refuse to forward the packet and send that refusal back to the originator. The originating machine then increments the TTL by 1 and resends the packet. This time the packet will make it past the first router and get refused by the second. This process continues until the destination is met. Needless to say, using this command-line utility is a simple yet effective way of viewing the path that a DNS query takes as it crosses the Internet.


Using the DNSCMD Command-Line Utility
The DNSCMD utility is essentially a command-line version of the MMC DNS console.
Installed as part of the Windows Server 2008 R2 DNS Server role, this utility allows administrators to create zones, modify records, and perform other vital administrative functions via the command line. You can view the full functionality of this utility by typing DNSCMD /? at the command line, as illustrated in Listing 10.3.

LISTING 10.3 DNSCMD Command Options
Usage: DnsCmd []

:
IP address or host name — remote or local DNS server
. — DNS server on local machine

:
/Info — Get server information
/Config — Reset server or zone configuration
/EnumZones — Enumerate zones
/Statistics — Query/clear server statistics data
/ClearCache — Clear DNS server cache
/WriteBackFiles — Write back all zone or root-hint datafile(s)
/StartScavenging — Initiates server scavenging
/IpValidate — Validate remote DNS servers
/ResetListenAddresses — Set server IP address(es) to serve DNS requests
/ResetForwarders — Set DNS servers to forward recursive queries to
/ZoneInfo — View zone information
/ZoneAdd — Create a new zone on the DNS server
/ZoneDelete — Delete a zone from DNS server or DS
/ZonePause — Pause a zone
/ZoneResume — Resume a zone
/ZoneReload — Reload zone from its database (file or DS)
/ZoneWriteBack — Write back zone to file
/ZoneRefresh — Force refresh of secondary zone from master
/ZoneUpdateFromDs — Update a DS integrated zone by data from DS
/ZonePrint — Display all records in the zone
/ZoneResetType — Change zone type
/ZoneResetSecondaries — Reset secondary\notify information for a zone
/ZoneResetScavengeServers — Reset scavenging servers for a zone
/ZoneResetMasters — Reset secondary zone’s master servers
/ZoneExport — Export a zone to file
/ZoneChangeDirectoryPartition — Move a zone to another directory partition
/TrustAnchorsResetType — Change zone type for a trust anchor zone
/EnumRecords — Enumerate records at a name
/RecordAdd — Create a record in zone or RootHints
/RecordDelete — Delete a record from zone, RootHints, or cache
/NodeDelete — Delete all records at a name
/AgeAllRecords — Force aging on node(s) in zone
/TrustAnchorAdd — Create a new trust anchor zone on the DNS server
/TrustAnchorDelete — Delete a trust anchor zone from DNS server or DS
/EnumTrustAnchors — Enumerate records at a name
/EnumDirectoryPartitions — Enumerate directory partitions
/DirectoryPartitionInfo — Get info on a directory partition
/CreateDirectoryPartition — Create a directory partition
/DeleteDirectoryPartition — Delete a directory partition
/EnlistDirectoryPartition — Add DNS server to partition replication scope
/UnenlistDirectoryPartition — Remove DNS server from replication scope
/CreateBuiltinDirectoryPartitions — Create built-in partitions
/ExportSettings — Output settings to DnsSettings.txt in the DNS

server database directory
/OfflineSign — Offline signing zone files, including key generation/
deletion

:
DnsCmd /? — For help info on specific Command

The /config option of the DNSCMD was used to set the Global Names option of the DNS server earlier in the chapter. There is no option in the DNS console to set this value.



Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)

Tuesday, July 5, 2011

Building Fault-Tolerant Windows Server 2008 R2 Systems - Designing Fault-Tolerant Server Disks

Many Windows Server 2008 R2 systems that will be used for NLB or failover clusters are deployed with local disk storage. The local disks commonly store the operating system files as well as the necessary service or application files. Each system that will participate in a cluster should have the local disks and volumes configured exactly the same, including drive letters and any mount point assignments. When local disks are used to provide the operating system and application or service core files, the local disks should be deployed using redundant, fault-tolerant configurations. There are mainly two different ways to add fault tolerance to the local disks in a Windows Server 2008 R2 system. The first is creating redundant arrays of inexpensive disks (RAID) using disk controller configuration utilities (also known as hardware-level RAID), and the second is creating RAID volumes using dynamic disks using the Disk Management console from within the operating system (known as software-level RAID).

Using two or more disks, different RAID-level arrays can be configured to provide fault tolerance that can withstand disk failures and still provide uninterrupted disk access. Implementing hardware-level RAID configured, stored, and managed by the system’s disk controllers is preferred over the software-level RAID configurable within Windows Server 2008 R2. Windows Server 2008 R2 dynamic disk mirrored and RAID-5 volumes are managed by the system and add some load to the system. Additionally, another good reason to provide hardware-level RAID is that the configuration of the disks does not depend on the operating system, which gives administrators greater flexibility when it comes to recovering server systems and performing upgrades. For more information on disk configuration options, refer to Chapter 28 of this book. For detailed information on how to best configure RAID arrays using local disk controllers, refer to the manufacturer’s documentation.

As a best practice, Windows Server 2008 R2 can be deployed with the operating system disks stored on RAID-1, or mirrored, disks and presented to the operating system as the “C” volume. A second volume in the system can be used to store application data and files and, when possible, this data should be placed on different redundant disks or at least on separate volumes to prevent impact to the space available in the operating system volume.

Source of Information : Sams - Windows Server 2008 R2 Unleashed (2010)