Internet Engineering Task Force (IETF) S. Bortzmeyer
Request for Comments: 7816 AFNIC
Category: Experimental March 2016
ISSN: 2070-1721
Internet Engineering Task Force (IETF) S. Bortzmeyer
Request for Comments: 7816 AFNIC
Category: Experimental March 2016
ISSN: 2070-1721
DNS Query Name Minimisation to Improve Privacy
DNS查询名称最小化以改善隐私
Abstract
摘要
This document describes a technique to improve DNS privacy, a technique called "QNAME minimisation", where the DNS resolver no longer sends the full original QNAME to the upstream name server.
本文档描述了一种改善DNS隐私的技术，该技术称为“QNAME最小化”，其中DNS解析程序不再向上游名称服务器发送完整的原始QNAME。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. 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 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第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/rfc7816.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7816.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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 and Background .....................................2
2. QNAME Minimisation ..............................................3
3. Possible Issues .................................................4
4. Protocol and Compatibility Discussion ...........................5
5. Operational Considerations ......................................5
6. Performance Considerations ......................................6
7. On the Experimentation ..........................................6
8. Security Considerations .........................................7
9. References ......................................................7
9.1. Normative References .......................................7
9.2. Informative References .....................................8
Appendix A. An Algorithm to Perform QNAME Minimisation .............9
Appendix B. Alternatives .........................................10
Acknowledgments ...................................................11
Author's Address ..................................................11
1. Introduction and Background .....................................2
2. QNAME Minimisation ..............................................3
3. Possible Issues .................................................4
4. Protocol and Compatibility Discussion ...........................5
5. Operational Considerations ......................................5
6. Performance Considerations ......................................6
7. On the Experimentation ..........................................6
8. Security Considerations .........................................7
9. References ......................................................7
9.1. Normative References .......................................7
9.2. Informative References .....................................8
Appendix A. An Algorithm to Perform QNAME Minimisation .............9
Appendix B. Alternatives .........................................10
Acknowledgments ...................................................11
Author's Address ..................................................11
The problem statement is described in [RFC7626]. The terminology ("QNAME", "resolver", etc.) is also defined in this companion document. This specific solution is not intended to fully solve the DNS privacy problem; instead, it should be viewed as one tool amongst many.
[RFC7626]中描述了问题陈述。术语（“QNAME”、“解析器”等）也在本配套文件中定义。此特定解决方案并非旨在完全解决DNS隐私问题；相反，它应该被视为众多工具中的一种。
QNAME minimisation follows the principle explained in Section 6.1 of [RFC6973]: the less data you send out, the fewer privacy problems you have.
QNAME最小化遵循[RFC6973]第6.1节中解释的原则：发送的数据越少，隐私问题就越少。
Currently, when a resolver receives the query "What is the AAAA record for www.example.com?", it sends to the root (assuming a cold resolver, whose cache is empty) the very same question. Sending the full QNAME to the authoritative name server is a tradition, not a protocol requirement. In a conversation with the author in January 2015, Paul Mockapetris explained that this tradition comes from a desire to optimise the number of requests, when the same name server is authoritative for many zones in a given name (something that was more common in the old days, where the same name servers served .com and the root) or when the same name server is both recursive and authoritative (something that is strongly discouraged now). Whatever the merits of this choice at this time, the DNS is quite different now.
当前，当解析程序接收到查询“www.example.com的AAAA记录是什么？”时，它会向根用户（假设冷解析程序的缓存为空）发送相同的问题。将完整的QNAME发送到权威名称服务器是一种传统，而不是协议要求。在2015年1月与作者的一次对话中，Paul Mockapetris解释说，这一传统源于优化请求数量的愿望，当同名服务器对给定名称中的许多区域具有权威性时（在过去更为常见，同名服务器服务于.com和root）或者当同一个名称的服务器是递归的和权威的（这是现在强烈反对的）。无论这个选择在此时有什么优点，DNS现在已经完全不同了。
The idea is to minimise the amount of data sent from the DNS resolver to the authoritative name server. In the example in the previous section, sending "What are the NS records for .com?" would have been sufficient (since it will be the answer from the root anyway). The rest of this section describes the recommended way to do QNAME minimisation -- the way that maximises privacy benefits (other alternatives are discussed in the appendices).
这样做的目的是最大限度地减少从DNS解析程序发送到权威名称服务器的数据量。在上一节的示例中，发送“What is the NS records for.com？”就足够了（因为它将是根目录的答案）。本节其余部分介绍了QNAME最小化的推荐方法——最大限度地提高隐私优势的方法（其他替代方法在附录中讨论）。
Instead of sending the full QNAME and the original QTYPE upstream, a resolver that implements QNAME minimisation and does not already have the answer in its cache sends a request to the name server authoritative for the closest known ancestor of the original QNAME. The request is done with:
实现QNAME最小化且其缓存中没有答案的解析程序不向上游发送完整QNAME和原始QTYPE，而是向名称服务器权威发送请求，以获取原始QNAME最接近的已知祖先。请求通过以下方式完成：
o the QTYPE NS
o qtypens
o the QNAME that is the original QNAME, stripped to just one label more than the zone for which the server is authoritative
o QNAME是原始QNAME，仅比服务器授权的区域多出一个标签
For example, a resolver receives a request to resolve foo.bar.baz.example. Let's assume that it already knows that ns1.nic.example is authoritative for .example and the resolver does not know a more specific authoritative name server. It will send the query QTYPE=NS,QNAME=baz.example to ns1.nic.example.
例如，解析程序收到解析foo.bar.baz.example的请求。假设它已经知道ns1.nic.example是权威的，例如，解析器不知道更具体的权威名称服务器。它将把查询QTYPE=NS，QNAME=baz.example发送到ns1.nic.example。
The minimising resolver works perfectly when it knows the zone cut (zone cuts are described in Section 6 of [RFC2181]). But zone cuts do not necessarily exist at every label boundary. If we take the name www.foo.bar.example, it is possible that there is a zone cut between "foo" and "bar" but not between "bar" and "example". So, assuming that the resolver already knows the name servers of .example, when it receives the query "What is the AAAA record of www.foo.bar.example?", it does not always know where the zone cut will be. To find the zone cut, it will query the .example name servers for the NS records for bar.example. It will get a NODATA response, indicating that there is no zone cut at that point, so it has to query the .example name servers again with one more label, and so on. (Appendix A describes this algorithm in deeper detail.)
当知道分区切割时，最小分解器可以完美工作（分区切割在[RFC2181]的第6节中描述）。但分区切割不一定存在于每个标签边界。如果我们使用名称www.foo.bar.example，则可能在“foo”和“bar”之间有一个分区，但在“bar”和“example”之间没有。因此，假设解析器已经知道.example的名称，当它接收到查询“www.foo.bar.example的AAAA记录是什么？”时，它并不总是知道分区切割将在哪里。要查找分区切割，它将在.example名称服务器中查询bar.example的NS记录。它将得到一个NODATA响应，表明在该点上没有区域切割，因此它必须用一个标签再次查询.example name服务器，以此类推。（附录A更详细地描述了该算法。）
Since the information about the zone cuts will be stored in the resolver's cache, the performance cost is probably reasonable. Section 6 discusses this performance discrepancy further.
由于有关分区切割的信息将存储在解析器的缓存中，因此性能成本可能是合理的。第6节进一步讨论了这种性能差异。
Note that DNSSEC-validating resolvers already have access to this information, since they have to know the zone cut (the DNSKEY record set is just below; the DS record set is just above).
请注意，DNSSEC验证解析程序已经可以访问此信息，因为它们必须知道分区切割（DNSKEY记录集就在下面；DS记录集就在上面）。
QNAME minimisation is legal, since the original DNS RFCs do not mandate sending the full QNAME. So, in theory, it should work without any problems. However, in practice, some problems may occur (see [Huque-QNAME-Min] for an analysis and [Huque-QNAME-storify] for an interesting discussion on this topic).
QNAME最小化是合法的，因为原始DNS RFC不要求发送完整的QNAME。因此，从理论上讲，它应该毫无问题地工作。但是，在实践中，可能会出现一些问题（请参阅[Huque QNAME Min]了解分析，并参阅[Huque QNAME storify]了解有关此主题的有趣讨论）。
Some broken name servers do not react properly to QTYPE=NS requests. For instance, some authoritative name servers embedded in load balancers reply properly to A queries but send REFUSED to NS queries. This behaviour is a protocol violation, and there is no need to stop improving the DNS because of such behaviour. However, QNAME minimisation may still work with such domains, since they are only leaf domains (no need to send them NS requests). Such a setup breaks more than just QNAME minimisation. It breaks negative answers, since the servers don't return the correct SOA, and it also breaks anything dependent upon NS and SOA records existing at the top of the zone.
某些损坏的名称服务器无法正确响应QTYPE=NS请求。例如，负载平衡器中嵌入的一些权威名称服务器正确地答复A查询，但拒绝发送NS查询。这种行为违反了协议，没有必要因为这种行为而停止改进DNS。然而，QNAME最小化可能仍然适用于此类域，因为它们只是叶域（不需要向它们发送NS请求）。这样的设置打破的不仅仅是QNAME最小化。它打破了否定的答案，因为服务器没有返回正确的SOA，它还打破了依赖于区域顶部存在的NS和SOA记录的任何内容。
Another way to deal with such incorrect name servers would be to try with QTYPE=A requests (A being chosen because it is the most common and hence a QTYPE that will always be accepted, while a QTYPE NS may ruffle the feathers of some middleboxes). Instead of querying name servers with a query "NS example.com", we could use "A _.example.com" and see if we get a referral.
处理此类错误名称服务器的另一种方法是尝试使用QTYPE=A请求（之所以选择A，是因为它是最常见的，因此QTYPE总是被接受，而QTYPE NS可能会激怒某些中间包）。我们不必使用查询“NS example.com”来查询名称服务器，而可以使用“a u.example.com”来查看是否得到了推荐。
A problem can also appear when a name server does not react properly to ENTs (Empty Non-Terminals). If ent.example.com has no resource records but foobar.ent.example.com does, then ent.example.com is an ENT. Whatever the QTYPE, a query for ent.example.com must return NODATA (NOERROR / ANSWER: 0). However, some name servers incorrectly return NXDOMAIN for ENTs. If a resolver queries only foobar.ent.example.com, everything will be OK, but if it implements QNAME minimisation, it may query ent.example.com and get an NXDOMAIN. See also Section 3 of [DNS-Res-Improve] for the other bad consequences of this bad behaviour.
当名称服务器不能对ENT（空的非终端）做出正确反应时，也会出现问题。如果ent.example.com没有资源记录，但foobar.ent.example.com有，则ent.example.com是一个ent。无论QTYPE是什么，对ent.example.com的查询都必须返回NODATA（NOERROR/ANSWER:0）。但是，一些名称服务器错误地返回NTS的NXDOMAIN。如果解析器只查询foobar.ent.example.com，一切都会正常，但如果它实现QNAME最小化，它可能会查询ent.example.com并获得一个NXDOMAIN。有关此不良行为的其他不良后果，请参见[DNS Res Improve]第3节。
A possible solution, currently implemented in Knot, is to retry with the full query when you receive an NXDOMAIN. It works, but it is not ideal for privacy.
当前在Knot中实现的一个可能的解决方案是在收到NXDOMAIN时使用完整查询重试。这是可行的，但对隐私来说并不理想。
Other practices that do not conform to the DNS protocol standards may pose a problem: there is a common DNS trick used by some web hosters that also do DNS hosting that exploits the fact that the DNS protocol
不符合DNS协议标准的其他实践可能会带来一个问题：一些web主机使用一种常见的DNS技巧，这些主机也利用DNS协议
(pre-DNSSEC) allows certain serious misconfigurations, such as parent and child zones disagreeing on the location of a zone cut. Basically, they have a single zone with wildcards for each TLD, like:
（DNSSEC之前）允许某些严重的错误配置，例如父分区和子分区在分区切割位置上存在分歧。基本上，每个TLD都有一个带通配符的区域，如：
*.example. 60 IN A 192.0.2.6
*.例如。在192.0.2.6中为60
(They could just wildcard all of "*.", which would be sufficient. We don't know why they don't do it.)
（他们可以通配符所有的“*”，这就足够了。我们不知道他们为什么不这么做。）
This lets them have many web-hosting customers without having to configure thousands of individual zones on their name servers. They just tell the prospective customer to point their NS records at the hoster's name servers, and the web hoster doesn't have to provision anything in order to make the customer's domain resolve. NS queries to the hoster will therefore not give the right result, which may endanger QNAME minimisation (it will be a problem for DNSSEC, too).
这使他们拥有许多web托管客户，而无需在其名称服务器上配置数千个单独的区域。他们只是告诉潜在客户将他们的NS记录指向主机的名称服务器，web主机不必提供任何内容来解析客户的域。因此，NS向主机的查询不会给出正确的结果，这可能会危及QNAME最小化（这对DNSSEC来说也是一个问题）。
QNAME minimisation is compatible with the current DNS system and therefore can easily be deployed; since it is a unilateral change to the resolver, it does not change the protocol. (Because it is a unilateral change, resolver implementers may do QNAME minimisation in slightly different ways; see the appendices for examples.)
QNAME最小化与当前DNS系统兼容，因此可以轻松部署；由于这是对解析器的单方面更改，因此不会更改协议。（因为这是一个单方面的更改，解析器实现者可能会以稍微不同的方式实现QNAME最小化；示例请参见附录。）
One should note that the behaviour suggested here (minimising the amount of data sent in QNAMEs from the resolver) is NOT forbidden by Section 5.3.3 of [RFC1034] or Section 7.2 of [RFC1035]. As stated in Section 1, the current method, sending the full QNAME, is not mandated by the DNS protocol.
需要注意的是，[RFC1034]第5.3.3节或[RFC1035]第7.2节并未禁止此处建议的行为（尽量减少以QName形式从解析器发送的数据量）。如第1节所述，当前发送完整QNAME的方法不受DNS协议的约束。
One may notice that many documents that explain the DNS and that are intended for a wide audience incorrectly describe the resolution process as using QNAME minimisation (e.g., by showing a request going to the root, with just the TLD in the query). As a result, these documents may confuse readers that use them for privacy analysis.
人们可能会注意到，许多解释DNS和面向广大受众的文档错误地将解析过程描述为使用QNAME最小化（例如，通过将请求显示到根目录，查询中仅包含TLD）。因此，这些文档可能会使使用它们进行隐私分析的读者感到困惑。
The administrators of the forwarders, and of the authoritative name servers, will get less data, which will reduce the utility of the statistics they can produce (such as the percentage of the various QTYPEs) [Kaliski-Minimum].
转发器和权威名称服务器的管理员将获得较少的数据，这将降低他们可以生成的统计数据的效用（例如各种QTYPE的百分比）[Kaliski Minimum]。
DNS administrators are reminded that the data on DNS requests that they store may have legal consequences, depending on your jurisdiction (check with your local lawyer).
提醒DNS管理员，他们存储的DNS请求上的数据可能会产生法律后果，具体取决于您所在的司法管辖区（请咨询您当地的律师）。
The main goal of QNAME minimisation is to improve privacy by sending less data. However, it may have other advantages. For instance, if a root name server receives a query from some resolver for A.example followed by B.example followed by C.example, the result will be three NXDOMAINs, since .example does not exist in the root zone. Under query name minimisation, the root name servers would hear only one question (for .example itself) to which they could answer NXDOMAIN, thus opening up a negative caching opportunity in which the full resolver could know a priori that neither B.example nor C.example could exist. Thus, in this common case the total number of upstream queries under QNAME minimisation would be counterintuitively less than the number of queries under the traditional iteration (as described in the DNS standard).
QNAME最小化的主要目标是通过发送更少的数据来改善隐私。然而，它可能还有其他优势。例如，如果根名称服务器接收到某个解析程序对a.example后跟B.example后跟C.example的查询，则结果将是三个nxdomain，因为根区域中不存在.example。在查询名称最小化的情况下，根名称服务器只会听到一个问题（例如，它本身），它们可以回答NXDOMAIN，从而打开了一个负面缓存机会，在这个机会中，完整解析程序可以先验地知道B.example和C.example都不可能存在。因此，在这种常见情况下，QNAME最小化下的上游查询总数将反直觉地少于传统迭代下的查询数量（如DNS标准中所述）。
QNAME minimisation may also improve lookup performance for TLD operators. For a typical TLD, delegation-only, and with delegations just under the TLD, a two-label QNAME query is optimal for finding the delegation owner name.
QNAME最小化还可以提高TLD操作符的查找性能。对于典型的TLD（仅限委派），并且对于TLD下的委派，双标签QNAME查询最适合查找委派所有者名称。
QNAME minimisation can decrease performance in some cases -- for instance, for a deep domain name (like www.host.group.department.example.com, where host.group.department.example.com is hosted on example.com's name servers). Let's assume a resolver that knows only the name servers of .example. Without QNAME minimisation, it would send these .example name servers a query for www.host.group.department.example.com and immediately get a specific referral or an answer, without the need for more queries to probe for the zone cut. For such a name, a cold resolver with QNAME minimisation will, depending on how QNAME minimisation is implemented, send more queries, one per label. Once the cache is warm, there will be no difference with a traditional resolver. Actual testing is described in [Huque-QNAME-Min]. Such deep domains are especially common under ip6.arpa.
QNAME最小化在某些情况下会降低性能——例如，对于深度域名（如www.host.group.department.example.com，其中host.group.department.example.com托管在example.com的名称服务器上）。让我们假设一个解析器只知道服务器的名称。例如。如果没有QNAME最小化，它将向这些.example name服务器发送www.host.group.department.example.com的查询，并立即获得特定的推荐或答案，而不需要更多的查询来调查分区切割。对于这样的名称，具有QNAME最小化的冷解析程序将根据QNAME最小化的实现方式发送更多查询，每个标签一个查询。一旦缓存变热，与传统的解析器就没有什么区别了。实际测试在[Huque QNAME Min]中描述。这种深域在ip6.arpa下尤其常见。
This document has status "Experimental". Since the beginning of time (or DNS), the fully qualified host name was always sent to the authoritative name servers. There was a concern that changing this behaviour may engage the Law of Unintended Consequences -- hence this status.
本文件的状态为“实验性”。从时间开始（或DNS），完全限定的主机名始终发送到权威名称服务器。有人担心，改变这种行为可能会涉及意外后果的法律——因此这一地位。
The idea behind the experiment is to observe QNAME minimisation in action with multiple resolvers, various authoritative name servers, etc.
实验背后的想法是观察多个解析器、各种权威名称服务器等的QNAME最小化。
QNAME minimisation's benefits are clear in the case where you want to decrease exposure to the authoritative name server. But minimising the amount of data sent also, in part, addresses the case of a wire sniffer as well as the case of privacy invasion by the servers. (Encryption is of course a better defense against wire sniffers, but, unlike QNAME minimisation, it changes the protocol and cannot be deployed unilaterally. Also, the effect of QNAME minimisation on wire sniffers depends on whether the sniffer is on the DNS path.)
在您希望减少对权威名称服务器的接触的情况下，QNAME最小化的好处是显而易见的。但将发送的数据量降至最低也在一定程度上解决了窃听器和服务器侵犯隐私的问题。（加密当然是对有线嗅探器的更好防御，但与QNAME最小化不同，它改变了协议，不能单方面部署。此外，QNAME最小化对有线嗅探器的影响取决于嗅探器是否在DNS路径上。）
QNAME minimisation offers zero protection against the recursive resolver, which still sees the full request coming from the stub resolver.
QNAME最小化提供了针对递归解析器的零保护，递归解析器仍然可以看到来自存根解析器的完整请求。
All the alternatives mentioned in Appendix B decrease privacy in the hope of improving performance. They must not be used if you want maximum privacy.
附录B中提到的所有备选方案都会减少隐私，以期提高性能。如果您希望最大限度地保护隐私，则不得使用它们。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <http://www.rfc-editor.org/info/rfc1034>.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，DOI 10.17487/RFC1034，1987年11月<http://www.rfc-editor.org/info/rfc1034>.
[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>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <http://www.rfc-editor.org/info/rfc6973>.
[RFC6973]Cooper，A.，Tschofenig，H.，Aboba，B.，Peterson，J.，Morris，J.，Hansen，M.，和R.Smith，“互联网协议的隐私考虑”，RFC 6973，DOI 10.17487/RFC6973，2013年7月<http://www.rfc-editor.org/info/rfc6973>.
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, DOI 10.17487/RFC7626, August 2015, <http://www.rfc-editor.org/info/rfc7626>.
[RFC7626]Bortzmeyer，S.，“DNS隐私注意事项”，RFC 7626，DOI 10.17487/RFC7626，2015年8月<http://www.rfc-editor.org/info/rfc7626>.
[DNS-Res-Improve] Vixie, P., Joffe, R., and F. Neves, "Improvements to DNS Resolvers for Resiliency, Robustness, and Responsiveness", Work in Progress, draft-vixie-dnsext-resimprove-00, June 2010.
[DNS Res-Improve]Vixie，P.，Joffe，R.，和F.Neves，“DNS解析程序的弹性、健壮性和响应性改进”，正在进行的工作，草稿-Vixie-dnsext-resimprove-00，2010年6月。
[HAMMER] Kumari, W., Arends, R., Woolf, S., and D. Migault, "Highly Automated Method for Maintaining Expiring Records", Work in Progress, draft-wkumari-dnsop-hammer-01, July 2014.
[HAMMER]Kumari，W.，Arends，R.，Woolf，S.，和D.Migault，“维护过期记录的高度自动化方法”，正在进行的工作，草稿-wkumari-dnsop-HAMMER-012014年7月。
[Huque-QNAME-Min] Huque, S., "Query name minimization and authoritative server behavior", May 2015, <https://indico.dns-oarc.net/event/21/contribution/9>.
[Huque QNAME Min]Huque，S.，“查询名称最小化和权威服务器行为”，2015年5月<https://indico.dns-oarc.net/event/21/contribution/9>.
[Huque-QNAME-storify] Huque, S., "Qname Minimization @ DNS-OARC", May 2015, <https://storify.com/shuque/qname-minimization-dns-oarc>.
[Huque QNAME storify]Huque，S.，“QNAME最小化@DNS-OARC”，2015年5月<https://storify.com/shuque/qname-minimization-dns-oarc>.
[Kaliski-Minimum] Kaliski, B., "Minimum Disclosure: What Information Does a Name Server Need to Do Its Job?", March 2015, <http://blogs.verisigninc.com/blog/entry/ minimum_disclosure_what_information_does>.
[Kaliski Minimum]Kaliski，B.，“最小披露：名称服务器需要什么信息来完成其工作？”，2015年3月<http://blogs.verisigninc.com/blog/entry/ 最低限度的信息披露信息的作用>。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, <http://www.rfc-editor.org/info/rfc2181>.
[RFC2181]Elz，R.和R.Bush，“DNS规范的澄清”，RFC 2181，DOI 10.17487/RFC2181，1997年7月<http://www.rfc-editor.org/info/rfc2181>.
This algorithm performs name resolution with QNAME minimisation in the presence of zone cuts that are not yet known.
该算法在存在未知区域切割的情况下，通过QNAME最小化执行名称解析。
Although a validating resolver already has the logic to find the zone cuts, implementers of other resolvers may want to use this algorithm to locate the cuts. This is just a possible aid for implementers; it is not intended to be normative:
尽管验证解析器已经具有查找区域切割的逻辑，但其他解析器的实现者可能希望使用此算法来定位切割。这只是对实施者的一种可能的帮助；其目的不是规范性的：
(0) If the query can be answered from the cache, do so; otherwise, iterate as follows:
(0) 如果可以从缓存中回答查询，请执行此操作；否则，按如下方式迭代：
(1) Find the closest enclosing NS RRset in your cache. The owner of this NS RRset will be a suffix of the QNAME -- the longest suffix of any NS RRset in the cache. Call this ANCESTOR.
(1) 在缓存中查找最近的封闭RRNS集。此NS RRset的所有者将是QNAME的后缀——缓存中任何NS RRset的最长后缀。称之为祖先。
(2) Initialise CHILD to the same as ANCESTOR.
(2) 将子项初始化为与祖先相同。
(3) If CHILD is the same as the QNAME, resolve the original query using ANCESTOR's name servers, and finish.
(3) 如果CHILD与QNAME相同，请使用祖先的名称服务器解析原始查询，然后完成。
(4) Otherwise, add a label from the QNAME to the start of CHILD.
(4) 否则，请将标签从QNAME添加到子项的开头。
(5) If you have a negative cache entry for the NS RRset at CHILD, go back to step 3.
(5) 如果子级上的NS RRset的缓存项为负数，请返回步骤3。
(6) Query for CHILD IN NS using ANCESTOR's name servers. The response can be:
(6) 使用祖先的名称服务器查询NS中的子级。答复可以是：
(6a) A referral. Cache the NS RRset from the authority section, and go back to step 1.
（6a）转介。从授权部分缓存NS RRset，然后返回步骤1。
(6b) An authoritative answer. Cache the NS RRset from the answer section, and go back to step 1.
（6b）权威性的回答。缓存应答部分中的NS RRset，然后返回步骤1。
(6c) An NXDOMAIN answer. Return an NXDOMAIN answer in response to the original query, and stop.
（6c）答案。返回NXDOMAIN答案以响应原始查询，然后停止。
(6d) A NOERROR/NODATA answer. Cache this negative answer, and go back to step 3.
（6d）无错误/无数据的回答。缓存此否定答案，然后返回步骤3。
Remember that QNAME minimisation is unilateral, so a resolver is not forced to implement it exactly as described here.
请记住，QNAME最小化是单方面的，因此解析程序不会被迫完全按照此处所述实现它。
There are several ways to perform QNAME minimisation. See Section 2 for the suggested way. It can be called the aggressive algorithm, since the resolver only sends NS queries as long as it does not know the zone cuts. This is the safest, from a privacy point of view. Another possible algorithm, not fully studied at this time, could be to "piggyback" on the traditional resolution code. At startup, it sends traditional full QNAMEs and learns the zone cuts from the referrals received, then switches to NS queries asking only for the minimum domain name. This leaks more data but could require fewer changes in the existing resolver codebase.
有几种方法可以执行QNAME最小化。建议的方法见第2节。它可以被称为主动算法，因为解析器只发送NS查询，只要它不知道区域切割。从隐私的角度来看，这是最安全的。另一种可能的算法，目前还没有完全研究，可能是“背驮”在传统的分辨率代码上。在启动时，它发送传统的QQ全名，并从收到的转介中学习区域切割，然后切换到只要求最小域名的NS查询。这会泄漏更多数据，但可能需要对现有解析器代码库进行更少的更改。
In the above specification, the original QTYPE is replaced by NS (or may be A, if too many servers react incorrectly to NS requests); this is the best approach to preserve privacy. But this erases information about the relative use of the various QTYPEs, which may be interesting for researchers (for instance, if they try to follow IPv6 deployment by counting the percentage of AAAA vs. A queries). A variant of QNAME minimisation would be to keep the original QTYPE.
在上述规范中，原始QTYPE被NS替换（如果太多服务器对NS请求做出错误反应，则可能是A）；这是保护隐私的最佳方法。但这抹去了关于各种QType的相对使用的信息，这可能会引起研究人员的兴趣（例如，如果他们试图通过计算AAAA与A查询的百分比来跟踪IPv6部署）。QNAME最小化的一种变体是保留原始QTYPE。
Another useful optimisation may be, in the spirit of the HAMMER idea [HAMMER], to probe in advance for the introduction of zone cuts where none previously existed (i.e., confirm their continued absence, or discover them).
另一个有用的优化可能是，本着HAMMER理念【HAMMER】的精神，提前探索引入以前不存在的区域切割（即，确认其持续缺失，或发现）。
To address the "number of queries" issue described in Section 6, a possible solution is to always use the traditional algorithm when the cache is cold and then to move to QNAME minimisation (precisely defining what is "hot" or "cold" is left to the implementer). This will decrease the privacy but will guarantee no degradation of performance.
为了解决第6节中描述的“查询数量”问题，一个可能的解决方案是在缓存处于冷态时始终使用传统算法，然后转向QNAME最小化（精确定义什么是“热”或“冷”留给实现者）。这将减少隐私，但不会降低性能。
Acknowledgments
致谢
Thanks to Olaf Kolkman for the original idea during a KLM flight from Amsterdam to Vancouver, although the concept is probably much older (e.g., <https://lists.dns-oarc.net/pipermail/dns-operations/ 2010-February/005003.html>). Thanks to Shumon Huque and Marek Vavrusa for implementation and testing. Thanks to Mark Andrews and Francis Dupont for the interesting discussions. Thanks to Brian Dickson, Warren Kumari, Evan Hunt, and David Conrad for remarks and suggestions. Thanks to Mohsen Souissi for proofreading. Thanks to Tony Finch for the zone cut algorithm in Appendix A and for discussion of the algorithm. Thanks to Paul Vixie for pointing out that there are practical advantages (besides privacy) to QNAME minimisation. Thanks to Phillip Hallam-Baker for the fallback on A queries, to deal with broken servers. Thanks to Robert Edmonds for an interesting anti-pattern.
感谢奥拉夫·科尔克曼（Olaf Kolkman）在荷兰皇家航空公司（KLM）从阿姆斯特丹飞往温哥华的航班上提出的最初想法，尽管这个概念可能要古老得多（例如<https://lists.dns-oarc.net/pipermail/dns-operations/ 2010年2月/005003.html>）。感谢Shumon Huque和Marek Vavrusa的实施和测试。感谢马克·安德鲁斯和弗朗西斯·杜邦的有趣讨论。感谢Brian Dickson、Warren Kumari、Evan Hunt和David Conrad的评论和建议。感谢Mohsen Souissi的校对。感谢Tony Finch在附录A中介绍了区域切割算法，并对该算法进行了讨论。感谢Paul Vixie指出QNAME最小化有实际优势（除了隐私）。感谢Phillip Hallam Baker在处理服务器故障时提供了一个查询的后备方案。感谢Robert Edmonds提供的有趣的反模式。
Author's Address
作者地址
Stephane Bortzmeyer AFNIC 1, rue Stephenson Montigny-le-Bretonneux 78180 France
Stephane Bortzmeyer AFNIC 1号，Stephenson Montigny le Bretoneux街78180号，法国
Phone: +33 1 39 30 83 46
Email: bortzmeyer+ietf@nic.fr
URI: http://www.afnic.fr/
Phone: +33 1 39 30 83 46
Email: bortzmeyer+ietf@nic.fr
URI: http://www.afnic.fr/