Network Working Group R. Bellis
Request for Comments: 5625 Nominet UK
BCP: 152 August 2009
Category: Best Current Practice
Network Working Group R. Bellis
Request for Comments: 5625 Nominet UK
BCP: 152 August 2009
Category: Best Current Practice
DNS Proxy Implementation Guidelines
DNS代理实施指南
Abstract
摘要
This document provides guidelines for the implementation of DNS proxies, as found in broadband gateways and other similar network devices.
本文档提供了在宽带网关和其他类似网络设备中实现DNS代理的指南。
Status of This Memo
关于下段备忘
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................3
3. The Transparency Principle ......................................3
4. Protocol Conformance ............................................4
4.1. Unexpected Flags and Data ..................................4
4.2. Label Compression ..........................................4
4.3. Unknown Resource Record Types ..............................4
4.4. Packet Size Limits .........................................4
4.4.1. TCP Transport .......................................5
4.4.2. Extension Mechanisms for DNS (EDNS0) ................6
4.4.3. IP Fragmentation ....................................6
4.5. Secret Key Transaction Authentication for DNS (TSIG) .......7
5. DHCP's Interaction with DNS .....................................7
5.1. Domain Name Server (DHCP Option 6) .........................7
5.2. Domain Name (DHCP Option 15) ...............................8
5.3. DHCP Leases ................................................8
6. Security Considerations .........................................9
6.1. Forgery Resilience .........................................9
6.2. Interface Binding .........................................10
6.3. Packet Filtering ..........................................10
7. Acknowledgements ...............................................10
8. References .....................................................11
8.1. Normative References ......................................11
8.2. Informative References ....................................12
1. Introduction ....................................................2
2. Terminology .....................................................3
3. The Transparency Principle ......................................3
4. Protocol Conformance ............................................4
4.1. Unexpected Flags and Data ..................................4
4.2. Label Compression ..........................................4
4.3. Unknown Resource Record Types ..............................4
4.4. Packet Size Limits .........................................4
4.4.1. TCP Transport .......................................5
4.4.2. Extension Mechanisms for DNS (EDNS0) ................6
4.4.3. IP Fragmentation ....................................6
4.5. Secret Key Transaction Authentication for DNS (TSIG) .......7
5. DHCP's Interaction with DNS .....................................7
5.1. Domain Name Server (DHCP Option 6) .........................7
5.2. Domain Name (DHCP Option 15) ...............................8
5.3. DHCP Leases ................................................8
6. Security Considerations .........................................9
6.1. Forgery Resilience .........................................9
6.2. Interface Binding .........................................10
6.3. Packet Filtering ..........................................10
7. Acknowledgements ...............................................10
8. References .....................................................11
8.1. Normative References ......................................11
8.2. Informative References ....................................12
Research has found ([SAC035], [DOTSE]) that many commonly used broadband gateways (and similar devices) contain DNS proxies that are incompatible in various ways with current DNS standards.
研究发现（[SAC035]，[DOTSE]）许多常用的宽带网关（和类似设备）包含DNS代理，这些代理在不同方面与当前的DNS标准不兼容。
These proxies are usually simple DNS forwarders, but typically do not have any caching capabilities. The proxy serves as a convenient default DNS resolver for clients on the LAN, but relies on an upstream resolver (e.g., at an ISP) to perform recursive DNS lookups.
这些代理通常是简单的DNS转发器，但通常没有任何缓存功能。该代理作为局域网上客户端的一个方便的默认DNS解析程序，但依赖于上游解析程序（如ISP）执行递归DNS查找。
Note that to ensure full DNS protocol interoperability it is preferred that client stub resolvers should communicate directly with full-feature, upstream recursive resolvers wherever possible.
请注意，为了确保完整的DNS协议互操作性，最好是客户端存根解析程序应尽可能直接与完整功能的上游递归解析程序通信。
That notwithstanding, this document describes the incompatibilities that have been discovered and offers guidelines to implementors on how to provide better interoperability in those cases where the client must use the broadband gateway's DNS proxy.
尽管如此，本文档描述了已发现的不兼容性，并为实施者提供了指南，指导他们在客户端必须使用宽带网关的DNS代理的情况下如何提供更好的互操作性。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
It is not considered practical for a simple DNS proxy to implement all current and future DNS features.
一个简单的DNS代理实现所有当前和未来的DNS功能是不现实的。
There are several reasons why this is the case:
出现这种情况的原因有几个：
o Broadband gateways usually have limited hardware resources.
o 宽带网关通常具有有限的硬件资源。
o Firmware upgrade cycles are long, and many users do not routinely apply upgrades when they become available.
o 固件升级周期很长，许多用户在升级可用时不会定期应用升级。
o No one knows what those future DNS features will be or how they might be implemented.
o 没有人知道这些未来的DNS功能将是什么，或者它们将如何实现。
o Doing so would substantially complicate the configuration user interface (UI) of the device.
o 这样做将大大复杂化设备的配置用户界面（UI）。
Furthermore, some modern DNS protocol extensions (see, e.g., EDNS0 below) are intended to be used as "hop-by-hop" mechanisms. If the DNS proxy is considered to be such a "hop" in the resolution chain, then for it to function correctly, it would need to be fully compliant with all such mechanisms.
此外，一些现代DNS协议扩展（例如，参见下面的EDNS0）打算用作“逐跳”机制。如果DNS代理被认为是解析链中的一个“跃点”，那么为了使其正常工作，它需要完全符合所有这些机制。
[SAC035] shows that the more actively a proxy participates in the DNS protocol, the more likely it is that it will somehow interfere with the flow of messages between the DNS client and the upstream recursive resolvers.
[SAC035]表明，代理参与DNS协议越积极，就越有可能以某种方式干扰DNS客户端和上游递归解析程序之间的消息流。
The role of the proxy should therefore be no more and no less than to receive DNS requests from clients on the LAN side, forward those verbatim to one of the known upstream recursive resolvers on the WAN side, and ensure that the whole response is returned verbatim to the original client.
因此，代理的作用不应大于或小于从LAN端的客户端接收DNS请求，将这些逐字转发给WAN端的一个已知上游递归解析器，并确保将整个响应逐字返回给原始客户端。
It is RECOMMENDED that proxies should be as transparent as possible, such that any "hop-by-hop" mechanisms or newly introduced protocol extensions operate as if the proxy were not there.
建议代理应尽可能透明，以便任何“逐跳”机制或新引入的协议扩展都可以像代理不存在一样运行。
Except when required to enforce an active security or network policy (such as maintaining a pre-authentication "walled garden"), end-users SHOULD be able to send their DNS queries to specified upstream
除非需要强制实施主动安全或网络策略（如维护预认证“围墙花园”），最终用户应能够将其DNS查询发送到指定的上游
resolvers, thereby bypassing the proxy altogether. In this case, the gateway SHOULD NOT modify the DNS request or response packets in any way.
解析程序，从而完全绕过代理。在这种情况下，网关不应以任何方式修改DNS请求或响应数据包。
The Transparency Principle above, when combined with Postel's Robustness Principle [RFC0793], suggests that DNS proxies should not arbitrarily reject or otherwise drop requests or responses based on perceived non-compliance with standards.
上述透明度原则与Postel的稳健性原则[RFC0793]相结合，表明DNS代理不应基于感知到的不符合标准而任意拒绝或以其他方式丢弃请求或响应。
For example, some proxies have been observed to drop any packet containing either the "Authentic Data" (AD) or "Checking Disabled" (CD) bits from DNSSEC [RFC4035]. This may be because [RFC1035] originally specified that these unused "Z" flag bits "MUST" be zero. However, these flag bits were always intended to be reserved for future use, so refusing to proxy any packet containing these flags (now that uses for those flags have indeed been defined) is not appropriate.
例如，已观察到一些代理从DNSSEC[RFC4035]丢弃包含“真实数据”（AD）或“检查禁用”（CD）位的任何数据包。这可能是因为[RFC1035]最初指定这些未使用的“Z”标志位“必须”为零。然而，这些标志位总是为了将来的使用而保留的，因此拒绝代理包含这些标志的任何数据包（现在这些标志的用途确实已经定义）是不合适的。
Therefore, proxies MUST ignore any unknown DNS flags and proxy those packets as usual.
因此，代理必须忽略任何未知的DNS标志，并像往常一样代理这些数据包。
Compression of labels as per Section 4.1.4 of [RFC1035] is optional.
根据[RFC1035]第4.1.4节压缩标签是可选的。
Proxies MUST forward packets regardless of the presence or absence of compressed labels therein.
代理必须转发数据包，无论其中是否存在压缩标签。
[RFC3597] requires that resolvers MUST handle Resource Records (RRs) of unknown type transparently.
[RFC3597]要求解析程序必须透明地处理未知类型的资源记录（RRs）。
All requests and responses MUST be proxied regardless of the values of the QTYPE and QCLASS fields.
无论QTYPE和QCLASS字段的值如何，都必须代理所有请求和响应。
Similarly, all responses MUST be proxied regardless of the values of the TYPE and CLASS fields of any Resource Record therein.
类似地，无论其中任何资源记录的类型和类字段的值如何，都必须代理所有响应。
[RFC1035] specifies that the maximum size of the DNS payload in a UDP packet is 512 octets. Where the required portions of a response would not fit inside that limit, the DNS server MUST set the
[RFC1035]指定UDP数据包中DNS有效负载的最大大小为512个八位字节。如果响应的所需部分不符合该限制，DNS服务器必须设置
"TrunCation" (TC) bit in the DNS response header to indicate that truncation has occurred. There are however two standard mechanisms (described in Sections 4.4.1 and 4.4.2) for transporting responses larger than 512 octets.
DNS响应标头中的“截断”（TC）位，用于指示已发生截断。然而，有两种标准机制（在第4.4.1节和第4.4.2节中描述）用于传输大于512个八位字节的响应。
Many proxies have been observed to truncate all responses at 512 octets, and others at a packet size related to the WAN MTU, in either case doing so without correctly setting the TC bit.
已观察到许多代理在512个八位字节处截断所有响应，其他代理在与WAN MTU相关的数据包大小处截断所有响应，在任何一种情况下都没有正确设置TC位。
Other proxies have been observed to remove the TC bit in server responses that correctly had the TC bit set by the server.
已观察到其他代理删除服务器响应中的TC位，这些响应正确地由服务器设置了TC位。
If a DNS response is truncated but the TC bit is not set, then client failures may result. In particular, a naive DNS client library might suffer crashes due to reading beyond the end of the data actually received.
如果DNS响应被截断，但未设置TC位，则可能导致客户端失败。特别是，原始DNS客户端库可能会由于读取超出实际接收数据的末尾而发生崩溃。
Since UDP packets larger than 512 octets are now expected in normal operation, proxies SHOULD NOT truncate UDP packets that exceed that size. See Section 4.4.3 for recommendations for packet sizes exceeding the WAN MTU.
由于在正常操作中预期UDP数据包大于512个八位字节，因此代理不应截断超过该大小的UDP数据包。有关超过WAN MTU的数据包大小的建议，请参见第4.4.3节。
If a proxy must unilaterally truncate a response, then the proxy MUST set the TC bit. Similarly, proxies MUST NOT remove the TC bit from responses.
如果代理必须单方面截断响应，则代理必须设置TC位。同样，代理不得从响应中删除TC位。
Should a UDP query fail because of truncation, the standard fail-over mechanism is to retry the query using TCP, as described in Section 6.1.3.2 of [RFC1123].
如果UDP查询因截断而失败，标准故障转移机制是使用TCP重试查询，如[RFC1123]第6.1.3.2节所述。
Whilst TCP transport is not strictly mandatory, it is supported by the vast majority of stub resolvers and recursive servers. Lack of support in the proxy prevents this fail-over mechanism from working.
虽然TCP传输不是严格强制的，但绝大多数存根解析器和递归服务器都支持它。代理中缺少支持会阻止此故障转移机制工作。
DNS proxies MUST therefore be prepared to receive and forward queries over TCP.
因此，DNS代理必须准备好通过TCP接收和转发查询。
Note that it is unlikely that a client would send a request over TCP unless it had already received a truncated UDP response. Some "smart" proxies have been observed to first forward any request received over TCP to an upstream resolver over UDP, only for the response to be truncated, causing the proxy to retry over TCP. Such behaviour increases network traffic and causes delay in DNS resolution since the initial UDP request is doomed to fail.
请注意，客户端不太可能通过TCP发送请求，除非它已经收到截断的UDP响应。观察到一些“智能”代理首先通过UDP将通过TCP收到的任何请求转发给上游解析器，只是为了截断响应，从而导致代理通过TCP重试。这种行为会增加网络流量并导致DNS解析延迟，因为初始UDP请求注定会失败。
Therefore, whenever a proxy receives a request over TCP, the proxy SHOULD forward the query over TCP and SHOULD NOT attempt the same query over UDP first.
因此，每当代理通过TCP接收请求时，代理应通过TCP转发查询，而不应首先尝试通过UDP进行相同的查询。
The "Extension Mechanism for DNS" [RFC2671] was introduced to allow the transport of larger DNS packets over UDP and also to allow for additional request and response flags.
引入了“DNS扩展机制”[RFC2671]，以允许通过UDP传输较大的DNS数据包，并允许附加的请求和响应标志。
A client may send an OPT Resource Record (OPT RR) in the Additional Section of a request to indicate that it supports a specific receive buffer size. The OPT RR also includes the "DNSSEC OK" (DO) flag used by DNSSEC to indicate that DNSSEC-related RRs should be returned to the client.
客户端可以在请求的附加部分发送OPT资源记录（OPT RR），以指示它支持特定的接收缓冲区大小。OPT RR还包括DNSSEC使用的“DNSSEC OK”（DO）标志，以指示应将与DNSSEC相关的RRs返回给客户端。
However, some proxies have been observed to either reject (with a FORMERR response code) or black-hole any packet containing an OPT RR. As per Section 4.1, proxies MUST NOT refuse to proxy such packets.
然而，已经观察到一些代理拒绝（使用FORMERR响应代码）或黑洞包含OPT RR的任何数据包。根据第4.1节，代理不得拒绝代理此类数据包。
Support for UDP packet sizes exceeding the WAN MTU depends on the gateway's algorithm for handling fragmented IP packets. Several methods are possible:
对超过WAN MTU的UDP数据包大小的支持取决于网关处理分段IP数据包的算法。有几种可能的方法：
1. Fragments are dropped.
1. 碎片被丢弃。
2. Fragments are forwarded individually as they're received.
2. 片段在接收时被单独转发。
3. Complete packets are reassembled on the gateway and then re-fragmented (if necessary) as they're forwarded to the client.
3. 完整的数据包在网关上重新组装，然后在转发到客户端时重新分段（如有必要）。
Method 1 above will cause compatibility problems with EDNS0 unless the DNS client is configured to advertise an EDNS0 buffer size limited to the WAN MTU less the size of the IP header. Note that RFC 2671 does recommend that the path MTU should be taken into account when using EDNS0.
上述方法1将导致与EDNS0的兼容性问题，除非DNS客户端配置为公布EDNS0缓冲区大小，该缓冲区大小限制为WAN MTU小于IP标头的大小。请注意，RFC 2671建议在使用EDNS0时应考虑路径MTU。
Also, whilst the EDNS0 specification allows for a buffer size of up to 65535 octets, most common DNS server implementations do not support a buffer size above 4096 octets.
此外，虽然EDNS0规范允许缓冲区大小最多为65535个八位字节，但大多数常见的DNS服务器实现不支持缓冲区大小超过4096个八位字节。
Therefore (irrespective of which of the above methods is in use), proxies SHOULD be capable of forwarding UDP packets up to a payload size of at least 4096 octets.
因此（无论使用上述哪种方法），代理应该能够转发UDP数据包，其有效负载大小至少为4096个八位字节。
NB: in theory, IP fragmentation may also occur if the LAN MTU is smaller than the WAN MTU, although the author has not observed such a configuration in use on any residential broadband service.
注意：理论上，如果LAN MTU小于WAN MTU，则也可能发生IP碎片，尽管作者没有在任何住宅宽带服务上观察到这种配置。
[RFC2845] defines TSIG, which is a mechanism for authenticating DNS requests and responses at the packet level.
[RFC2845]定义了TSIG，这是一种在数据包级别验证DNS请求和响应的机制。
Any modifications made to the DNS portions of a TSIG-signed query or response packet (with the exception of the Query ID) will cause a TSIG authentication failure.
对TSIG签名查询或响应数据包的DNS部分所做的任何修改（查询ID除外）都将导致TSIG身份验证失败。
DNS proxies MUST implement Section 4.7 of [RFC2845] and either forward packets unchanged (as recommended above) or fully implement TSIG.
DNS代理必须实现[RFC2845]第4.7节，转发数据包不变（如上所述）或完全实现TSIG。
As per Section 4.3, DNS proxies MUST be capable of proxying packets containing TKEY [RFC2930] Resource Records.
根据第4.3节，DNS代理必须能够代理包含TKEY[RFC2930]资源记录的数据包。
NB: any DNS proxy (such as those commonly found in WiFi hotspot "walled gardens") that transparently intercepts all DNS queries and that returns unsigned responses to signed queries, will also cause TSIG authentication failures.
注意：任何DNS代理（如WiFi热点“围墙花园”中常见的DNS代理）都会透明地拦截所有DNS查询，并对已签名的查询返回未签名的响应，这也会导致TSIG身份验证失败。
Whilst this document is primarily about DNS proxies, most consumers rely on DHCP [RFC2131] to obtain network configuration settings. Such settings include the client machine's IP address, subnet mask, and default gateway, but also include DNS-related settings.
虽然本文档主要是关于DNS代理的，但大多数消费者依靠DHCP[RFC2131]来获得网络配置设置。此类设置包括客户端计算机的IP地址、子网掩码和默认网关，但也包括与DNS相关的设置。
It is therefore appropriate to examine how DHCP affects client DNS configuration.
因此，检查DHCP如何影响客户端DNS配置是合适的。
Most gateways default to supplying their own IP address in the DHCP "Domain Name Server" option [RFC2132]. The net result is that without explicit re-configuration many DNS clients will, by default, send queries to the gateway's DNS proxy. This is understandable behaviour given that the correct upstream settings are not usually known at boot time.
大多数网关默认在DHCP“域名服务器”选项[RFC2132]中提供自己的IP地址。最终的结果是，在没有显式重新配置的情况下，默认情况下，许多DNS客户端将向网关的DNS代理发送查询。这是可以理解的行为，因为在引导时通常不知道正确的上游设置。
Most gateways learn their own DNS settings via values supplied by an ISP via DHCP or PPP over the WAN interface. However, whilst many gateways do allow the device administrator to override those values, some gateways only use those supplied values to affect the proxy's own forwarding function, and do not offer these values via DHCP.
大多数网关通过ISP通过DHCP或PPP通过WAN接口提供的值来学习自己的DNS设置。然而，尽管许多网关允许设备管理员覆盖这些值，但一些网关仅使用这些提供的值来影响代理自身的转发功能，并且不通过DHCP提供这些值。
When using such a device, the only way to avoid using the DNS proxy is to hard-code the required values in the client operating system. This may be acceptable for a desktop system but it is inappropriate for mobile devices that are regularly used on many different networks.
使用此类设备时，避免使用DNS代理的唯一方法是在客户端操作系统中硬编码所需的值。这对于桌面系统来说是可以接受的，但是对于经常在许多不同网络上使用的移动设备来说是不合适的。
As per Section 3, end-users SHOULD be able to send their DNS queries directly to specified upstream resolvers, ideally without hard-coding those settings in their stub resolver.
根据第3节，最终用户应该能够直接将其DNS查询发送到指定的上游解析程序，理想情况下无需在其存根解析程序中硬编码这些设置。
It is therefore RECOMMENDED that gateways SHOULD support device-administrator configuration of values for the "Domain Name Server" DHCP option.
因此，建议网关支持设备管理员配置“域名服务器”DHCP选项的值。
A significant amount of traffic to the DNS Root Name Servers is for invalid top-level domain names, and some of that traffic can be attributed to particular equipment vendors whose firmware defaults this DHCP option to specific values.
到DNS根名称服务器的大量流量是针对无效的顶级域名的，其中一些流量可归因于特定设备供应商，其固件将此DHCP选项默认为特定值。
Since no standard exists for a "local" scoped domain name suffix, it is RECOMMENDED that the default value for this option SHOULD be empty, and that this option MUST NOT be sent to clients when no value is configured.
由于“本地”范围的域名后缀不存在标准，建议此选项的默认值应为空，并且在未配置任何值时，不得将此选项发送给客户端。
It is noted that some DHCP servers in broadband gateways offer, by default, their own IP address for the "Domain Name Server" option (as described above) but then automatically start offering the upstream servers' addresses once they've been learnt over the WAN interface.
需要注意的是，宽带网关中的一些DHCP服务器默认为“域名服务器”选项（如上所述）提供自己的IP地址，但一旦通过WAN接口了解到上游服务器的地址，就会自动开始提供它们的地址。
In general, this behaviour is highly desirable, but the effect for the end-user is that the settings used depend on whether the DHCP lease was obtained before or after the WAN link was established.
一般来说，这种行为非常理想，但对最终用户的影响是，所使用的设置取决于DHCP租约是在WAN链路建立之前还是之后获得的。
If the DHCP lease is obtained whilst the WAN link is down, then the DHCP client (and hence the DNS client) will not receive the correct values until the DHCP lease is renewed.
如果在WAN链路断开时获得DHCP租约，则DHCP客户端（因此DNS客户端）在DHCP租约续订之前将不会收到正确的值。
Whilst no specific recommendations are given here, vendors may wish to give consideration to the length of DHCP leases and to whether some mechanism for forcing a DHCP lease renewal might be appropriate.
虽然此处未给出具体建议，但供应商可能希望考虑DHCP租约的期限，以及强制DHCP租约续约的某种机制是否合适。
Another possibility is that the learnt upstream values might be persisted in non-volatile memory such that on reboot the same values can be automatically offered via DHCP. However, this does run the risk that incorrect values are initially offered if the device is moved or connected to another ISP.
另一种可能性是，学习到的上游值可能会保留在非易失性内存中，以便在重新启动时，可以通过DHCP自动提供相同的值。但是，如果设备被移动或连接到另一个ISP，则最初提供的值可能不正确。
Alternatively, the DHCP server might only issue very short (i.e., 60 second) leases while the WAN link is down, only reverting to more typical lease lengths once the WAN link is up and the upstream DNS servers are known. Indeed, with such a configuration it may be possible to avoid the need to implement a DNS proxy function in the broadband gateway at all.
或者，DHCP服务器可能仅在WAN链路断开时发出非常短（即60秒）的租约，仅在WAN链路断开且上游DNS服务器已知后恢复到更典型的租约长度。事实上，通过这种配置，可能根本不需要在宽带网关中实现DNS代理功能。
This document introduces no new protocols. However, there are some security-related recommendations for vendors that are listed here.
本文档没有介绍新的协议。但是，这里列出了一些针对供应商的安全相关建议。
Whilst DNS proxies are not usually full-feature resolvers, they nevertheless share some characteristics with them.
虽然DNS代理通常不是全功能解析器，但它们仍具有一些共同的特征。
Notwithstanding the recommendations above about transparency, many DNS proxies are observed to pick a new Query ID for outbound requests to ensure that responses are directed to the correct client.
尽管有上述关于透明度的建议，但仍观察到许多DNS代理为出站请求选择新的查询ID，以确保响应指向正确的客户端。
NB: changing the Query ID is acceptable and compatible with proxying TSIG-signed packets since the TSIG signature calculation is based on the original message ID, which is carried in the TSIG RR.
注意：更改查询ID是可以接受的，并且与代理TSIG签名数据包兼容，因为TSIG签名计算基于TSIG RR中携带的原始消息ID。
It has been standard guidance for many years that each DNS query should use a randomly generated Query ID. However, many proxies have been observed picking sequential Query IDs for successive requests.
多年来，每个DNS查询都应该使用随机生成的查询ID，这一直是标准指南。但是，观察到许多代理为连续请求选择顺序查询ID。
It is strongly RECOMMENDED that DNS proxies follow the relevant recommendations in [RFC5452], particularly those in Section 9.2 relating to randomisation of Query IDs and source ports. This also applies to source port selection within any NAT function.
强烈建议DNS代理遵循[RFC5452]中的相关建议，特别是第9.2节中有关查询ID和源端口随机性的建议。这也适用于任何NAT函数中的源端口选择。
If a DNS proxy is running on a broadband gateway with NAT that is compliant with [RFC4787], then it SHOULD also follow the recommendations in Section 10 of [RFC5452] concerning how long DNS state is kept.
如果DNS代理在具有符合[RFC4787]的NAT的宽带网关上运行，则还应遵循[RFC5452]第10节中关于DNS状态保持多长时间的建议。
Some gateways have been observed to have their DNS proxy listening on both internal (LAN) and external (WAN) interfaces. In this configuration, it is possible for the proxy to be used to mount reflector attacks as described in [RFC5358].
据观察，一些网关的DNS代理在内部（LAN）和外部（WAN）接口上侦听。在此配置中，可以使用代理安装反射器攻击，如[RFC5358]中所述。
The DNS proxy in a gateway SHOULD NOT, by default, be accessible from the WAN interfaces of the device.
默认情况下，网关中的DNS代理不应从设备的WAN接口访问。
The Transparency and Robustness Principles are not entirely compatible with the deep packet-inspection features of security appliances such as firewalls, which are intended to protect systems on the inside of a network from rogue traffic.
透明性和健壮性原则与安全设备（如防火墙）的深度数据包检查功能不完全兼容，防火墙旨在保护网络内部的系统免受恶意流量的影响。
However, a clear distinction may be made between traffic that is intrinsically malformed and that which merely contains unexpected data.
但是，可以明确区分本质上格式不正确的通信量和仅包含意外数据的通信量。
Examples of malformed packets that MAY be dropped include:
可能丢弃的格式错误的数据包示例包括：
o invalid compression pointers (i.e., those that point outside of the current packet or that might cause a parsing loop)
o 无效的压缩指针（即，指向当前数据包之外或可能导致解析循环的指针）
o incorrect counts for the Question, Answer, Authority, and Additional Sections (although care should be taken where truncation is a possibility)
o 问题、答案、权限和附加部分的计数不正确（尽管在可能截断的情况下应小心）
Dropped packets will cause the client to repeatedly retransmit the original request, with the client only detecting the error after several retransmit intervals.
丢弃的数据包将导致客户端重复重新传输原始请求，客户端仅在多次重新传输间隔后检测到错误。
In these circumstances, proxies SHOULD synthesise a suitable DNS error response to the client (i.e., SERVFAIL) instead of dropping the packet completely. This will allow the client to detect the error immediately.
在这些情况下，代理应该向客户端合成合适的DNS错误响应（即SERVFAIL），而不是完全丢弃数据包。这将允许客户端立即检测错误。
The author would particularly like to acknowledge the assistance of Lisa Phifer of Core Competence. In addition, the author is grateful for the feedback from the members of the DNSEXT Working Group.
作者特别要感谢核心竞争力部门Lisa Phifer的帮助。此外，作者感谢DNSEXT工作组成员的反馈。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]Braden，R.，“互联网主机的要求-应用和支持”，STD 3，RFC 1123，1989年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132]Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671]Vixie，P.，“DNS的扩展机制（EDNS0）”，RFC 26711999年8月。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2845]Vixie，P.，Gudmundsson，O.，Eastlake，D.，和B.Wellington，“DNS秘密密钥交易认证（TSIG）”，RFC 28452000年5月。
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000.
[RFC2930]Eastlake，D.，“DNS密钥建立（TKEY RR）”，RFC 29302000年9月。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.
[RFC3597]Gustafsson，A.，“未知DNS资源记录（RR）类型的处理”，RFC3597，2003年9月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787]Audet，F.和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，2007年1月。
[RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive Nameservers in Reflector Attacks", BCP 140, RFC 5358, October 2008.
[RFC5358]Damas，J.和F.Neves，“防止在反射器攻击中使用递归名称服务器”，BCP 140，RFC 5358，2008年10月。
[RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More Resilient against Forged Answers", RFC 5452, January 2009.
[RFC5452]Hubert，A.和R.van Mook，“使DNS对伪造答案更具弹性的措施”，RFC 5452，2009年1月。
[DOTSE] Ahlund and Wallstrom, "DNSSEC Tests of Consumer Broadband Routers", February 2008, <http://www.iis.se/docs/Routertester_en.pdf>.
[DOTSE]Ahlund和Wallstrom，“消费者宽带路由器的DNSSEC测试”，2008年2月<http://www.iis.se/docs/Routertester_en.pdf>.
[SAC035] Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on Broadband Routers and Firewalls", September 2008, <http://www.icann.org/committees/security/sac035.pdf>.
[SAC035]Bellis，R.和L.Phifer，“测试报告：DNSSEC对宽带路由器和防火墙的影响”，2008年9月<http://www.icann.org/committees/security/sac035.pdf>.
Author's Address
作者地址
Ray Bellis Nominet UK Edmund Halley Road Oxford OX4 4DQ United Kingdom
Ray Bellis Nominet UK Edmund Halley Road OX4 4DQ英国牛津大学
Phone: +44 1865 332211
EMail: ray.bellis@nominet.org.uk
URI: http://www.nominet.org.uk/
Phone: +44 1865 332211
EMail: ray.bellis@nominet.org.uk
URI: http://www.nominet.org.uk/