RFC 3225: Indicating Resolver Support of DNSSEC 中文翻译

URL : https://datatracker.ietf.org/doc/html/rfc3225
标题 : RFC 3225
翻译类型 : 自动生成

Network Working Group                                          D. Conrad
Request for Comments: 3225                                 Nominum, Inc.
Category: Standards Track                                  December 2001

Network Working Group                                          D. Conrad
Request for Comments: 3225                                 Nominum, Inc.
Category: Standards Track                                  December 2001

Indicating Resolver Support of DNSSEC

指示DNSSEC的分解器支持

Status of this Memo

本备忘录的状况

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。

版权公告

Abstract

摘要

In order to deploy DNSSEC (Domain Name System Security Extensions) operationally, DNSSEC aware servers should only perform automatic inclusion of DNSSEC RRs when there is an explicit indication that the resolver can understand those RRs. This document proposes the use of a bit in the EDNS0 header to provide that explicit indication and describes the necessary protocol changes to implement that notification.

为了在操作上部署DNSSEC（域名系统安全扩展），支持DNSSEC的服务器只应在明确指示解析程序可以理解这些RRs时自动包含DNSSEC RRs。本文件建议在EDNS0报头中使用位来提供该明确指示，并描述了实现该通知所需的协议更改。

1. Introduction

1. 介绍

DNSSEC [RFC2535] has been specified to provide data integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures. However, as DNSSEC is deployed, non-DNSSEC-aware clients will likely query DNSSEC-aware servers. In such situations, the DNSSEC-aware server (responding to a request for data in a signed zone) will respond with SIG, KEY, and/or NXT records. For reasons described in the subsequent section, such responses can have significant negative operational impacts for the DNS infrastructure.

DNSSEC[RFC2535]已被指定通过使用加密数字签名为具有安全意识的解析器和应用程序提供数据完整性和身份验证。但是，随着DNSSEC的部署，不支持DNSSEC的客户端可能会查询支持DNSSEC的服务器。在这种情况下，DNSSEC感知服务器（响应签名区域中的数据请求）将使用SIG、KEY和/或NXT记录进行响应。由于下文所述的原因，此类响应可能会对DNS基础设施产生重大的负面运营影响。

This document discusses a method to avoid these negative impacts, namely DNSSEC-aware servers should only respond with SIG, KEY, and/or NXT RRs when there is an explicit indication from the resolver that it can understand those RRs.

本文档讨论了一种避免这些负面影响的方法，即当解析程序明确表示可以理解这些RRs时，支持DNSSEC的服务器应仅使用SIG、KEY和/或NXT RRs进行响应。

For the purposes of this document, "DNSSEC security RRs" are considered RRs of type SIG, KEY, or NXT.

在本文件中，“DNSSEC安全RRs”被视为SIG、KEY或NXT类型的RRs。

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]中所述进行解释。

2. Rationale

2. 根本原因

Initially, as DNSSEC is deployed, the vast majority of queries will be from resolvers that are not DNSSEC aware and thus do not understand or support the DNSSEC security RRs. When a query from such a resolver is received for a DNSSEC signed zone, the DNSSEC specification indicates the nameserver must respond with the appropriate DNSSEC security RRs. As DNS UDP datagrams are limited to 512 bytes [RFC1035], responses including DNSSEC security RRs have a high probability of resulting in a truncated response being returned and the resolver retrying the query using TCP.

最初，随着DNSSEC的部署，绝大多数查询将来自不了解DNSSEC的解析程序，因此不理解或支持DNSSEC安全RRs。当收到来自此类解析程序的DNSSEC签名区域的查询时，DNSSEC规范指示名称服务器必须使用适当的DNSSEC安全RRs进行响应。由于DNS UDP数据报被限制为512字节[RFC1035]，包括DNSSEC安全RRs在内的响应极有可能导致返回截断响应，并且解析程序使用TCP重试查询。

TCP DNS queries result in significant overhead due to connection setup and teardown. Operationally, the impact of these TCP queries will likely be quite detrimental in terms of increased network traffic (typically five packets for a single query/response instead of two), increased latency resulting from the additional round trip times, increased incidences of queries failing due to timeouts, and significantly increased load on nameservers.

由于连接设置和断开，TCP DNS查询会导致大量开销。在操作上，这些TCP查询的影响可能非常有害，因为网络流量增加（通常一个查询/响应有五个数据包，而不是两个）、额外往返时间导致的延迟增加、超时导致查询失败的发生率增加，并显著增加了名称服务器上的负载。

In addition, in preliminary and experimental deployment of DNSSEC, there have been reports of non-DNSSEC aware resolvers being unable to handle responses which contain DNSSEC security RRs, resulting in the resolver failing (in the worst case) or entire responses being ignored (in the better case).

此外，在DNSSEC的初步和实验部署中，有报告称非DNSSEC感知的解析器无法处理包含DNSSEC安全RRs的响应，导致解析器失败（在最坏的情况下）或忽略整个响应（在更好的情况下）。

Given these operational implications, explicitly notifying the nameserver that the client is prepared to receive (if not understand) DNSSEC security RRs would be prudent.

考虑到这些操作影响，明确通知名称服务器客户端准备接收（如果不理解）DNSSEC安全RRs是谨慎的。

Client-side support of DNSSEC is assumed to be binary -- either the client is willing to receive all DNSSEC security RRs or it is not willing to accept any. As such, a single bit is sufficient to indicate client-side DNSSEC support. As effective use of DNSSEC implies the need of EDNS0 [RFC2671], bits in the "classic" (non-EDNS enhanced DNS header) are scarce, and there may be situations in which non-compliant caching or forwarding servers inappropriately copy data from classic headers as queries are passed on to authoritative servers, the use of a bit from the EDNS0 header is proposed.

假定DNSSEC的客户端支持是二进制的——要么客户端愿意接收所有DNSSEC安全RRs，要么客户端不愿意接受任何安全RRs。因此，单个位足以表示客户端DNSSEC支持。由于DNSSEC的有效使用意味着需要EDNS0[RFC2671]，因此“经典”（非EDNS增强型DNS标头）中的位很少，并且可能存在不符合要求的缓存或转发服务器在将查询传递到权威服务器时不适当地从经典标头复制数据的情况，建议使用来自EDNS0报头的位。

An alternative approach would be to use the existence of an EDNS0 header as an implicit indication of client-side support of DNSSEC. This approach was not chosen as there may be applications in which EDNS0 is supported but in which the use of DNSSEC is inappropriate.

另一种方法是使用EDNS0头的存在作为DNSSEC客户端支持的隐式指示。未选择此方法，因为可能存在支持EDNS0但不适合使用DNSSEC的应用程序。

3. Protocol Changes

3. 协议变更

The mechanism chosen for the explicit notification of the ability of the client to accept (if not understand) DNSSEC security RRs is using the most significant bit of the Z field on the EDNS0 OPT header in the query. This bit is referred to as the "DNSSEC OK" (DO) bit. In the context of the EDNS0 OPT meta-RR, the DO bit is the first bit of the third and fourth bytes of the "extended RCODE and flags" portion of the EDNS0 OPT meta-RR, structured as follows:

为明确通知客户端接受（如果不理解）DNSSEC安全RRs的能力而选择的机制是使用查询中EDNS0 OPT头上Z字段的最高有效位。该位称为“DNSSEC OK”（DO）位。在EDNS0 OPT meta RR的上下文中，DO位是EDNS0 OPT meta RR的“扩展RCODE和标志”部分的第三和第四字节的第一位，其结构如下：

                +0 (MSB)                +1 (LSB)
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      0: |   EXTENDED-RCODE      |       VERSION         |
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      2: |DO|                    Z                       |
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

                +0 (MSB)                +1 (LSB)
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      0: |   EXTENDED-RCODE      |       VERSION         |
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      2: |DO|                    Z                       |
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Setting the DO bit to one in a query indicates to the server that the resolver is able to accept DNSSEC security RRs. The DO bit cleared (set to zero) indicates the resolver is unprepared to handle DNSSEC security RRs and those RRs MUST NOT be returned in the response (unless DNSSEC security RRs are explicitly queried for). The DO bit of the query MUST be copied in the response.

在查询中将DO位设置为1，表示解析程序能够接受DNSSEC安全RRs。清除DO位（设置为零）表示解析程序未准备好处理DNSSEC安全RRs，并且这些RRs不得在响应中返回（除非明确查询DNSSEC安全RRs）。必须在响应中复制查询的DO位。

More explicitly, DNSSEC-aware nameservers MUST NOT insert SIG, KEY, or NXT RRs to authenticate a response as specified in [RFC2535] unless the DO bit was set on the request. Security records that match an explicit SIG, KEY, NXT, or ANY query, or are part of the zone data for an AXFR or IXFR query, are included whether or not the DO bit was set.

更明确地说，DNSSEC感知的名称服务器不得插入SIG、KEY或NXT RRs以验证[RFC2535]中指定的响应，除非在请求上设置了DO位。无论是否设置了DO位，都会包含与显式SIG、KEY、NXT或任何查询匹配的安全记录，或者是AXFR或IXFR查询的区域数据的一部分。

A recursive DNSSEC-aware server MUST set the DO bit on recursive requests, regardless of the status of the DO bit on the initiating resolver request. If the initiating resolver request does not have the DO bit set, the recursive DNSSEC-aware server MUST remove DNSSEC security RRs before returning the data to the client, however cached data MUST NOT be modified.

递归DNSSEC感知服务器必须在递归请求上设置DO位，而不管启动解析程序请求上DO位的状态如何。如果启动的冲突解决程序请求未设置DO位，递归DNSSEC感知服务器必须在将数据返回到客户端之前删除DNSSEC安全RRs，但不得修改缓存的数据。

In the event a server returns a NOTIMP, FORMERR or SERVFAIL response to a query that has the DO bit set, the resolver SHOULD NOT expect DNSSEC security RRs and SHOULD retry the query without EDNS0 in accordance with section 5.3 of [RFC2671].

如果服务器对设置了DO位的查询返回NOTIMP、FORMERR或SERVFAIL响应，解析程序不应期待DNSSEC安全RRs，并应根据[RFC2671]第5.3节在没有EDNS0的情况下重试查询。

Security Considerations

安全考虑

The absence of DNSSEC data in response to a query with the DO bit set MUST NOT be taken to mean no security information is available for that zone as the response may be forged or a non-forged response of an altered (DO bit cleared) query.

对于设置了DO位的查询，如果没有DNSSEC数据，则不能认为该区域没有可用的安全信息，因为响应可能是伪造的，或者是更改（清除DO位）查询的非伪造响应。

IANA Considerations

IANA考虑

EDNS0 [RFC2671] defines 16 bits as extended flags in the OPT record, these bits are encoded into the TTL field of the OPT record (RFC2671 section 4.6).

EDNS0[RFC2671]将16位定义为OPT记录中的扩展标志，这些位被编码到OPT记录的TTL字段中（RFC2671第4.6节）。

This document reserves one of these bits as the OK bit. It is requested that the left most bit be allocated. Thus the USE of the OPT record TTL field would look like

本文档保留其中一位作为OK位。请求分配最左边的位。因此，OPT record TTL字段的使用如下

                +0 (MSB)                +1 (LSB)
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      0: |   EXTENDED-RCODE      |       VERSION         |
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      2: |DO|                    Z                       |
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

                +0 (MSB)                +1 (LSB)
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      0: |   EXTENDED-RCODE      |       VERSION         |
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      2: |DO|                    Z                       |
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Acknowledgements

致谢

This document is based on a rough draft by Bob Halley with input from Olafur Gudmundsson, Andreas Gustafsson, Brian Wellington, Randy Bush, Rob Austein, Steve Bellovin, and Erik Nordmark.

本文件基于Bob Halley的草稿，由Olafur Gudmundsson、Andreas Gustafsson、Brian Wellington、Randy Bush、Rob Austein、Steve Bellovin和Erik Nordmark提供意见。

References

工具书类

[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.

[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。

[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specifications", STD 13, RFC 1035, November 1987.

[RFC1035]Mockapetris，P.，“域名-实施和规范”，STD 13，RFC 1035，1987年11月。

[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月。

[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.

[RFC2535]Eastlake，D.，“域名系统安全扩展”，RFC25351999年3月。

[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.

[RFC2671]Vixie，P.，“DNS的扩展机制（EDNS0）”，RFC 26711999年8月。

Author's Address

作者地址

David Conrad Nominum Inc. 950 Charter Street Redwood City, CA 94063 USA

David Conrad Nominum Inc.美国加利福尼亚州红木市Charter Street 950号，邮编94063

   Phone: +1 650 381 6003
   EMail: david.conrad@nominum.com

   Phone: +1 650 381 6003
   EMail: david.conrad@nominum.com

Full Copyright Statement

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。

Acknowledgement

确认

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC编辑功能的资金目前由互联网协会提供。