Internet Engineering Task Force (IETF) C. Huitema
Request for Comments: 8117 Private Octopus Inc.
Category: Informational D. Thaler
ISSN: 2070-1721 Microsoft
R. Winter
University of Applied Sciences Augsburg
March 2017
Internet Engineering Task Force (IETF) C. Huitema
Request for Comments: 8117 Private Octopus Inc.
Category: Informational D. Thaler
ISSN: 2070-1721 Microsoft
R. Winter
University of Applied Sciences Augsburg
March 2017
Current Hostname Practice Considered Harmful
目前的做法被认为是有害的
Abstract
摘要
Giving a hostname to your computer and publishing it as you roam from one network to another is the Internet's equivalent of walking around with a name tag affixed to your lapel. This current practice can significantly compromise your privacy, and something should change in order to mitigate these privacy threats.
在你从一个网络漫游到另一个网络时，给你的计算机提供一个主机名并发布它，这相当于在你的翻领上贴上一个姓名标签。目前的做法可能会严重损害您的隐私，为了缓解这些隐私威胁，应该进行一些更改。
There are several possible remedies, such as fixing a variety of protocols or avoiding disclosing a hostname at all. This document describes some of the protocols that reveal hostnames today and sketches another possible remedy, which is to replace static hostnames by frequently changing randomized values.
有几种可能的补救措施，例如修复各种协议或避免公开主机名。本文档介绍了目前公开主机名的一些协议，并概述了另一种可能的补救方法，即通过频繁更改随机值来替换静态主机名。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8117.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8117.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Naming Practices . . . . . . . . . . . . . . . . . . . . . . 3
3. Partial Identifiers . . . . . . . . . . . . . . . . . . . . . 4
4. Protocols That Leak Hostnames . . . . . . . . . . . . . . . . 5
4.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. DNS Address to Name Resolution . . . . . . . . . . . . . 5
4.3. Multicast DNS . . . . . . . . . . . . . . . . . . . . . . 6
4.4. Link-Local Multicast Name Resolution . . . . . . . . . . 6
4.5. DNS-Based Service Discovery . . . . . . . . . . . . . . . 7
4.6. NetBIOS-over-TCP . . . . . . . . . . . . . . . . . . . . 7
5. Randomized Hostnames as a Remedy . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Informative References . . . . . . . . . . . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Naming Practices . . . . . . . . . . . . . . . . . . . . . . 3
3. Partial Identifiers . . . . . . . . . . . . . . . . . . . . . 4
4. Protocols That Leak Hostnames . . . . . . . . . . . . . . . . 5
4.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. DNS Address to Name Resolution . . . . . . . . . . . . . 5
4.3. Multicast DNS . . . . . . . . . . . . . . . . . . . . . . 6
4.4. Link-Local Multicast Name Resolution . . . . . . . . . . 6
4.5. DNS-Based Service Discovery . . . . . . . . . . . . . . . 7
4.6. NetBIOS-over-TCP . . . . . . . . . . . . . . . . . . . . 7
5. Randomized Hostnames as a Remedy . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Informative References . . . . . . . . . . . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
There is a long established practice of giving names to computers. In the Internet protocols, these names are referred to as "hostnames" [RFC7719]. Hostnames are normally used in conjunction with a domain name suffix to build the Fully Qualified Domain Name (FQDN) of a host [RFC1983]. However, it is common practice to use the hostname without further qualification in a variety of applications from file sharing to network management. Hostnames are typically published as part of domain names and can be obtained through a variety of name lookup and discovery protocols.
给计算机命名是一种由来已久的做法。在互联网协议中，这些名称被称为“主机名”[RFC7719]。主机名通常与域名后缀一起使用，以构建主机的完全限定域名（FQDN）[RFC1983]。但是，在从文件共享到网络管理的各种应用程序中，通常使用主机名而无需进一步限定。主机名通常作为域名的一部分发布，可以通过各种名称查找和发现协议获得。
Hostnames have to be unique within the domain in which they are created and used. They do not have to be globally unique identifiers, but they will always be at least partial identifiers, as discussed in Section 3.
主机名在创建和使用它们的域中必须是唯一的。它们不必是全局唯一标识符，但它们将始终至少是部分标识符，如第3节所述。
The disclosure of information through hostnames creates a problem for mobile devices. Adversaries that monitor a remote network such as a Wi-Fi hot spot can obtain the hostname through passive monitoring or active probing of a variety of Internet protocols, such as DHCP or Multicast DNS (mDNS). They can correlate the hostname with various other information extracted from traffic analysis and other information sources, and they can potentially identify the device, device properties, and its user [TRAC2016].
通过主机名泄露信息给移动设备带来了问题。监视远程网络（如Wi-Fi热点）的对手可以通过被动监视或主动探测各种Internet协议（如DHCP或多播DNS（MDN））来获取主机名。它们可以将主机名与从流量分析和其他信息源中提取的各种其他信息相关联，并可能识别设备、设备属性及其用户[TRAC2016]。
There are many reasons to give names to computers. This is particularly true when computers operate on a network. Operating systems like Microsoft Windows or Unix assume that computers have a "hostname." This enables users and administrators to do things such as ping a computer, add its name to an access control list, remotely mount a computer disk, or connect to the computer through tools such as telnet or remote desktop. Other operating systems maintain multiple hostnames for different purposes, e.g., for use with certain protocols such as mDNS.
给计算机命名有很多理由。当计算机在网络上运行时尤其如此。Microsoft Windows或Unix等操作系统假定计算机具有“主机名”。这使用户和管理员能够执行诸如ping计算机、将其名称添加到访问控制列表、远程装载计算机磁盘或通过telnet或远程桌面等工具连接到计算机等操作。其他操作系统出于不同目的维护多个主机名，例如，与某些协议（如MDN）一起使用。
In most consumer networks, naming is pretty much left to the discretion of the user. Some will pick names of planets or stars, others will pick names of fruits or flowers, and still others will pick whatever suits their mood when they unwrap the device. As long as users are careful to not pick a name already in use on the same network, anything goes. Very often, however, the operating system suggests a hostname at the time of installation, which can contain the user name, the login name, and information learned from the device itself such as the brand, model, or maker of the device [TRAC2016].
在大多数消费者网络中，命名基本上由用户自行决定。一些人会选择行星或恒星的名字，其他人会选择水果或花朵的名字，还有一些人会在打开设备时选择适合他们心情的任何东西。只要用户小心不要选择一个已经在同一网络上使用的名称，任何事情都会发生。但是，操作系统通常在安装时建议主机名，其中可以包含用户名、登录名以及从设备本身获取的信息，如设备的品牌、型号或制造商[TRAC2016]。
In large organizations, collisions are more likely and a more structured approach is necessary. In theory, organizations could use multiple DNS subdomains to ease the pressure on uniqueness, but in practice many don't and insist on unique flat names, if only to simplify network management. To ensure unique names, organizations will set naming guidelines and enforce some kind of structured naming. For example, within the Microsoft corporate network, computer names are derived from the login name of the main user, which leads to names like "huitema-test2" for a machine that one of the authors used to test software.
在大型组织中，冲突的可能性更大，需要一种更结构化的方法。理论上，组织可以使用多个DNS子域来缓解对唯一性的压力，但实际上许多组织不这样做，并且坚持使用唯一的平面名称，即使只是为了简化网络管理。为了确保名称的唯一性，各组织将制定命名准则并实施某种结构化命名。例如，在Microsoft公司网络中，计算机名是从主要用户的登录名派生出来的，这导致了一台机器的名称，如“huitema-test2”，作者之一使用该机器测试软件。
There is less pressure to assign names to small devices including, for example, smart phones, as these devices typically do not enable sharing of their disks or remote login. As a consequence, these devices often have manufacturer-assigned names, which vary from generic names like "Windows Phone" to completely unique names like "BrandX-123456-7890-abcdef" and often contain the name of the device owner, the device's brand name, and often also a hint as to which language the device owner speaks [TRAC2016].
为小型设备（例如智能手机）分配名称的压力较小，因为这些设备通常不支持共享磁盘或远程登录。因此，这些设备通常有制造商指定的名称，这些名称从“Windows Phone”等通用名称到“BrandX-123456-7890-abcdef”等完全唯一的名称不等，并且通常包含设备所有者的名称、设备的品牌名称，以及设备所有者使用哪种语言的提示[TRAC2016]。
Suppose an adversary wants to track the people connecting to a specific Wi-Fi hot spot, for example, in a railroad station. Assume that the adversary is able to retrieve the hostname used by a specific laptop. That, in itself, might not be enough to identify the laptop's owner. Suppose, however, that the adversary observes that the laptop name is "dthaler-laptop" and that the laptop has established a VPN connection to the Microsoft corporate network. The two pieces of information, put together, firmly point to Dave Thaler, employed by Microsoft. The identification is successful.
假设对手想要跟踪连接到特定Wi-Fi热点的人，例如，在火车站。假设对手能够检索特定笔记本电脑使用的主机名。这本身可能不足以确定笔记本电脑的所有者。但是，假设对手观察到笔记本电脑名称为“dthaler laptop”，并且笔记本电脑已建立到Microsoft公司网络的VPN连接。这两条信息放在一起，坚定地指向了微软雇佣的戴夫·泰勒。鉴定成功。
In the example, we saw a login name inside the hostname, and that certainly helped identification. But generic names like "jupiter" or "rosebud" also provide partial identification, especially if the adversary is capable of maintaining a database recording, among other information, the hostnames of devices used by specific users. Generic names are picked from vocabularies that include thousands of potential choices. Finding the name reduces the scope of the search significantly. Other information such as the visited sites will quickly complement that data and can lead to user identification.
在这个例子中，我们在主机名中看到了一个登录名，这当然有助于识别。但是像“jupiter”或“rosebud”这样的通用名称也提供了部分识别，特别是如果对手能够维护数据库记录，以及其他信息，特定用户使用的设备的主机名。通用名称是从包含数千种潜在选择的词汇表中挑选出来的。查找名称可以显著减少搜索范围。其他信息，如访问的站点，将快速补充该数据，并可导致用户识别。
Also, the special circumstances of the network can play a role. Experiments on operational networks such as the IETF meeting network have shown that, with the help of external data such as the publicly available IETF attendees list or other data sources such as
此外，网络的特殊情况也可以发挥作用。在IETF会议网络等运营网络上的实验表明，借助外部数据（如公开的IETF与会者名单）或其他数据源（如
Lightweight Directory Access Protocol (LDAP) servers on the network [TRAC2016], the identification of the device owner can become trivial given only partial identifiers in a hostname.
网络上的轻型目录访问协议（LDAP）服务器[TRAC2016]，如果主机名中只有部分标识符，那么设备所有者的标识可能变得微不足道。
Unique names assigned by manufacturers do not directly encode a user identifier, but they have the property of being stable and unique to the device in a large context. A unique name like "BrandX-123456-7890-abcdef" allows efficient tracking across multiple domains. In theory, this only allows tracking of the device but not of the user. However, an adversary could correlate the device to the user through other means, for example, the one-time capture of some cleartext traffic. Adversaries could then maintain databases linking a unique hostname to a user identity. This will allow efficient tracking of both the user and the device.
制造商分配的唯一名称不会直接编码用户标识符，但它们具有在大型环境中对设备稳定且唯一的特性。像“BrandX-123456-7890-abcdef”这样的唯一名称允许跨多个域进行有效跟踪。理论上，这只允许跟踪设备，而不允许跟踪用户。然而，对手可以通过其他方式将设备与用户关联起来，例如，一次性捕获一些明文通信量。然后，对手可以维护将唯一主机名链接到用户身份的数据库。这将允许有效跟踪用户和设备。
Many IETF protocols can leak the "hostname" of a computer. A non-exhaustive list includes DHCP, DNS address to name resolution, Multicast DNS, Link-local Multicast Name Resolution, and DNS service discovery.
许多IETF协议可能泄漏计算机的“主机名”。非详尽列表包括DHCP、DNS地址到名称解析、多播DNS、链路本地多播名称解析和DNS服务发现。
Shortly after connecting to a new network, a host can use DHCP [RFC2131] to acquire an IPv4 address and other parameters [RFC2132]. A DHCP query can disclose the "hostname." DHCP traffic is sent to the broadcast address and can be easily monitored, enabling adversaries to discover the hostname associated with a computer visiting a particular network. DHCPv6 [RFC3315] shares similar issues.
连接到新网络后不久，主机可以使用DHCP[RFC2131]获取IPv4地址和其他参数[RFC2132]。DHCP查询可以公开“主机名”。DHCP通信被发送到广播地址，并且可以轻松监控，从而使对手能够发现与访问特定网络的计算机相关联的主机名。DHCPv6[RFC3315]也有类似的问题。
The problems with the hostname and FQDN parameters in DHCP are analyzed in [RFC7819] and [RFC7824]. Possible mitigations are described in [RFC7844].
[RFC7819]和[RFC7824]中分析了DHCP中主机名和FQDN参数的问题。[RFC7844]中描述了可能的缓解措施。
The domain name service design [RFC1035] includes the specification of the special domain "in-addr.arpa" for resolving the name of the computer using a particular IPv4 address, using the PTR format defined in [RFC1033]. A similar domain, "ip6.arpa", is defined in [RFC3596] for finding the name of a computer using a specific IPv6 address.
域名服务设计[RFC1035]包括特殊域“in addr.arpa”的规范，用于使用[RFC1033]中定义的PTR格式，使用特定IPv4地址解析计算机名称。[RFC3596]中定义了一个类似的域“ip6.arpa”，用于查找使用特定IPv6地址的计算机的名称。
Adversaries who observe a particular address in use on a specific network can try to retrieve the PTR record associated with that address and thus the hostname of the computer, or even the FQDN of
观察特定网络上使用的特定地址的对手可以尝试检索与该地址相关联的PTR记录，从而检索计算机的主机名，甚至服务器的FQDN
that computer. The retrieval may not be useful in many IPv4 networks due to the prevalence of NAT, but it could work in IPv6 networks. Other name lookup mechanisms, such as [RFC4620], share similar issues.
那台电脑。由于NAT的流行，检索在许多IPv4网络中可能没有用处，但它可以在IPv6网络中工作。其他名称查找机制，如[RFC4620]，也有类似的问题。
Multicast DNS (mDNS) is defined in [RFC6762]. It enables hosts to send DNS queries over multicast and to elicit responses from hosts participating in the service.
[RFC6762]中定义了多播DNS（MDN）。它使主机能够通过多播发送DNS查询，并从参与服务的主机获取响应。
If an adversary suspects that a particular host is present on a network, the adversary can send mDNS requests to find, for example, the A or AAAA records associated with the hostname in the ".local" domain. A positive reply will confirm the presence of the host.
如果对手怀疑网络上存在特定主机，则对手可以发送mDNS请求，以查找与“.local”域中的主机名关联的a或AAAA记录。肯定答复将确认主机的存在。
When a new responder starts, it must send a set of multicast queries to verify that the name that it advertises is unique on the network and to populate the caches of other mDNS hosts. Adversaries can monitor this traffic and discover the hostname of computers as they join the monitored network.
当新响应程序启动时，它必须发送一组多播查询，以验证其播发的名称在网络上是否唯一，并填充其他MDN主机的缓存。对手可以监视此流量，并在加入受监视的网络时发现计算机的主机名。
mDNS further allows queries to be sent via unicast to port 5353. An adversary might decide to use unicast instead of multicast in order to hide from, e.g., intrusion detection systems.
mDNS还允许通过单播将查询发送到端口5353。对手可能决定使用单播而不是多播，以躲避入侵检测系统等。
Link-Local Multicast Name Resolution (LLMNR) is defined in [RFC4795]. The specification did not achieve consensus as an IETF standard, but it is widely deployed. Like mDNS, it enables hosts to send DNS queries over multicast and to elicit responses from computers implementing the LLMNR service.
链路本地多播名称解析（LLMNR）在[RFC4795]中定义。该规范并未作为IETF标准达成共识，但已被广泛部署。与MDN一样，它使主机能够通过多播发送DNS查询，并从实现LLMNR服务的计算机获取响应。
Like mDNS, LLMNR can be used by adversaries to confirm the presence of a specific host on a network by issuing a multicast request to find the A or AAAA records associated with the hostname in the ".local" domain.
与MDN一样，LLMNR也可以被对手使用，通过发出多播请求来查找与“.local”域中的主机名相关联的a或AAAA记录，从而确认网络上是否存在特定主机。
When an LLMNR responder starts, it sends a set of multicast queries to verify that the name that it advertises is unique on the network. Adversaries can monitor this traffic and discover the hostname of computers as they join the monitored network.
当LLMNR响应程序启动时，它会发送一组多播查询，以验证其播发的名称在网络上是唯一的。对手可以监视此流量，并在加入受监视的网络时发现计算机的主机名。
DNS-based Service Discovery (DNS-SD) is described in [RFC6763]. It enables participating hosts to retrieve the location of services proposed by other hosts. It can be used with DNS servers or in conjunction with mDNS in a serverless environment.
[RFC6763]中描述了基于DNS的服务发现（DNS-SD）。它使参与主机能够检索其他主机建议的服务的位置。它可以与DNS服务器一起使用，也可以与无服务器环境中的MDN一起使用。
Participating hosts publish a service described by an "instance name", which is typically chosen by the user responsible for the publication. While this is obviously an active disclosure of information, privacy aspects can be mitigated by user control. Services should only be published when deciding to do so, and the information disclosed in the service name should be well under the control of the device's owner.
参与主机发布由“实例名称”描述的服务，该名称通常由负责发布的用户选择。虽然这显然是信息的主动披露，但用户控制可以缓解隐私方面的问题。只有在决定发布服务时才应发布服务，并且服务名称中披露的信息应完全在设备所有者的控制之下。
In theory, there should not be any privacy issue, but in practice the publication of a service also forces the publication of the hostname due to a chain of dependencies. The service name is used to publish a PTR record announcing the service. The PTR record typically points to the service name in the local domain. The service names, in turn, are used to publish TXT records describing service parameters and SRV records describing the service location.
理论上，不应该存在任何隐私问题，但在实践中，由于一系列依赖关系，服务的发布也会强制发布主机名。服务名称用于发布宣布服务的PTR记录。PTR记录通常指向本地域中的服务名称。服务名称依次用于发布描述服务参数的TXT记录和描述服务位置的SRV记录。
SRV records are described in [RFC2782]. Each record contains four parameters: priority, weight, port number, and hostname. While the service name published in the PTR record is chosen by the user, the "hostname" in the SRV record is indeed the hostname of the device.
[RFC2782]中描述了SRV记录。每个记录包含四个参数：优先级、重量、端口号和主机名。当用户选择PTR记录中发布的服务名称时，SRV记录中的“主机名”实际上就是设备的主机名。
Adversaries can monitor the mDNS traffic associated with DNS-SD and retrieve the hostname of computers advertising any service with DNS-SD.
对手可以监视与DNS-SD关联的mDNS流量，并检索使用DNS-SD发布任何服务的计算机的主机名。
Amongst other things, NetBIOS-over-TCP [RFC1002] implements a name registration and resolution mechanism called the NetBIOS Name Service. In practice, NetBIOS resource names are often based on hostnames.
除此之外，TCP上的NetBIOS[RFC1002]实现了名为NetBIOS名称服务的名称注册和解析机制。实际上，NetBIOS资源名称通常基于主机名。
NetBIOS allows an application to register resource names and to resolve such names to IP addresses. In environments without a NetBIOS Name Server, the protocol makes extensive use of broadcasts from which resource names can be easily extracted. NetBIOS also allows querying for the names registered by a node directly (node status).
NetBIOS允许应用程序注册资源名称并将这些名称解析为IP地址。在没有NetBIOS名称服务器的环境中，该协议广泛使用广播，可以轻松地从广播中提取资源名称。NetBIOS还允许查询由节点直接注册的名称（节点状态）。
There are several ways to remedy the hostname practices. We could instruct people to just turn off any protocol that leaks hostnames, at least when they visit some "insecure" place. We could also examine each particular standard that publishes hostnames and somehow fix the corresponding protocols. Or, we could attempt to revise the way devices manage the hostname parameter.
有几种方法可以纠正主机名做法。我们可以指示人们关闭任何泄露主机名的协议，至少当他们访问某个“不安全”的地方时是这样。我们还可以检查发布主机名的每个特定标准，并以某种方式修复相应的协议。或者，我们可以尝试修改设备管理主机名参数的方式。
There is a lot of merit in turning off unneeded protocols when visiting insecure places. This amounts to attack-surface reduction and is clearly beneficial -- this is an advantage of the stealth mode defined in [RFC7288]. However, there are two issues with this advice. First, it relies on recognizing which networks are secure or insecure. This is hard to automate, but relying on end-user judgment may not always provide good results. Second, some protocols such as DHCP cannot be turned off without losing connectivity, which limits the value of this option. Also, the services that rely on protocols that leak hostnames such as mDNS will not be available when switched off. In addition, not always are hostname-leaking protocols well-known, as they might be proprietary and come with an installed application instead of being provided by the operating system.
在访问不安全的地方时，关闭不必要的协议有很多优点。这相当于减少攻击面，显然是有益的——这是[RFC7288]中定义的隐身模式的优势。然而，这一建议存在两个问题。首先，它依赖于识别哪些网络是安全的或不安全的。这很难实现自动化，但依靠最终用户的判断可能并不总能提供良好的结果。其次，某些协议（如DHCP）无法在不丢失连接的情况下关闭，这限制了此选项的价值。此外，依赖于泄露主机名（如MDN）的协议的服务在关闭时将不可用。此外，主机名泄漏协议并不总是广为人知的，因为它们可能是专有的，并且随安装的应用程序而来，而不是由操作系统提供。
It may be possible in many cases to examine a protocol and prevent it from leaking hostnames. This is, for example, what is attempted for DHCP in [RFC7844]. However, it is unclear that we can identify, revisit, and fix all the protocols that publish hostnames. In particular, this is impossible for proprietary protocols.
在许多情况下，可以检查协议并防止它泄漏主机名。例如，这就是[RFC7844]中DHCP的尝试。但是，我们是否能够识别、重新访问和修复发布主机名的所有协议尚不清楚。特别是，这对于专有协议是不可能的。
We may be able to mitigate most of the effects of hostname leakage by revisiting the way platforms handle hostnames. In a way, this is similar to the approach of Media Access Control (MAC) address randomization described in [RFC7844]. Let's assume that the operating system, at the time of connecting to a new network, picks a random hostname and starts publicizing that random name in protocols such as DHCP or mDNS, instead of the static value. This will render monitoring and identification of users by adversaries much more difficult without preventing protocols such as DNS-SD from operating as expected. This, of course, has implications on the applications making use of such protocols, e.g., when the hostname is being displayed to users of the application. They will not as easily be able to identify, e.g., network shares or services based on the hostname carried in the underlying protocols. Also, the generation of new hostnames should be synchronized with the change of other tokens used in network protocols such as the MAC or IP address to prevent correlation of this information. For example, if the IP
通过重新研究平台处理主机名的方式，我们可以减轻主机名泄漏的大部分影响。在某种程度上，这类似于[RFC7844]中描述的媒体访问控制（MAC）地址随机化方法。假设在连接到新网络时，操作系统选择一个随机主机名，并开始在协议（如DHCP或MDN）中公布该随机名称，而不是静态值。如果不阻止DNS-SD等协议按预期运行，这将使对手对用户的监视和识别变得更加困难。当然，这对使用此类协议的应用程序有影响，例如，当主机名显示给应用程序的用户时。例如，他们将无法根据基础协议中携带的主机名轻松识别网络共享或服务。此外，新主机名的生成应与网络协议（如MAC或IP地址）中使用的其他令牌的更改同步，以防止此信息的关联。例如，如果IP
address changes but the hostname stays the same, the new IP address can be correlated to belong to the same device based on a leaked hostname.
地址更改但主机名保持不变，新IP地址可以基于泄漏的主机名关联为属于同一设备。
Some operating systems, including Windows, support "per network" hostnames, but some other operating systems only support "global" hostnames. In that case, changing the hostname may be difficult if the host is multihomed, as the same name will be used on several networks. Other operating systems already use potentially different hostnames for different purposes, which might be a good model to combine both static hostnames and randomized hostnames based on their potential use and threat to a user's privacy.
包括Windows在内的某些操作系统支持“每网络”主机名，但其他一些操作系统仅支持“全局”主机名。在这种情况下，如果主机是多主机的，更改主机名可能会很困难，因为在多个网络上会使用相同的名称。其他操作系统已经为不同的目的使用了可能不同的主机名，这可能是一个很好的模型，可以根据静态主机名和随机主机名的潜在用途和对用户隐私的威胁来组合它们。
Obviously, further studies are required before the idea of randomized hostnames can be implemented.
显然，在实现随机主机名的想法之前，还需要进一步的研究。
This document does not introduce any new protocol. It does point to potential privacy issues in a set of existing protocols.
本文件未介绍任何新协议。它确实指出了一组现有协议中潜在的隐私问题。
There are obvious privacy gains to changing to randomized hostnames and also to changing these names frequently. However, wide deployment might affect security functions or current practices. For example, incident response using hostnames to track the source of traffic might be affected. It is common practice to include hostnames and reverse lookup information at various times during an investigation.
更改为随机主机名以及频繁更改这些名称会明显增加隐私。但是，广泛部署可能会影响安全功能或当前做法。例如，使用主机名跟踪流量来源的事件响应可能会受到影响。通常的做法是在调查过程中的不同时间包含主机名和反向查找信息。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
[RFC1002] NetBIOS Working Group in the Defense Advanced Research Projects Agency, Internet Activities Board, and End-to-End Services Task Force, "Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed specifications", STD 19, RFC 1002, DOI 10.17487/RFC1002, March 1987, <http://www.rfc-editor.org/info/rfc1002>.
[RFC1002]国防高级研究计划局、互联网活动委员会和端到端服务工作组的NetBIOS工作组，“TCP/UDP传输上NetBIOS服务的协议标准：详细规范”，STD 19，RFC 1002，DOI 10.17487/RFC1002，1987年3月<http://www.rfc-editor.org/info/rfc1002>.
[RFC1033] Lottor, M., "Domain Administrators Operations Guide", RFC 1033, DOI 10.17487/RFC1033, November 1987, <http://www.rfc-editor.org/info/rfc1033>.
[RFC1033]Lottor，M.，“域管理员操作指南”，RFC 1033，DOI 10.17487/RFC1033，1987年11月<http://www.rfc-editor.org/info/rfc1033>.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，DOI 10.17487/RFC1035，1987年11月<http://www.rfc-editor.org/info/rfc1035>.
[RFC1983] Malkin, G., Ed., "Internet Users' Glossary", FYI 18, RFC 1983, DOI 10.17487/RFC1983, August 1996, <http://www.rfc-editor.org/info/rfc1983>.
[RFC1983]Malkin，G.，Ed.，“互联网用户词汇表”，FYI 18，RFC 1983，DOI 10.17487/RFC1983，1996年8月<http://www.rfc-editor.org/info/rfc1983>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <http://www.rfc-editor.org/info/rfc2131>.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC 2131，DOI 10.17487/RFC2131，1997年3月<http://www.rfc-editor.org/info/rfc2131>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, <http://www.rfc-editor.org/info/rfc2132>.
[RFC2132]Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 2132，DOI 10.17487/RFC2132，1997年3月<http://www.rfc-editor.org/info/rfc2132>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <http://www.rfc-editor.org/info/rfc2782>.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，DOI 10.17487/RFC2782，2000年2月<http://www.rfc-editor.org/info/rfc2782>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 3315，DOI 10.17487/RFC3315，2003年7月<http://www.rfc-editor.org/info/rfc3315>.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, DOI 10.17487/RFC3596, October 2003, <http://www.rfc-editor.org/info/rfc3596>.
[RFC3596]Thomson，S.，Huitema，C.，Ksinant，V.，和M.Souissi，“支持IP版本6的DNS扩展”，RFC 3596，DOI 10.17487/RFC3596，2003年10月<http://www.rfc-editor.org/info/rfc3596>.
[RFC4620] Crawford, M. and B. Haberman, Ed., "IPv6 Node Information Queries", RFC 4620, DOI 10.17487/RFC4620, August 2006, <http://www.rfc-editor.org/info/rfc4620>.
[RFC4620]克劳福德，M.和B.哈伯曼，编辑，“IPv6节点信息查询”，RFC 4620，DOI 10.17487/RFC4620，2006年8月<http://www.rfc-editor.org/info/rfc4620>.
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast Name Resolution (LLMNR)", RFC 4795, DOI 10.17487/RFC4795, January 2007, <http://www.rfc-editor.org/info/rfc4795>.
[RFC4795]Aboba，B.，Thaler，D.，和L.Esibov，“链路本地多播名称解析（LLMNR）”，RFC 4795，DOI 10.17487/RFC4795，2007年1月<http://www.rfc-editor.org/info/rfc4795>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <http://www.rfc-editor.org/info/rfc6762>.
[RFC6762]Cheshire，S.和M.Krochmal，“多播DNS”，RFC 6762，DOI 10.17487/RFC6762，2013年2月<http://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <http://www.rfc-editor.org/info/rfc6763>.
[RFC6763]Cheshire，S.和M.Krocmal，“基于DNS的服务发现”，RFC 6763，DOI 10.17487/RFC6763，2013年2月<http://www.rfc-editor.org/info/rfc6763>.
[RFC7288] Thaler, D., "Reflections on Host Firewalls", RFC 7288, DOI 10.17487/RFC7288, June 2014, <http://www.rfc-editor.org/info/rfc7288>.
[RFC7288]Thaler，D.，“关于主机防火墙的思考”，RFC 7288，DOI 10.17487/RFC7288，2014年6月<http://www.rfc-editor.org/info/rfc7288>.
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2015, <http://www.rfc-editor.org/info/rfc7719>.
[RFC7719]Hoffman，P.，Sullivan，A.和K.Fujiwara，“DNS术语”，RFC 7719，DOI 10.17487/RFC77192015年12月<http://www.rfc-editor.org/info/rfc7719>.
[RFC7819] Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy Considerations for DHCP", RFC 7819, DOI 10.17487/RFC7819, April 2016, <http://www.rfc-editor.org/info/rfc7819>.
[RFC7819]Jiang，S.，Krishnan，S.，和T.Mrugalski，“DHCP的隐私考虑”，RFC 7819，DOI 10.17487/RFC78192016年4月<http://www.rfc-editor.org/info/rfc7819>.
[RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy Considerations for DHCPv6", RFC 7824, DOI 10.17487/RFC7824, May 2016, <http://www.rfc-editor.org/info/rfc7824>.
[RFC7824]Krishnan，S.，Mrugalski，T.，和S.Jiang，“DHCPv6的隐私考虑”，RFC 7824DOI 10.17487/RFC78242016年5月<http://www.rfc-editor.org/info/rfc7824>.
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity Profiles for DHCP Clients", RFC 7844, DOI 10.17487/RFC7844, May 2016, <http://www.rfc-editor.org/info/rfc7844>.
[RFC7844]Huitema，C.，Mrugalski，T.，和S.Krishnan，“DHCP客户端的匿名配置文件”，RFC 7844，DOI 10.17487/RFC7844，2016年5月<http://www.rfc-editor.org/info/rfc7844>.
[TRAC2016] Faath, M., Winter, R., and F. Weisshaar, "How Broadcast Data Reveals Your Identity and Social Graph", IEEE, Wireless Communications and Mobile Computing Conference (IWCMC), 2016 International, DOI 10.1109/IWCMC.2016.7577084, September 2016.
[TRAC2016]Faath，M.，Winter，R.，和F.Weisshaar，“广播数据如何揭示您的身份和社交图”，IEEE，无线通信和移动计算会议（IWCM），2016年国际，DOI 10.1109/IWCM.2016.7577084，2016年9月。
Acknowledgments
致谢
Thanks to the members of the INTAREA Working Group for discussions and reviews.
感谢INTAREA工作组成员的讨论和审查。
Authors' Addresses
作者地址
Christian Huitema Private Octopus Inc. Friday Harbor, WA 98250 United States of America
克里斯蒂安·惠特马私人章鱼公司，美国华盛顿州星期五港98250
Email: huitema@huitema.net
Email: huitema@huitema.net
Dave Thaler Microsoft Redmond, WA 98052 United States of America
Dave Thaler微软雷蒙德，华盛顿州，98052美利坚合众国
Email: dthaler@microsoft.com
Email: dthaler@microsoft.com
Rolf Winter University of Applied Sciences Augsburg Augsburg DE
罗尔夫奥格斯堡应用科学大学奥格斯堡分校
Email: rolf.winter@hs-augsburg.de
Email: rolf.winter@hs-augsburg.de