这部分描述了 Windows 中与 TCP/IP 相关的 name resolution protocols：Domain Name System (DNS), Windows Internet Name Service (WINS), and Peer Name Resolution Protocol (PNRP).

Domain Name System

DNS is the standard (RFC 1035, et al.) by which Internet names (such as www.microsoft.com) are translated to their corresponding IP addresses. 

A network application that wants to resolve a DNS name to an IP address sends a DNS lookup request using the UDP/IP protocol (TCP/IP is used for requests whose response size exceeds 512 bytes) to a DNS server. DNS servers implement a distributed database of name/IP address pairs that are used to perform translations, and each server maintains the translations for a particular zone. 

DNS is the foundation of naming in Windows and so it is the primary Windows name resolution protocol.

Windows DNS server 实现为一个 Windows service（Dns.exe），包含在 Windows Server 版本中。标准的 DNS 服务器实现依赖文本文件作为数据库，Windows DNS server can be configured to store zone information in Active Directory.

Peer Name Resolution Protocol

对等名称解析协议（PNRP）是一种分布式对等协议（peer-to-peer protocol），它允许在 IPv6 网络上进行动态名称解析和发布（dynamic name resolution and publication）。PNRP 协议允许连接到 Internet 的设备发布 peer names 及关联的 IPv6 地址、以及其它可选信息。Other devices will then resolve the peer name, retrieve the IPv6 address, and establish a connection.

PNRP与DNS 相比具有显著优势，mainly by being distributed, which means that it is essentially serverless, can scale to potentially millions of names, and is fault tolerant and bottleneck free. 

        1.  PNRP includes secure name publication services, changes to name records can be performed from any system. DNS generally requires contacting a DNS server administrator to perform updates. 

        2. PNRP name updates also occur in real time, making it appropriate for highly mobile devices, whereas DNS caches results. 

        3. PNRP allows for naming more than just computers and services by allowing extended information to be published with name records. 

Windows exposes PNRP via a PNRP API for applications and services, as well as by extending the getaddrinfo Winsock API to perform resolution of PNRP IDs (described next) when an address includes the reserved .pnrp.net domain suffix.

PNRP peer names (also called P2P IDs) 由两部分组成：

        ■ Authority    For secure clients (which have their name records signed by a certifying authority), the authority is identified by a SHA-1 hash of an associated public key, and for unsecured clients, it is zero. If a client is secure, PNRP validates the name record before publishing it.

        ■ Classifier    The classifier uses a simple string to identify a service provided by a peer, which allows multiple services to be provided by the same device.

To create a PNRP ID, PNRP hashes the P2P ID and combines it with a unique 128-bit ID called the service location. The service location identifies different instances of the same P2P ID in the same cloud. (PNRP uses two clouds: a global cloud, which corresponds to all IPv6 addresses on the Internet, and the link-local cloud, which corresponds to IPv6 addresses with the fe80::/10 prefix and is analogous to an IPv4 subnet.)

PNRP Resolution and Publication

PNRP name resolution occurs in two phases:

        ■ Endpoint determination    In this phase, the requesting peer determines the IPv6 address associated with the peer responsible for publishing the PNRP ID of the desired service.

        ■ PNRP ID resolution    In this phase, once the requesting peer has located and confirmed the availability of the peer associated with the IPv6 address, it sends a PNRP request message for the PNRP ID of the service being requested. The peer providing the service replies to confirm the PNRP ID and can supply a comment and up to 4 KB of additional data, such as context information related to the service.

During the first phase, PNRP iterates over nodes while locating the publishing node, such that the node performing name resolution will be responsible for contacting nodes that are successively closer to the desired PNRP ID. Each iteration works as follows: Once a peer receives a request message, it performs a lookup in its cache for the requested PNRP ID. If a match is found, the request message is sent directly; otherwise, it is sent to the next closest PNRP ID (by seeing how much of the ID matches).

When a node receives a request message for which it cannot find a PNRP ID, it checks the distance of any other IDs in the cache to the target ID. 

        1. If it finds a node that is closer, the requested node sends a reply to the requesting node, where the reply contains the IPv6 address of the peer that most closely matches the target PNRP ID. The requesting node can then use the IPv6 address to send another query to that address’ node. 

        2. If no node is closer, the requesting node is notified, and that node sends the request to the next closest node. 

Assuming PNRP IDs of 200, 350, 450, 500, and 800, Figure 7-32 depicts a possible endpoint determination phase for an example in which peer A is trying to find the endpoint for PNRP 800 (peer E).

To publish its PNRP ID(s), a peer first sends PNRP publication messages to its closest neighbors (entries in its cache that have IDs that are in the lowest levels) to seed their caches. It then randomly chooses nodes in the cloud that are not neighbors and sends them PNRP name resolution requests for its own PNRP ID. Through a mechanism described earlier, the endpoint determination phase results in the seeding of the PNRP ID across the caches of the random nodes that were chosen in the cloud.