Internet Engineering Task Force (IETF) A. Mayrhofer
Request for Comments: 8467 nic.at GmbH
Category: Experimental October 2018
ISSN: 2070-1721
Internet Engineering Task Force (IETF) A. Mayrhofer
Request for Comments: 8467 nic.at GmbH
Category: Experimental October 2018
ISSN: 2070-1721
Padding Policies for Extension Mechanisms for DNS (EDNS(0))
DNS（EDN（0））扩展机制的填充策略
Abstract
摘要
RFC 7830 specifies the "Padding" option for Extension Mechanisms for DNS (EDNS(0)) but does not specify the actual padding length for specific applications. This memo lists the possible options ("padding policies"), discusses the implications of each option, and provides a recommended (experimental) option.
RFC 7830为DNS（EDN（0））的扩展机制指定了“填充”选项，但没有为特定应用程序指定实际填充长度。本备忘录列出了可能的选项（“填充策略”），讨论了每个选项的含义，并提供了建议的（实验性）选项。
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 candidates 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 https://www.rfc-editor.org/info/rfc8467.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8467.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................2
3. General Guidance ................................................3
4. Padding Strategies ..............................................3
4.1. Recommended Strategy: Block-Length Padding .................3
4.2. Other Strategies ...........................................5
4.2.1. Maximal-Length Padding ..............................5
4.2.2. Random-Length Padding ...............................5
4.2.3. Random-Block-Length Padding .........................6
5. IANA Considerations .............................................6
6. Security Considerations .........................................6
7. References ......................................................7
7.1. Normative References .......................................7
7.2. Informative References .....................................7
Appendix A. Padding Policies That Are Not Sensible ................8
A.1. No Padding .................................................8
A.2. Fixed-Length Padding .......................................8
Acknowledgements ...................................................9
Author's Address ...................................................9
1. Introduction ....................................................2
2. Terminology .....................................................2
3. General Guidance ................................................3
4. Padding Strategies ..............................................3
4.1. Recommended Strategy: Block-Length Padding .................3
4.2. Other Strategies ...........................................5
4.2.1. Maximal-Length Padding ..............................5
4.2.2. Random-Length Padding ...............................5
4.2.3. Random-Block-Length Padding .........................6
5. IANA Considerations .............................................6
6. Security Considerations .........................................6
7. References ......................................................7
7.1. Normative References .......................................7
7.2. Informative References .....................................7
Appendix A. Padding Policies That Are Not Sensible ................8
A.1. No Padding .................................................8
A.2. Fixed-Length Padding .......................................8
Acknowledgements ...................................................9
Author's Address ...................................................9
[RFC7830] specifies the Extension Mechanisms for DNS (EDNS(0)) "Padding" option, which allows DNS clients and servers to artificially increase the size of a DNS message by a variable number of bytes, hampering size-based correlation of encrypted DNS messages.
[RFC7830]指定DNS的扩展机制（EDNS（0））“填充”选项，该选项允许DNS客户端和服务器人为地将DNS消息的大小增加可变字节数，从而妨碍加密DNS消息基于大小的关联。
However, RFC 7830 deliberately does not specify the actual length of padding to be used. This memo discusses options regarding the actual size of padding, lists advantages and disadvantages of each of these "padding strategies", and provides a recommended (experimental) strategy.
然而，RFC 7830故意不指定要使用的填充的实际长度。本备忘录讨论了有关填充实际大小的选项，列出了每种“填充策略”的优缺点，并提供了推荐的（实验性）策略。
Padding DNS messages is useful only when transport is encrypted using protocols such as DNS over Transport Layer Security [RFC7858], DNS over Datagram Transport Layer Security [RFC8094], or other encrypted DNS transports specified in the future.
仅当使用协议（如传输层上的DNS安全[RFC7858]、数据报传输层上的DNS安全[RFC8094]或将来指定的其他加密DNS传输）对传输进行加密时，填充DNS消息才有用。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
EDNS(0) options space: The maximum message length, as dictated by the protocol, limits the space for EDNS(0) options. Since padding will reduce the message space available to other EDNS(0) options, the "Padding" option MUST be the last EDNS(0) option applied before a DNS message is sent.
EDNS（0）选项空间：协议规定的最大消息长度限制了EDNS（0）选项的空间。由于填充将减少其他EDN（0）选项可用的消息空间，“填充”选项必须是在发送DNS消息之前应用的最后一个EDN（0）选项。
Resource Conservation: Especially in situations where networking and processing resources are scarce (e.g., battery-powered long-life devices, low bandwidth, or high-cost links), the trade-off between increased size of padded DNS messages and the corresponding gain in confidentiality must be carefully considered.
资源节约：尤其是在网络和处理资源稀缺的情况下（例如，电池供电的长寿命设备、低带宽或高成本链路），必须仔细考虑增加填充DNS消息的大小和相应的保密性增益之间的权衡。
Transport Protocol Independence: The message size used as input to the various padding strategies MUST be calculated excluding the potential extra 2-octet length field used in TCP transport. Otherwise, the padded (observable) size of the DNS packets could significantly change between different transport protocols and reveal an indication of the original (unpadded) length. For example, given a Block-Length Padding strategy with a block length of 32 octets and a DNS message with a size of 59 octets, the message would be padded to 64 octets when transported over UDP. If that same message were transported over TCP and the padding strategy considered the extra 2 octets of the length field (61 octets in total), the padded message would be 96 octets long (as the minimum length of the "Padding" option is 4 octets).
传输协议独立性：必须计算用作各种填充策略输入的消息大小，不包括TCP传输中使用的潜在额外2个八位字节长度字段。否则，DNS数据包的填充（可观察）大小可能在不同传输协议之间发生显著变化，并显示原始（未添加）长度的指示。例如，给定块长度为32个八位字节的块长度填充策略和大小为59个八位字节的DNS消息，通过UDP传输时，消息将填充到64个八位字节。如果相同的消息通过TCP传输，并且填充策略考虑长度字段的额外2个八位字节（总共61个八位字节），则填充的消息长度将为96个八位字节（因为“填充”选项的最小长度为4个八位字节）。
This section contains a recommended strategy, as well as a non-exhaustive list of other sensible strategies, for choosing padding length. Note that, for completeness, Appendix A contains two more strategies that are not sensible.
本节包含一个推荐的策略，以及选择填充长度的其他合理策略的非详尽列表。请注意，为了完整起见，附录A包含了另外两个不合理的策略。
Based on empirical research performed by Daniel K. Gillmor [NDSS-PADDING], padding SHOULD be performed following the Block-Length Padding strategy as follows:
根据Daniel K.Gillmor[NDSS-PADDING]进行的实证研究，应按照块长度填充策略进行填充，如下所示：
(1) Clients SHOULD pad queries to the closest multiple of 128 octets.
(1) 客户端应将查询填充到128个八位字节中最接近的倍数。
(2) If a server receives a query that includes the EDNS(0) "Padding" option, it MUST pad the corresponding response (see Section 4 of RFC 7830) and SHOULD pad the corresponding response to a multiple of 468 octets (see below).
(2) 如果服务器接收到包含EDNS（0）“填充”选项的查询，则必须填充相应的响应（参见RFC 7830第4节），并应将相应的响应填充到468个八位字节的倍数（参见下文）。
Note that the recommendation above only applies if the DNS transport is encrypted (see Section 6 of RFC 7830).
注意，上述建议仅适用于加密DNS传输的情况（参见RFC 7830第6节）。
In Block-Length Padding, a sender pads each message so that its padded length is a multiple of a chosen block length. This creates a greatly reduced variety of message lengths. An implementor needs to consider that even the zero-length "Padding" option increases the length of the packet by 4 octets.
在块长度填充中，发送方填充每条消息，使其填充长度为所选块长度的倍数。这大大减少了各种消息长度。一个实现者需要考虑，即使是零长度的“填充”选项也会增加包的长度4个八位字节。
Options: Block length. For queries, values between 16 and 128 octets were discussed before empiric research was performed. Responses will require larger block sizes (see [NDSS-PADDING] and above for a discussion).
选项：块长度。对于查询，在进行实证研究之前，对16到128个八位字节之间的值进行了讨论。响应将需要更大的块大小（有关讨论，请参阅[NDSS-PADDING]及以上内容）。
Very large block lengths will have confidentiality properties similar to the Maximal-Length Padding strategy (Section 4.2.1), since almost all messages will fit into a single block. Such "very large block length" values are:
非常大的数据块长度将具有类似于最大长度填充策略（第4.2.1节）的机密性，因为几乎所有消息都可以放入单个数据块中。此类“非常大的块长度”值为：
o 288 bytes for the query (the maximum size of a one-question query over TCP, without any EDNS(0) options) and
o 288字节用于查询（TCP上单问题查询的最大大小，不带任何EDN（0）选项）和
o the EDNS(0) buffer size of the server for the responses.
o 响应服务器的EDNS（0）缓冲区大小。
Advantages: This policy is reasonably easy to implement, reduces the variety of message ("fingerprint") sizes significantly, and does not require a source of (pseudo) random numbers, since the padding length required can be derived from the actual (unpadded) message.
优点：此策略相当容易实现，大大减少了消息（“指纹”）大小的多样性，并且不需要（伪）随机数源，因为所需的填充长度可以从实际（未添加的）消息中派生。
Disadvantage: Given an unpadded message and the block size of the padding (which is assumed to be public knowledge once a server is reachable), the size range of a padded message can be predicted. Therefore, the minimum length of the unpadded message can be inferred.
缺点：给定一条未添加的消息和填充的块大小（一旦服务器可以访问，就假定为公共知识），可以预测填充消息的大小范围。因此，可以推断未添加消息的最小长度。
The empirical research cited above performed a simulation of padding, based on real-world DNS traffic captured on busy recursive resolvers of a research network. The evaluation of the performance of individual padding policies was based on a "cost to attacker" and "cost to defender" function, where the "cost to attacker" was defined as the percentage of query/response pairs falling into the same size bucket and "cost to defender" was defined as the size factor between padded and unpadded messages. Padding with a block size of 128 bytes on the query side and 468 bytes on the response side was considered the optimum trade-off between defender and attacker cost. The response block size of 468 was chosen so that 3 blocks of 468 octets would still comfortably fit into typical Maximum Transmission Unit (MTU) size values.
上面引用的实证研究基于在研究网络繁忙的递归解析器上捕获的真实DNS流量，对填充进行了模拟。单个填充策略的性能评估基于“攻击者成本”和“防御者成本”函数，其中“攻击者成本”定义为落入相同大小存储桶的查询/响应对的百分比，“防御者成本”定义为填充消息和未添加消息之间的大小因子。查询端块大小为128字节，响应端块大小为468字节的填充被认为是防御者和攻击者成本之间的最佳权衡。选择的响应块大小为468，这样468个八位字节中的3个块仍能舒适地适应典型的最大传输单元（MTU）大小值。
The block size will interact with the MTU size. Especially for length values that are a large fraction of the MTU, unless the block length is chosen so that a multiple just fits into the MTU, Block-Length Padding may cause unnecessary fragmentation for UDP-based delivery. Of course, choosing a block length larger than the MTU always forces fragmentation.
块大小将与MTU大小交互。特别是对于占MTU很大一部分的长度值，除非选择块长度以使倍数正好适合MTU，否则块长度填充可能会导致基于UDP的传递出现不必要的碎片。当然，选择大于MTU的块长度总是会强制分段。
Note: Once DNSSEC-validating clients become more prevalent, observed size patterns are expected to change significantly. In that case, the recommended strategy might need to be revisited.
注：一旦DNSSEC验证客户端变得更普遍，观察到的大小模式将发生显著变化。在这种情况下，可能需要重新审视所建议的战略。
In Maximal-Length Padding, the sender pads every message to the maximum size allowed by protocol negotiations.
在最大长度填充中，发送方将每条消息填充到协议协商允许的最大大小。
Advantages: Maximal-Length Padding, when combined with encrypted transport, provides the highest possible level of message-size confidentiality.
优点：最大长度填充与加密传输相结合时，可提供最高级别的消息大小机密性。
Disadvantages: Maximal-Length Padding is wasteful and requires resources on the client, all intervening networks and equipment, and the server. Depending on the negotiated size, this strategy will commonly exceed the MTU and result in a consistent number of fragments, reducing delivery probability when datagram-based transport (such as UDP) is used.
缺点：最大长度填充非常浪费，需要客户端、所有介入网络和设备以及服务器上的资源。根据协商的大小，此策略通常会超过MTU，并导致一致数量的片段，从而在使用基于数据报的传输（如UDP）时降低交付概率。
Due to resource consumption, Maximal-Length Padding is NOT RECOMMENDED.
由于资源消耗，不建议使用最大长度填充。
When using Random-Length Padding, a sender pads each message with a random amount of padding. Due to the size of the "Padding" option itself, each message size is increased by at least 4 octets. The upper limit for padding is the maximum message size. However, a client or server may choose to impose a lower maximum padding length.
当使用随机长度填充时，发送者用随机数量的填充来填充每条消息。由于“Padding”选项本身的大小，每个消息大小至少增加4个八位字节。填充的上限是最大消息大小。但是，客户端或服务器可以选择施加较低的最大填充长度。
Options: Maximum and minimum padding length.
选项：最大和最小填充长度。
Advantages: Theoretically, this policy should create a natural distribution of message sizes.
优点：从理论上讲，此策略应创建消息大小的自然分布。
Disadvantage: Random-Length Padding allows an attacker who can observe a large number of requests to infer the length of the original value by observing the distribution of total lengths.
缺点：随机长度填充允许能够观察大量请求的攻击者通过观察总长度的分布来推断原始值的长度。
According to the limited empirical data available, Random-Length Padding exposes slightly more entropy to an attacker than Block-Length Padding. Because of that, and the risk outlined above, Random-Length Padding is NOT RECOMMENDED.
根据可用的有限经验数据，随机长度填充比块长度填充向攻击者暴露的熵稍多。鉴于上述风险，不建议使用随机长度填充。
This policy combines Block-Length Padding with a random component. Specifically, a sender randomly chooses between a few block length values and then applies Block-Length Padding based on the chosen block length. The random selection of block length might even be reasonably based on a "weak" source of randomness, such as the transaction ID of the message.
此策略将块长度填充与随机组件相结合。具体地说，发送方在几个块长度值之间随机选择，然后基于所选的块长度应用块长度填充。块长度的随机选择甚至可以合理地基于“弱”随机性源，例如消息的事务ID。
Options: Number of and the values for the set of block lengths; source of randomness
选项：块长度集的数量和值；随机性的来源
Advantages: Compared to Block-Length Padding, this creates more variety in the resulting message sizes for a certain individual original message length.
优点：与块长度填充相比，对于特定的原始消息长度，这会使生成的消息大小更加多样化。
Disadvantage: Requires more implementation effort compared to simple Block-Length Padding.
缺点：与简单的块长度填充相比，需要更多的实现工作。
Random-Block-Length Padding requires further empirical study, as do other combinations of padding strategies.
与其他填充策略组合一样，随机块长度填充需要进一步的实证研究。
This document has no IANA actions.
本文档没有IANA操作。
The choice of the right padding policy (and the right parameters for the chosen policy) has a significant impact on the resilience of encrypted DNS against size-based correlation attacks. Therefore, any implementor of the "Padding" option must carefully consider which policies to implement, the default policy chosen, which parameters to make configurable, and the default parameter values.
选择正确的填充策略（以及所选策略的正确参数）对加密DNS抵御基于大小的相关攻击的恢复能力有重大影响。因此，“填充”选项的任何实现者都必须仔细考虑要执行哪些策略、选择的默认策略、哪些可配置参数以及默认参数值。
No matter how carefully a client selects their padding policy, this effort can be jeopardized if the server chooses to apply an ineffective padding policy to the corresponding response packets. Therefore, a client applying the "Padding" option may want to choose a DNS server that applies a padding policy on responses that is at least equally effective.
无论客户机如何小心地选择其填充策略，如果服务器选择对相应的响应数据包应用无效的填充策略，这一努力都可能受到危害。因此，应用“填充”选项的客户端可能希望选择对响应应用填充策略的DNS服务器，该策略至少同样有效。
Note that even with encryption and padding, it might be trivial to identify that the observed traffic is DNS. Also, padding does not prevent information leaks via other side channels (particularly timing information and number of query/response pairs). Countermeasures against such side channels could include injecting artificial "cover traffic" into the stream of DNS messages or delaying DNS responses by a certain amount of jitter. Such strategies are out of the scope of this document. Additionally, there is not enough theoretic analysis or experimental data available to recommend any such countermeasures.
请注意，即使使用加密和填充，识别观察到的流量是DNS也可能是微不足道的。此外，填充并不能防止通过其他侧通道（特别是计时信息和查询/响应对的数量）的信息泄漏。针对此类侧信道的对策可包括向DNS消息流中注入人工“覆盖流量”，或通过一定数量的抖动延迟DNS响应。此类策略不在本文件的范围内。此外，没有足够的理论分析或实验数据来推荐任何此类对策。
[NDSS-PADDING] Gillmor, D., "Empirical DNS Padding Policy", March 2017, <https://dns.cmrg.net/ ndss2017-dprive-empirical-DNS-traffic-size.pdf>.
[NDSS-PADDING]Gillmor，D.，“经验DNS填充政策”，2017年3月<https://dns.cmrg.net/ ndss2017数据驱动经验DNS流量大小。pdf>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, DOI 10.17487/RFC7830, May 2016, <https://www.rfc-editor.org/info/rfc7830>.
[RFC7830]Mayrhofer，A.，“EDNS（0）填充选项”，RFC 7830，DOI 10.17487/RFC7830，2016年5月<https://www.rfc-editor.org/info/rfc7830>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7858]Hu，Z.，Zhu，L.，Heidemann，J.，Mankin，A.，Wessels，D.，和P.Hoffman，“DNS传输层安全规范（TLS）”，RFC 7858，DOI 10.17487/RFC7858，2016年5月<https://www.rfc-editor.org/info/rfc7858>.
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram Transport Layer Security (DTLS)", RFC 8094, DOI 10.17487/RFC8094, February 2017, <https://www.rfc-editor.org/info/rfc8094>.
[RFC8094]Reddy，T.，Wing，D.，和P.Patil，“数据报传输层安全（DTLS）上的DNS”，RFC 8094，DOI 10.17487/RFC8094，2017年2月<https://www.rfc-editor.org/info/rfc8094>.
In the No Padding policy, the "Padding" option is not used, and the size of the final (actually, "non-padded") message obviously exactly matches the size of the unpadded message. Even though this "non-policy" seems redundant in this list, its properties must be considered for cases in which just one of the parties (client or server) applies padding.
在无填充策略中，不使用“填充”选项，最终（实际上是“非填充”）消息的大小显然与未添加消息的大小完全匹配。即使这个“非策略”在这个列表中看起来是多余的，但在只有一方（客户端或服务器）应用填充的情况下，必须考虑它的属性。
Also, this policy is required when the remaining message size of the unpadded message does not allow for the "Padding" option to be included -- i.e., there are fewer than 4 octets left.
此外，当未添加消息的剩余消息大小不允许包含“填充”选项时，也就是说，剩余的八位组少于4个时，需要此策略。
Advantages: This policy requires no additional resources on the client, server, and network side.
优点：此策略不需要客户端、服务器端和网络端的额外资源。
Disadvantages: The original size of the message remains unchanged; hence, this approach provides no additional confidentiality.
缺点：消息的原始大小保持不变；因此，这种方法不提供额外的保密性。
The No Padding policy MUST NOT be used unless message size disallows the use of the "Padding" option.
除非消息大小不允许使用“填充”选项，否则不得使用“无填充”策略。
In Fixed-Length Padding, a sender chooses to pad each message with a padding of constant length.
在固定长度填充中，发送者选择用固定长度的填充填充每条消息。
Options: Actual length of padding
选项：填充的实际长度
Advantages: Since the padding is constant in length, this policy is very easy to implement and at least ensures that the message length diverges from the length of the original packet (even if only by a fixed value).
优点：由于填充的长度是恒定的，因此该策略非常容易实现，并且至少确保消息长度偏离原始数据包的长度（即使只偏离固定值）。
Disadvantage: Obviously, the amount of padding is easily discoverable from a single unencrypted message or by observing message patterns. When a public DNS server applies this policy, the length of the padding hence must be assumed to be public knowledge. Therefore, this policy is (almost) as useless as the No Padding policy described above.
缺点：显然，填充量很容易从单个未加密消息或通过观察消息模式发现。当公共DNS服务器应用此策略时，必须假定填充长度为公共知识。因此，此策略（几乎）与上述无填充策略一样无用。
The Fixed-Length Padding policy MUST NOT be used except for test applications.
除测试应用程序外，不得使用固定长度填充策略。
Acknowledgements
致谢
Daniel K. Gillmor performed empirical research out of which the "Recommended Strategy" was copied. Stephane Bortzmeyer and Hugo Connery provided text. Shane Kerr, Sara Dickinson, Paul Hoffman, Magnus Westerlund, Charlie Kaufman, Joe Clarke, and Meral Shirazipour performed reviews or provided substantial comments.
Daniel K.Gillmor进行了实证研究，从中复制了“推荐策略”。Stephane Bortzmeyer和Hugo Connery提供了文本。Shane Kerr、Sara Dickinson、Paul Hoffman、Magnus Westerlund、Charlie Kaufman、Joe Clarke和Meral Shirazipour进行了评论或提供了实质性意见。
Author's Address
作者地址
Alexander Mayrhofer nic.at GmbH Karlsplatz 1/2/9 Vienna 1010 Austria
Alexander Mayrhofer nic.at GmbH卡尔斯普拉茨1/2/9奥地利维也纳1010
Email: alex.mayrhofer.ietf@gmail.com
URI: http://edns0-padding.org/
Email: alex.mayrhofer.ietf@gmail.com
URI: http://edns0-padding.org/