windows server 2008 tcp ip protocols and services microsoft 2008 phần 8 pot

Chapter 15: Domain Name System 325 Monitor 3.1 display). Note that the DNS server that sent this message is authoritative for the record (the Authoritative flag is set to 1) and the message contains all of the requested records (the Truncation flag is set to 0). The Question Entries portion of the message contains the original question entry from the Name Query Request message. The Answer RRs section con- tains a single answer RR for the IPv4 address 10.0.0.100, which the DNS client can cache for 3600 seconds (60 minutes). Resolving Addresses to Names Resolving addresses to names, also known as reverse name resolution, occurs when a DNS client or DNS server sends a DNS server a Name Query Request message containing an FQDN corresponding to an IPv4 address in the reverse namespace, with instructions to return all PTR RRs. For example, the FQDN corresponding to the IPv4 address 131.107.48.28 in the reverse DNS namespace is 28.48.107.131.in-addr.arpa. An example of this message exchange is Capture 15-02, a Network Monitor trace that is included in the \Captures folder on the companion CD-ROM. The following is the DNS Name Query Request message from Capture 15-02 (Frame 1), as displayed with Network Monitor 3.1: Frame: + Ethernet: Etype = Internet IP (IPv4) + Ipv4: Next Protocol = UDP, Packet ID = 13033, Total IP Length = 69 + Udp: SrcPort = 53206, DstPort = DNS(53), Length = 49 - Dns: QueryId = 0xB75C, QUERY (Standard query), Query for 100.0.0.10.in- addr.arpa of type PTR on class Internet QueryIdentifier: 46940 (0xB75C) + Flags: Query, Opcode - QUERY (Standard query), RD, Rcode - Success QuestionCount: 1 (0x1) AnswerCount: 0 (0x0) NameServerCount: 0 (0x0) AdditionalCount: 0 (0x0) - QRecord: 100.0.0.10.in-addr.arpa of type PTR on class Internet QuestionName: 100.0.0.10.in-addr.arpa QuestionType: PTR, Domain name pointer, 12(0xc) QuestionClass: Internet, 1(0x1) In this frame, a DNS client is requesting that the DNS server return all PTR RRs for the FQDN 100.0.0.10.in-addr.arpa. The following is the corresponding DNS Name Query Response message from Capture 15-02 (Frame 2), as displayed with Network Monitor 3.1: Frame: + Ethernet: Etype = Internet IP (IPv4) + Ipv4: Next Protocol = UDP, Packet ID = 1225, Total IP Length = 102 + Udp: SrcPort = DNS(53), DstPort = 53206, Length = 82 - Dns: QueryId = 0xB75C, QUERY (Standard query), Response - Success QueryIdentifier: 46940 (0xB75C) + Flags: Response, Opcode - QUERY (Standard query), AA, RD, RA, Rcode - Success QuestionCount: 1 (0x1) 326 Part IV: Application Layer Protocols and Services AnswerCount: 1 (0x1) NameServerCount: 0 (0x0) AdditionalCount: 0 (0x0) - QRecord: 100.0.0.10.in-addr.arpa of type PTR on class Internet QuestionName: 100.0.0.10.in-addr.arpa QuestionType: PTR, Domain name pointer, 12(0xc) QuestionClass: Internet, 1(0x1) - ARecord: 100.0.0.10.in-addr.arpa of type PTR on class Internet ResourceName: 100.0.0.10.in-addr.arpa ResourceType: PTR, Domain name pointer, 12(0xc) ResourceClass: Internet, 1(0x1) TimeToLive: 3600 (0xE10) ResourceDataLength: 21 (0x15) DomainNamePointer: server1.contoso.com Note that the Answer RRs section in this case contains a single answer RR for the FQDN server1.contoso.com, which the DNS client can cache for 3600 seconds (60 minutes). Resolving Aliases The CNAME RR allows you to create an alias for an FQDN. For example, you can create an alias s1.contoso.com for the FQDN server1.contoso.com. When a DNS client performs for- ward name resolution and the name corresponds to a CNAME record on the DNS server, the DNS server returns multiple records in the answer section: the CNAME record and the records for the aliased name. An example of this message exchange is Capture 15-03, a Network Monitor trace that is included in the \Captures folder on the companion CD-ROM. In Frame 1 of this exchange (not shown), a DNS client is requesting all A records for the name s1.contoso.com. On the DNS server, the s1.contoso.com FQDN corresponds to a CNAME record for the alias server1.contoso.com. The following is the DNS Name Query Response message from Capture 15-03 (Frame 2), as displayed with Network Monitor 3.1: Frame: + Ethernet: Etype = Internet IP (IPv4) + Ipv4: Next Protocol = UDP, Packet ID = 1279, Total IP Length = 98 + Udp: SrcPort = DNS(53), DstPort = 53223, Length = 78 - Dns: QueryId = 0xBC54, QUERY (Standard query), Response - Success QueryIdentifier: 48212 (0xBC54) + Flags: Response, Opcode - QUERY (Standard query), AA, RD, RA, Rcode - Success QuestionCount: 1 (0x1) AnswerCount: 2 (0x2) NameServerCount: 0 (0x0) AdditionalCount: 0 (0x0) - QRecord: s1.contoso.com of type Host Addr on class Internet QuestionName: s1.contoso.com QuestionType: A, IPv4 address, 1(0x1) QuestionClass: Internet, 1(0x1) - ARecord: s1.contoso.com of type CNAME on class Internet ResourceName: s1.contoso.com ResourceType: CNAME, Canonical name for an alias, 5(0x5) ResourceClass: Internet, 1(0x1) Chapter 15: Domain Name System 327 TimeToLive: 3600 (0xE10) ResourceDataLength: 10 (0xA) CName: server1.contoso.com - ARecord: server1.contoso.com of type Host Addr on class Internet ResourceName: server1.contoso.com ResourceType: A, IPv4 address, 1(0x1) ResourceClass: Internet, 1(0x1) TimeToLive: 3600 (0xE10) ResourceDataLength: 4 (0x4) IPAddress: 10.0.0.100 Note that the first answer record is the CNAME record that maps the FQDN s1.contoso.com to the FQDN server1.contoso.com. The second answer record is an A record for the IPv4 address of the FQDN server1.contoso.com. Dynamically Updating DNS DNS dynamic updates, described in RFC 2136, are an exchange of DNS Update and Update Response messages that allows DNS clients to add or delete a specific RR or sets of RRs, known as RRSets, to any zone. Dynamic updates can simplify the process of managing the contents of a DNS zone, especially in an environment that uses automated configuration with the Dynamic Host Configuration Protocol (DHCP). Dynamic update requests can also state prerequisites specified separately from update opera- tions. These can be tested before an update can occur. When prerequisites are used with dynamic updates, the updates are said to be atomic; that is, all prerequisites must be satisfied for the update operation to occur. An example of this message exchange is Capture 15-04, a Network Monitor trace that is included in the \Captures folder on the companion CD-ROM. The following is the DNS Update message from Capture 15-04 (Frame 1), as displayed with Network Monitor 3.1: Frame: + Ethernet: Etype = Internet IP (IPv4) + Ipv4: Next Protocol = UDP, Packet ID = 35, Total IP Length = 156 + Udp: SrcPort = 53285, DstPort = DNS(53), Length = 136 - Dns: QueryId = 0x8EB7, Update, Query for contoso.com of type SOA on class Internet QueryIdentifier: 36535 (0x8EB7) - Flags: Query, Opcode - Update, Rcode - Success QR: (0 ) Query Opcode: (.0101 ) Update 5 AA: ( 0 ) Not authoritative TC: ( 0 ) Not truncated RD: ( 0 ) Recursion not desired RA: ( 0 ) Recursive query support not available Zero: ( 0 ) 0 AuthenticatedData: ( 0 ) Not AuthenticatedData CheckingDisabled: ( 0 ) Not CheckingDisabled Rcode: ( 0000) Success 0 QuestionCount: 1 (0x1) AnswerCount: 1 (0x1) 328 Part IV: Application Layer Protocols and Services NameServerCount: 4 (0x4) AdditionalCount: 0 (0x0) - QRecord: contoso.com of type SOA on class Internet QuestionName: contoso.com QuestionType: SOA, Marks the start of a zone of authority, 6(0x6) QuestionClass: Internet, 1(0x1) - ARecord: VistaPC.contoso.com of type CNAME on class None ResourceName: VistaPC.contoso.com ResourceType: CNAME, Canonical name for an alias, 5(0x5) ResourceClass: None, 254(0xfe) TimeToLive: 0 (0x0) ResourceDataLength: 0 (0x0) - AuthorityRecord: VistaPC.contoso.com of type AAAA on class Any ResourceName: VistaPC.contoso.com ResourceType: AAAA, IPv6 Address, 28(0x1c) ResourceClass: Any, 255(0xff) TimeToLive: 0 (0x0) ResourceDataLength: 0 (0x0) - AuthorityRecord: VistaPC.contoso.com of type Host Addr on class Any ResourceName: VistaPC.contoso.com ResourceType: A, IPv4 address, 1(0x1) ResourceClass: Any, 255(0xff) TimeToLive: 0 (0x0) ResourceDataLength: 0 (0x0) - AuthorityRecord: VistaPC.contoso.com of type AAAA on class Internet ResourceName: VistaPC.contoso.com ResourceType: AAAA, IPv6 Address, 28(0x1c) ResourceClass: Internet, 1(0x1) TimeToLive: 1200 (0x4B0) ResourceDataLength: 16 (0x10) IPv6Address: 2001:DB8:0:0:B500:734B:FE5B:3945 - AuthorityRecord: VistaPC.contoso.com of type Host Addr on class Internet ResourceName: VistaPC.contoso.com ResourceType: A, IPv4 address, 1(0x1) ResourceClass: Internet, 1(0x1) TimeToLive: 1200 (0x4B0) ResourceDataLength: 4 (0x4) IPAddress: 10.0.0.3 In this frame, a DNS client sends a DNS Update message requesting that the DNS server register an A record for the name vistapc.contoso.com with the IPv4 address 10.0.0.3 and an AAAA record for the name vistapc.contoso.com with the IPv6 address 2001:db8:0:0:b500:734b:fe5b:3945. This DNS Update message is not being sent securely. Secure DNS Update messages include a Transaction Signature record in the Additional RRs section of the message. The following is the corresponding DNS Update Response message from Capture 15-04 (Frame 2), as displayed with Network Monitor 3.1: Frame: + Ethernet: Etype = Internet IP (IPv4) + Ipv4: Next Protocol = UDP, Packet ID = 1518, Total IP Length = 156 + Udp: SrcPort = DNS(53), DstPort = 53285, Length = 136 - Dns: QueryId = 0x8EB7, Update, Response - Success Chapter 15: Domain Name System 329 QueryIdentifier: 36535 (0x8EB7) - Flags: Response, Opcode - Update, Rcode - Success QR: (1 ) Response Opcode: (.0101 ) Update 5 AA: ( 0 ) Not authoritative TC: ( 0 ) Not truncated RD: ( 0 ) Recursion not desired RA: ( 0 ) Recursive query support not available Zero: ( 0 ) 0 AuthenticatedData: ( 0 ) Not AuthenticatedData CheckingDisabled: ( 0 ) Not CheckingDisabled Rcode: ( 0000) Success 0 QuestionCount: 1 (0x1) AnswerCount: 1 (0x1) NameServerCount: 4 (0x4) AdditionalCount: 0 (0x0) - QRecord: contoso.com of type SOA on class Internet QuestionName: contoso.com QuestionType: SOA, Marks the start of a zone of authority, 6(0x6) QuestionClass: Internet, 1(0x1) - ARecord: VistaPC.contoso.com of type CNAME on class None ResourceName: VistaPC.contoso.com ResourceType: CNAME, Canonical name for an alias, 5(0x5) ResourceClass: None, 254(0xfe) TimeToLive: 0 (0x0) ResourceDataLength: 0 (0x0) - AuthorityRecord: VistaPC.contoso.com of type AAAA on class Any ResourceName: VistaPC.contoso.com ResourceType: AAAA, IPv6 Address, 28(0x1c) ResourceClass: Any, 255(0xff) TimeToLive: 0 (0x0) ResourceDataLength: 0 (0x0) - AuthorityRecord: VistaPC.contoso.com of type Host Addr on class Any ResourceName: VistaPC.contoso.com ResourceType: A, IPv4 address, 1(0x1) ResourceClass: Any, 255(0xff) TimeToLive: 0 (0x0) ResourceDataLength: 0 (0x0) - AuthorityRecord: VistaPC.contoso.com of type AAAA on class Internet ResourceName: VistaPC.contoso.com ResourceType: AAAA, IPv6 Address, 28(0x1c) ResourceClass: Internet, 1(0x1) TimeToLive: 1200 (0x4B0) ResourceDataLength: 16 (0x10) IPv6Address: 2001:DB8:0:0:B500:734B:FE5B:3945 - AuthorityRecord: VistaPC.contoso.com of type Host Addr on class Internet ResourceName: VistaPC.contoso.com ResourceType: A, IPv4 address, 1(0x1) ResourceClass: Internet, 1(0x1) TimeToLive: 1200 (0x4B0) ResourceDataLength: 4 (0x4) IPAddress: 10.0.0.3 The update response confirms the success of the registration and contains the records that were registered. 330 Part IV: Application Layer Protocols and Services Transferring Zone Information Between DNS Servers There are three methods of performing zone transfer for DNS servers running Windows Server 2008: ■ Traditional zone transfer This method, described in RFC 1034, involves the secondary server requesting a full copy of the zone from the primary server. ■ Incremental zone transfer This method, defined in RFC 1995, requires the DNS server hosting the primary zone to keep a record of the changes that are made between each increment of the zone’s sequence number. The secondary zone can thus request only the changes that occurred since the last time the secondary zone was updated. ■ Active Directory zone transfer In this method, Active Directory zones are replicated to all domain controllers using Active Directory replication. Active Directory replication does not use the DNS protocol. The traditional zone transfer mechanism can be wasteful of network resources if the change in the transferred RRs is small in relation to the overall zone. In such cases, incremental zone transfer is more efficient. The Network Monitor Capture 15-05 (included in the \Captures folder on the companion CD-ROM) provides an example of a traditional zone transfer. In the capture, a secondary DNS server for a zone creates a TCP connection with the primary DNS server and requests a zone transfer. The secondary DNS server requests the zone transfer over the TCP connection; the transfer occurs; and the secondary DNS server terminates the TCP connection. Incremental zone transfers can be more efficient than traditional zone transfers for both large and dynamic zones. However, they place additional processing requirements on the DNS server, which needs to keep track of the zone differences and sends only the changed records. By default, the DNS Server service for Windows Server 2008 uses incremental transfers when possible. The Network Monitor Capture 15-06 (included in the \Captures folder on the companion CD-ROM) provides an example of an incremental zone transfer. In the capture, a secondary DNS server for a zone first queries a primary DNS server for the SOA record and then requests an incremental zone transfer. For this example capture, the changed records fit within a single UDP message. Therefore, the entire incremental zone transfer is done with a single UDP-based reply message (frame 4). If the changes did not fit within a single UDP message, the reply mes- sage would have the Truncated flag set to 1. The secondary server would then create a TCP connection to the primary DNS server and request the zone transfer using TCP. Active Directory replication is a method of zone transfer that can be used only with Windows Server 2008 or Windows Server 2003 domain controllers. Normal DNS zone transfers are pull in nature—the secondary DNS servers pull the zone or zone changes from the primary server. Active Directory replication, on the other hand, is push in nature—the directory Chapter 15: Domain Name System 331 changes are pushed from the domain controller on which the change occurred to the other domain controllers. For zones that do not change often, Active Directory replication ensures that all DNS servers storing the zone are updated quickly. For more dynamic zones this tends to smooth the replication traffic. Active Directory replication does not use the DNS protocol and is not described in this book. Summary DNS has a common message format for DNS Name Query Request and Name Query Response messages and a different common message format for DNS Update and Update Response messages. DNS messages have a fixed-size portion and a variable sized portion. The variable-sized portion contains entries and records to perform name resolution, registra- tion, and zone transfers between DNS servers. DNS name resolution, either for a recursive or iterative query, consists of an exchange of DNS Name Query Request and Name Query Response messages. For successful resolution, the Name Query Response message contains the RRs for the FQDN that was requested. DNS name registration consists of an exchange of DNS Update and Update Response messages. For successful registration, the DNS Update Response message contains the data that was registered. Zone transfers between DNS servers can transfer the entire zone in a full or traditional zone transfer, or just the changes to the zone in an incremental zone transfer. 333 Chapter 16 Windows Internet Name Service (WINS) In this chapter: NetBT Name Service Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 WINS Client and Server Message Exchanges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 Network Basic Input/Output System (NetBIOS) is a protocol that provides commands and support for network name registration and verification, session establishment and termina- tion, reliable connection-oriented session data transfer, unreliable connectionless datagram data transfer, and protocol and adapter monitoring and management. NetBIOS is also a stan- dard application programming interface (API) so that user applications can utilize the services of installed network protocol stacks. The NetBIOS API is not discussed in this chapter. NetBIOS over TCP/IP (NetBT) is the operation of the NetBIOS protocol over the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP) of the TCP/IP protocol stack. Windows Internet Name Service (WINS) is the Windows implementation of a NetBIOS name server (NBNS), which provides a distributed database for registering and resolving NetBIOS names to IP addresses used on your network. This chapter describes the details of NetBT messages for WINS-based name resolution and reg- istration and common NetBT message exchanges between WINS clients and WINS servers. Note This chapter assumes prior knowledge of NetBT including NetBIOS names, NetBIOS name resolution, NetBIOS node types, the components of a WINS infrastructure (WINS client, WINS server, and WINS proxy), and their operation and configuration in Microsoft Windows. For more information, see Chapter 11, “NetBIOS over TCP/IP,” and Chapter 12, “Windows Inter- net Name Service Overview,” of the “TCP/IP Fundamentals for Microsoft Windows” book, located in the \Fundamentals folder on the companion CD-ROM. NetBT Name Service Messages WINS clients and WINS servers communicate by exchanging NetBT name service messages. NetBT messages and protocol operation are defined in RFCs 1001 and 1002. There are many types of NetBT name service messages defined in RFC 1002, which are typically sent as UDP 334 Part IV: Application Layer Protocols and Services messages. Both the WINS client and the WINS server listen on UDP port 137. The types of NetBT name service messages that are described in this chapter are the following: ■ Name Query Request Sent by a WINS client to a WINS server to perform NetBIOS name resolution. ■ Name Query Response Sent by a WINS server to a WINS client to respond to a name query request. There is a positive name query response and a negative name query response. ■ Name Registration Request Sent by a WINS client to a WINS server to perform name registration. ■ Name Registration Response Sent by a WINS server to a WINS client to respond to a name registration request. There is a positive name registration response and a negative name registration response. ■ Wait Acknowledgment Sent by a WINS server to a WINS client during name registra- tion when confirming the ownership of an existing name previously registered by another client. ■ Name Refresh Request Sent by a WINS client to a WINS server to refresh a name that was previously registered. The response to a name refresh request is a name registration response. ■ Name Release Request Sent by a WINS client to a WINS server to release the registra- tion of a name that was previously registered. ■ Name Release Response Sent by a WINS server to a WINS client to respond to a name release request. There is a positive name release response and a negative name release response. More Info All of the RFCs referenced in this chapter can be found in the \Standards\Chap16_WINS folder on the companion CD-ROM. NetBIOS Name Service Messages NetBIOS name service messages share a common structure, as shown in Figure 16-1. NetBIOS name service messages consist of the following: ■ Name Service header Fixed length (12 bytes long), containing information about the type of name service message and the numbers of the other records in the message. ■ Question entries Variable length for NetBIOS Name Registration, Refresh, or Release messages. This portion of the message contains the NetBIOS name being acted on by the message. [...]... server can return a list of other name servers that can be contacted to resolve the name Windows Server 20 08 and Windows Vista-based WINS clients set this flag to 1 for all name queries If the flag is set to 1 in a name service message sent to a WINS server running Windows Server 20 08, the WINS server sets it to 1 in the corresponding reply Windows Server 20 08 does not support iterative NetBIOS name... + Ethernet: Etype = Internet IP (IPv4) + Ipv4: Next Protocol = UDP, Packet ID = 73, Total IP Length = 78 - Udp: SrcPort = NETBIOS Name Service(137), DstPort = NETBIOS Name Service(137), Length = 58 SourcePort: NETBIOS Name Service(137), 137(0x89) DestinationPort: NETBIOS Name Service(137), 137(0x89) TotalLength: 58 (0x3A) Checksum: 40 28 (0xFBC) - Nbtns: Query Request for SERVER1 Workstation Service... attributes received from the client in messages transmitted to a RADIUS server There are two types of RADIUS attributes: standard attributes and vendor-specific attributes (VSAs) Standard attributes are defined in RFCs 286 5 through 286 9 and are used by all RADIUS clients and servers VSAs are proprietary Not all RADIUS clients and servers implement all VSAs For more information, see the section “Vendor-Specific... Monitor 3.1: Frame: + Ethernet: Etype = Internet IP (IPv4) + Ipv4: Next Protocol = UDP, Packet ID = 189 3, Total IP Length = 84 + Udp: SrcPort = NETBIOS Name Service(137), DstPort = NETBIOS Name Service(137), Length = 64 - Nbtns: Query Response, Requested name doesn’t exist for SERVER9 9 Workstation Service TransactionId: 36171 (0x8D4B) - Flag: 34179 (0x8 583 ) R: (1 .) Response OPCode: (.0000 ) Query... WINS server release and remove the registration of the NetBIOS name VISTAPC with the IP address 10.0.0.3 The following is the corresponding Name Release Response message from Capture 16-06 (Frame 2), as displayed with Network Monitor 3.1: 352 Part IV: + + + - Application Layer Protocols and Services Frame: Ethernet: Etype = Internet IP (IPv4) Ipv4: Next Protocol = UDP, Packet ID = 1941, Total IP. .. prior knowledge of the components of a RADIUS infrastructure and their operation and configuration in Microsoft Windows For more information, see Chapter 14, “Virtual Private Networking,” of the TCP/ IP Fundamentals for Microsoft Windows book, located in the \Fundamentals folder on the companion CD-ROM RADIUS Messages RADIUS clients and RADIUS servers communicate by exchanging RADIUS messages There are... RADIUS server or RADIUS proxy listens on UDP port 181 2 for incoming authentication messages and on UDP port 181 3 for incoming accounting messages RADIUS clients use a 353 354 Part IV: Application Layer Protocols and Services dynamically allocated UDP port for both authentication messages and accounting messages Older versions of RADIUS used UDP port 1645 for authentication and authorization messages and. .. Transmission Control Protocol (TCP) Most RADIUS servers, including the Network Policy Server (NPS) service in Windows Server 20 08, allow you to configure the UDP ports that the RADIUS server listens on for incoming authentication and accounting messages The types of RADIUS messages are the following: ■ Access-Request Sent by a RADIUS client to request authentication and authorization for a network... Part IV: Application Layer Protocols and Services WINS Client and Server Message Exchanges This section describes common message exchanges between WINS clients and servers for the following: ■ Resolving NetBIOS names to IP addresses ■ Registering NetBIOS names ■ Renewing NetBIOS names ■ Releasing NetBIOS names Resolving NetBIOS Names to IP Addresses Resolving NetBIOS names to IP addresses occurs when... follows: 3 58 Part IV: Application Layer Protocols and Services Table 17-2 Common RADIUS Attributes Attribute Type (Decimal) Attribute Name Purpose of Attribute 1 PPP 2 Serial Line Internet Protocol (SLIP) 3 AppleTalk Remote Access Protocol (ARAP) 4 Gandalf proprietary SingleLink/MultiLink protocol 6 X.75 Synchronous 8 Framed-IPAddress This attribute is included in accounting requests and indicates the IP address . client, WINS server, and WINS proxy), and their operation and configuration in Microsoft Windows. For more information, see Chapter 11, “NetBIOS over TCP/ IP, ” and Chapter 12, Windows Inter- net. a name service message sent to a WINS server running Windows Server 20 08, the WINS server sets it to 1 in the corresponding reply. Windows Server 20 08 does not support iterative NetBIOS name. DNS truncation, RFC 1001 describes the use of TCP to obtain the original datagram. Windows Server 20 08 and Windows Vista do not support the use of TCP for NetBIOS name service messages. Therefore,