[要約] RFC 6891は、DNSの拡張メカニズムであるEDNS(0)についての仕様を定めたものです。EDNS(0)は、DNSの機能を拡張するための拡張ヘッダーを提供し、DNSの性能やセキュリティを向上させることを目的としています。
Internet Engineering Task Force (IETF) J. Damas
Request for Comments: 6891 Bond Internet Systems
STD: 75 M. Graff
Obsoletes: 2671, 2673
Category: Standards Track P. Vixie
ISSN: 2070-1721 Internet Systems Consortium
April 2013
Extension Mechanisms for DNS (EDNS(0))
DNSの拡張メカニズム（EDNS（0））
Abstract
概要
The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow.
ドメインネームシステムのワイヤプロトコルには、範囲が使い果たされた、または間もなく尽きる多数の固定フィールドが含まれており、リクエスタが自分の機能をレスポンダに通知することはできません。このドキュメントでは、プロトコルの拡張を可能にする下位互換性メカニズムについて説明します。
This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS.
このドキュメントは、いくつかの実装における展開経験からのフィードバックに基づいて、DNS（EDNS（0））仕様の拡張メカニズム（およびRFC 2671を廃止）を更新します。また、RFC 2673（「ドメインネームシステムのバイナリラベル」）を廃止し、DNSでの拡張ラベルの使用に関する考慮事項を追加しています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc6891.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6891で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部で著作権を管理している人が、IETFトラストにそのような素材の変更を許可する権利を付与していない可能性がありますIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. EDNS Support Requirement . . . . . . . . . . . . . . . . . . . 5
4. DNS Message Changes . . . . . . . . . . . . . . . . . . . . . 5
4.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Label Types . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. UDP Message Size . . . . . . . . . . . . . . . . . . . . . 6
5. Extended Label Types . . . . . . . . . . . . . . . . . . . . . 6
6. The OPT Pseudo-RR . . . . . . . . . . . . . . . . . . . . . . 6
6.1. OPT Record Definition . . . . . . . . . . . . . . . . . . 6
6.1.1. Basic Elements . . . . . . . . . . . . . . . . . . . . 6
6.1.2. Wire Format . . . . . . . . . . . . . . . . . . . . . 7
6.1.3. OPT Record TTL Field Use . . . . . . . . . . . . . . . 9
6.1.4. Flags . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2.1. Cache Behaviour . . . . . . . . . . . . . . . . . . . 10
6.2.2. Fallback . . . . . . . . . . . . . . . . . . . . . . . 10
6.2.3. Requestor's Payload Size . . . . . . . . . . . . . . . 10
6.2.4. Responder's Payload Size . . . . . . . . . . . . . . . 11
6.2.5. Payload Size Selection . . . . . . . . . . . . . . . . 11
6.2.6. Support in Middleboxes . . . . . . . . . . . . . . . . 11
7. Transport Considerations . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. OPT Option Code Allocation Procedure . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Changes since RFCs 2671 and 2673 . . . . . . . . . . 16
DNS [RFC1035] specifies a message format, and within such messages there are standard formats for encoding options, errors, and name compression. The maximum allowable size of a DNS message over UDP not using the extensions described in this document is 512 bytes. Many of DNS's protocol limits, such as the maximum message size over UDP, are too small to efficiently support the additional information that can be conveyed in the DNS (e.g., several IPv6 addresses or DNS Security (DNSSEC) signatures). Finally, RFC 1035 does not define any way for implementations to advertise their capabilities to any of the other actors they interact with.
DNS [RFC1035]はメッセージ形式を指定し、そのようなメッセージ内には、エンコードオプション、エラー、および名前の圧縮のための標準形式があります。このドキュメントで説明されている拡張機能を使用しない、UDP経由のDNSメッセージの最大許容サイズは512バイトです。 UDP上の最大メッセージサイズなど、DNSのプロトコル制限の多くは小さすぎて、DNSで伝達できる追加情報（たとえば、複数のIPv6アドレスやDNSセキュリティ（DNSSEC）署名）を効率的にサポートできません。最後に、RFC 1035は、実装が機能を他のアクターとやり取りする方法をアドバタイズする方法を定義していません。
[RFC2671] added extension mechanisms to DNS. These mechanisms are widely supported, and a number of new DNS uses and protocol extensions depend on the presence of these extensions. This memo refines and obsoletes [RFC2671].
[RFC2671]はDNSに拡張メカニズムを追加しました。これらのメカニズムは広くサポートされており、多くの新しいDNSの使用とプロトコル拡張は、これらの拡張の存在に依存しています。このメモは洗練され、時代遅れです[RFC2671]。
Unextended agents will not know how to interpret the protocol extensions defined in [RFC2671] and restated here. Extended agents need to be prepared for handling the interactions with unextended clients in the face of new protocol elements and fall back gracefully to unextended DNS.
非拡張エージェントは、[RFC2671]で定義され、ここで再説明されたプロトコル拡張を解釈する方法を知りません。拡張エージェントは、新しいプロトコル要素に直面して拡張されていないクライアントとのやり取りを処理する準備を整え、拡張されていないDNSに適切にフォールバックする必要があります。
EDNS is a hop-by-hop extension to DNS. This means the use of EDNS is negotiated between each pair of hosts in a DNS resolution process, for instance, the stub resolver communicating with the recursive resolver or the recursive resolver communicating with an authoritative server.
EDNSは、DNSのホップバイホップ拡張です。これは、DNS解決プロセスでホストの各ペア間でEDNSの使用がネゴシエートされることを意味します。たとえば、再帰リゾルバーと通信するスタブリゾルバーや、権限のあるサーバーと通信する再帰リゾルバーなどです。
[RFC2671] specified extended label types. The only such label proposed was in [RFC2673] for a label type called "Bit-String Label" or "Binary Labels", with this latest term being the one in common use. For various reasons, introducing a new label type was found to be extremely difficult, and [RFC2673] was moved to Experimental. This document obsoletes [RFC2673], deprecating Binary Labels. Extended labels remain defined, but their use is discouraged due to practical difficulties with deployment; their use in the future SHOULD only be considered after careful evaluation of the deployment hindrances.
[RFC2671]は、拡張ラベルタイプを指定しました。提案されたそのような唯一のラベルは、「ビットストリングラベル」または「バイナリラベル」と呼ばれるラベルタイプの[RFC2673]にあり、この最新の用語が一般的に使用されているものです。さまざまな理由から、新しいラベルタイプを導入することは非常に困難であることが判明し、[RFC2673]は実験版に移行されました。このドキュメントは[RFC2673]を廃止し、バイナリラベルを非推奨にしました。拡張ラベルは定義されたままですが、展開に関する実際的な問題があるため、使用は推奨されません。将来のそれらの使用は、展開の障害を注意深く評価した後でのみ検討する必要があります。
"Requestor" refers to the side that sends a request. "Responder" refers to an authoritative, recursive resolver or other DNS component that responds to questions. Other terminology is used here as defined in the RFCs cited by this document.
「リクエスタ」とは、リクエストを送信する側を指します。 「レスポンダ」とは、信頼できる、再帰的なリゾルバ、または質問に応答するその他のDNSコンポーネントを指します。このドキュメントで引用されているRFCで定義されている他の用語がここで使用されています。
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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
EDNS provides a mechanism to improve the scalability of DNS as its uses get more diverse on the Internet. It does this by enabling the use of UDP transport for DNS messages with sizes beyond the limits specified in RFC 1035 as well as providing extra data space for additional flags and return codes (RCODEs). However, implementation experience indicates that adding new RCODEs should be avoided due to the difficulty in upgrading the installed base. Flags SHOULD be used only when necessary for DNS resolution to function.
EDNSは、DNSの用途がインターネット上で多様化するにつれて、DNSのスケーラビリティを向上させるメカニズムを提供します。これは、RFC 1035で指定された制限を超えるサイズのDNSメッセージにUDPトランスポートを使用できるようにするとともに、追加のフラグと戻りコード（RCODE）に追加のデータスペースを提供することで実現します。ただし、実装経験から、インストールベースのアップグレードが困難なため、新しいRCODEの追加は避ける必要があることが示されています。フラグは、DNS解決が機能するために必要な場合にのみ使用してください。
For many uses, an EDNS Option Code may be preferred.
多くの用途で、EDNSオプションコードが推奨されます。
Over time, some applications of DNS have made EDNS a requirement for their deployment. For instance, DNSSEC uses the additional flag space introduced in EDNS to signal the request to include DNSSEC data in a DNS response.
時が経つにつれて、DNSの一部のアプリケーションはEDNSをその展開の要件にしています。たとえば、DNSSECはEDNSで導入された追加のフラグスペースを使用して、DNSSECデータをDNS応答に含めるように要求を通知します。
Given the increase in DNS response sizes when including larger data items such as AAAA records, DNSSEC information (e.g., RRSIG or DNSKEY), or large TXT records, the additional UDP payload capabilities provided by EDNS can help improve the scalability of the DNS by avoiding widespread use of TCP for DNS transport.
AAAAレコード、DNSSEC情報（RRSIGやDNSKEYなど）、または大きなTXTレコードなどのより大きなデータアイテムを含める場合のDNS応答サイズの増加を考えると、EDNが提供する追加のUDPペイロード機能により、DNSのスケーラビリティを改善できます。 DNSトランスポートのためのTCPの広範な使用。
The DNS message header's second full 16-bit word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of 1-bit flags (see Section 4.1.1 of [RFC1035]). Some of these flag values were marked for future use, and most of these have since been allocated. Also, most of the RCODE values are now in use. The OPT pseudo-RR specified below contains extensions to the RCODE bit field as well as additional flag bits.
DNSメッセージヘッダーの2番目の完全な16ビットワードは、4ビットOPCODE、4ビットRCODE、およびいくつかの1ビットフラグに分割されます（[RFC1035]のセクション4.1.1を参照）。これらのフラグ値の一部は将来の使用のためにマークされており、それらのほとんどは割り当てられています。また、RCODE値のほとんどが現在使用されています。以下に指定するOPT疑似RRには、RCODEビットフィールドの拡張と追加のフラグビットが含まれています。
The first 2 bits of a wire format domain label are used to denote the type of the label. [RFC1035] allocates 2 of the 4 possible types and reserves the other 2. More label types were defined in [RFC2671]. The use of the 2-bit combination defined by [RFC2671] to identify extended label types remains valid. However, it has been found that deployment of new label types is noticeably difficult and so is only recommended after careful evaluation of alternatives and the need for deployment.
ワイヤフォーマットドメインラベルの最初の2ビットは、ラベルのタイプを示すために使用されます。 [RFC1035]は4つの可能なタイプのうち2つを割り当て、他の2つを予約します。[RFC2671]でより多くのラベルタイプが定義されました。 [RFC2671]で定義されている2ビットの組み合わせを使用して拡張ラベルタイプを識別することは、引き続き有効です。ただし、新しいラベルタイプの導入は非常に難しいことがわかっているため、代替案と導入の必要性を慎重に評価した後にのみ推奨されます。
Traditional DNS messages are limited to 512 octets in size when sent over UDP [RFC1035]. Fitting the increasing amounts of data that can be transported in DNS in this 512-byte limit is becoming more difficult. For instance, inclusion of DNSSEC records frequently requires a much larger response than a 512-byte message can hold.
従来のDNSメッセージは、UDP [RFC1035]経由で送信される場合、サイズが512オクテットに制限されています。 DNSで転送できる増加するデータ量をこの512バイトの制限に合わせるのは、より困難になっています。たとえば、DNSSECレコードを含めるには、512バイトのメッセージが保持できるよりもはるかに大きな応答が必要になることがよくあります。
EDNS(0) specifies a way to advertise additional features such as larger response size capability, which is intended to help avoid truncated UDP responses, which in turn cause retry over TCP. It therefore provides support for transporting these larger packet sizes without needing to resort to TCP for transport.
EDNS（0）は、より大きな応答サイズ機能などの追加機能をアドバタイズする方法を指定します。これは、TCPでの再試行を引き起こす切り捨てられたUDP応答を回避することを目的としています。したがって、トランスポートのためにTCPに頼る必要なく、これらのより大きなパケットサイズをトランスポートするためのサポートを提供します。
The first octet in the on-the-wire representation of a DNS label specifies the label type; the basic DNS specification [RFC1035] dedicates the 2 most significant bits of that octet for this purpose.
DNSラベルの送信中の表現の最初のオクテットは、ラベルタイプを指定します。基本的なDNS仕様[RFC1035]は、このオクテットの2つの最上位ビットをこの目的に使用します。
[RFC2671] defined DNS label type 0b01 for use as an indication for extended label types. A specific extended label type was selected by the 6 least significant bits of the first octet. Thus, extended label types were indicated by the values 64-127 (0b01xxxxxx) in the first octet of the label.
[RFC2671]拡張ラベルタイプの表示として使用するためにDNSラベルタイプ0b01を定義しました。特定の拡張ラベルタイプは、最初のオクテットの最下位6ビットによって選択されました。したがって、拡張ラベルタイプは、ラベルの最初のオクテットの値64〜127（0b01xxxxxx）で示されていました。
Extended label types are extremely difficult to deploy due to lack of support in clients and intermediate gateways, as described in [RFC3363], which moved [RFC2673] to Experimental status; and [RFC3364], which describes the pros and cons. As such, proposals that contemplate extended labels SHOULD weigh this deployment cost against the possibility of implementing functionality in other ways.
[RFC2673]を試験的ステータスに移行した[RFC3363]で説明されているように、拡張ラベルタイプはクライアントと中間ゲートウェイでのサポートがないため、展開が非常に困難です。と[RFC3364]は、長所と短所を説明します。したがって、拡張ラベルを検討する提案では、この展開コストを他の方法で機能を実装する可能性と比較検討する必要があります。
Finally, implementations MUST NOT generate or pass Binary Labels in their communications, as they are now deprecated.
最後に、実装は非推奨となったため、通信でバイナリラベルを生成または渡してはなりません（MUST NOT）。
An OPT pseudo-RR (sometimes called a meta-RR) MAY be added to the additional data section of a request.
OPT擬似RR（メタRRと呼ばれることもある）は、リクエストの追加データセクションに追加される場合があります。
The OPT RR has RR type 41.
OPT RRにはRRタイプ41があります。
If an OPT record is present in a received request, compliant responders MUST include an OPT record in their respective responses.
受信した要求にOPTレコードが存在する場合、対応レスポンダはそれぞれの応答にOPTレコードを含める必要があります。
An OPT record does not carry any DNS data. It is used only to contain control information pertaining to the question-and-answer sequence of a specific transaction. OPT RRs MUST NOT be cached, forwarded, or stored in or loaded from master files.
OPTレコードにはDNSデータは含まれていません。特定のトランザクションの質疑応答シーケンスに関連する制御情報を含めるためにのみ使用されます。 OPT RRをキャッシュしたり、転送したり、マスターファイルに保存したり、マスターファイルから読み込んだりしてはなりません。
The OPT RR MAY be placed anywhere within the additional data section. When an OPT RR is included within any DNS message, it MUST be the only OPT RR in that message. If a query message with more than one OPT RR is received, a FORMERR (RCODE=1) MUST be returned. The placement flexibility for the OPT RR does not override the need for the TSIG or SIG(0) RRs to be the last in the additional section whenever they are present.
OPT RRは、追加のデータセクション内のどこにでも配置できます。 OPT RRがDNSメッセージ内に含まれている場合、それはそのメッセージ内の唯一のOPT RRでなければなりません。複数のOPT RRを含むクエリメッセージを受信した場合は、FORMERR（RCODE = 1）を返す必要があります。 OPT RRの配置の柔軟性は、TSIGまたはSIG（0）RRが存在する場合は常に、それらが追加セクションの最後になる必要性をオーバーライドしません。
An OPT RR has a fixed part and a variable set of options expressed as {attribute, value} pairs. The fixed part holds some DNS metadata, and also a small collection of basic extension elements that we expect to be so popular that it would be a waste of wire space to encode them as {attribute, value} pairs.
OPT RRには、固定部分と、{属性、値}のペアで表されるオプションの可変セットがあります。固定部分には、いくつかのDNSメタデータと、非常に人気が高いと思われる基本的な拡張要素の小さなコレクションが含まれているため、それらを{属性、値}のペアとしてエンコードすると、ワイヤスペースが無駄になります。
The fixed part of an OPT RR is structured as follows:
OPT RRの固定部分は、次のように構成されています。
+------------+--------------+------------------------------+
| Field Name | Field Type | Description |
+------------+--------------+------------------------------+
| NAME | domain name | MUST be 0 (root domain) |
| TYPE | u_int16_t | OPT (41) |
| CLASS | u_int16_t | requestor's UDP payload size |
| TTL | u_int32_t | extended RCODE and flags |
| RDLEN | u_int16_t | length of all RDATA |
| RDATA | octet stream | {attribute,value} pairs |
+------------+--------------+------------------------------+
OPT RR Format
OPT RRフォーマット
The variable part of an OPT RR may contain zero or more options in the RDATA. Each option MUST be treated as a bit field. Each option is encoded as:
OPT RRの可変部分には、RDATAに0個以上のオプションを含めることができます。各オプションはビットフィールドとして扱われなければなりません。各オプションは次のようにエンコードされます。
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | OPTION-CODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | OPTION-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: | |
/ OPTION-DATA /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
OPTION-CODE Assigned by the Expert Review process as defined by the DNSEXT working group and the IESG.
OPTION-CODE DNSEXTワーキンググループとIESGによって定義されたように、エキスパートレビュープロセスによって割り当てられます。
OPTION-LENGTH Size (in octets) of OPTION-DATA.
OPTION-LENGTH OPTION-DATAのサイズ（オクテット単位）。
OPTION-DATA Varies per OPTION-CODE. MUST be treated as a bit field.
OPTION-DATA OPTION-CODEごとに異なります。ビットフィールドとして扱う必要があります。
The order of appearance of option tuples is not defined. If one option modifies the behaviour of another or multiple options are related to one another in some way, they have the same effect regardless of ordering in the RDATA wire encoding.
オプションのタプルの出現順序は定義されていません。 1つのオプションが別のオプションの動作を変更する場合、または複数のオプションが何らかの方法で相互に関連している場合、RDATAワイヤエンコーディングの順序に関係なく、同じ効果があります。
Any OPTION-CODE values not understood by a responder or requestor MUST be ignored. Specifications of such options might wish to include some kind of signaled acknowledgement. For example, an option specification might say that if a responder sees and supports option XYZ, it MUST include option XYZ in its response.
レスポンダまたはリクエスタが理解できないOPTION-CODE値は無視する必要があります。そのようなオプションの仕様は、ある種の合図された承認を含むことを望むかもしれません。たとえば、オプションの仕様では、レスポンダがオプションXYZを確認してサポートする場合、オプションXYZを応答に含める必要があると述べている場合があります。
The extended RCODE and flags, which OPT stores in the RR Time to Live (TTL) field, are structured as follows:
OPTがRR Time to Live（TTL）フィールドに格納する拡張RCODEとフラグは、次のように構成されています。
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | EXTENDED-RCODE | VERSION |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | DO| Z |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
EXTENDED-RCODE Forms the upper 8 bits of extended 12-bit RCODE (together with the 4 bits defined in [RFC1035]. Note that EXTENDED-RCODE value 0 indicates that an unextended RCODE is in use (values 0 through 15).
EXTENDED-RCODE拡張[12ビットRCODE]の上位8ビットを形成します（[RFC1035]で定義されている4ビットと共に）。EXTENDED-RCODE値0は、拡張されていないRCODEが使用されていることを示します（値0〜15）。
VERSION Indicates the implementation level of the setter. Full conformance with this specification is indicated by version '0'. Requestors are encouraged to set this to the lowest implemented level capable of expressing a transaction, to minimise the responder and network load of discovering the greatest common implementation level between requestor and responder. A requestor's version numbering strategy MAY ideally be a run-time configuration option. If a responder does not implement the VERSION level of the request, then it MUST respond with RCODE=BADVERS. All responses MUST be limited in format to the VERSION level of the request, but the VERSION of each response SHOULD be the highest implementation level of the responder. In this way, a requestor will learn the implementation level of a responder as a side effect of every response, including error responses and including RCODE=BADVERS.
VERSIONセッターの実装レベルを示します。この仕様への完全な準拠は、バージョン「0」で示されます。リクエスタは、これをトランザクションを表現できる最低の実装レベルに設定して、リクエスタとネットワークの負荷を最小限に抑え、リクエスタとレスポンダ間の最大の共通実装レベルを検出することをお勧めします。リクエスタのバージョン番号付け戦略は、実行時の構成オプションであることが理想的です。レスポンダがリクエストのVERSIONレベルを実装しない場合、RCODE = BADVERSで応答する必要があります。すべての応答の形式はリクエストのVERSIONレベルに制限する必要がありますが、各応答のVERSIONはレスポンダの最高の実装レベルである必要があります（SHOULD）。このようにして、リクエスターは、エラーレスポンスやRCODE = BADVERSを含むすべてのレスポンスの副作用として、レスポンダーの実装レベルを学習します。
DO DNSSEC OK bit as defined by [RFC3225].
[RFC3225]で定義されているDNSSEC OKビットを実行します。
Z Set to zero by senders and ignored by receivers, unless modified in a subsequent specification.
Z後続の仕様で変更されない限り、送信者によってゼロに設定され、受信者によって無視されます。
The OPT record MUST NOT be cached.
OPTレコードはキャッシュしてはなりません（MUST NOT）。
If a requestor detects that the remote end does not support EDNS(0), it MAY issue queries without an OPT record. It MAY cache this knowledge for a brief time in order to avoid fallback delays in the future. However, if DNSSEC or any future option using EDNS is required, no fallback should be performed, as these options are only signaled through EDNS. If an implementation detects that some servers for the zone support EDNS(0) while others would force the use of TCP to fetch all data, preference MAY be given to servers that support EDNS(0). Implementers SHOULD analyse this choice and the impact on both endpoints.
リクエスタがリモートエンドがEDNS（0）をサポートしていないことを検出した場合、OPTレコードなしでクエリを発行することができます（MAY）。将来のフォールバックの遅延を回避するために、この知識を短時間キャッシュする場合があります。ただし、DNSSECまたはEDNSを使用する将来のオプションが必要な場合、これらのオプションはEDNSを介してのみ通知されるため、フォールバックを実行する必要はありません。実装が、ゾーンの一部のサーバーがEDNS（0）をサポートし、他のサーバーがTCPの使用を強制してすべてのデータをフェッチすることを検出した場合、EDNS（0）をサポートするサーバーが優先される場合があります。実装者は、この選択と両方のエンドポイントへの影響を分析する必要があります（SHOULD）。
The requestor's UDP payload size (encoded in the RR CLASS field) is the number of octets of the largest UDP payload that can be reassembled and delivered in the requestor's network stack. Note that path MTU, with or without fragmentation, could be smaller than this.
リクエスターのUDPペイロードサイズ（RR CLASSフィールドにエンコードされています）は、リクエスターのネットワークスタックで再構成および配信できる最大のUDPペイロードのオクテット数です。パスMTUは、断片化の有無にかかわらず、これよりも小さいことに注意してください。
Values lower than 512 MUST be treated as equal to 512.
512未満の値は、512として扱われる必要があります。
The requestor SHOULD place a value in this field that it can actually receive. For example, if a requestor sits behind a firewall that will block fragmented IP packets, a requestor SHOULD NOT choose a value that will cause fragmentation. Doing so will prevent large responses from being received and can cause fallback to occur. This knowledge may be auto-detected by the implementation or provided by a human administrator.
リクエスタは、実際に受信できる値をこのフィールドに配置する必要があります（SHOULD）。たとえば、リクエスターが断片化されたIPパケットをブロックするファイアウォールの背後にある場合、リクエスターは断片化を引き起こす値を選択してはなりません（SHOULD NOT）。これを行うと、大きな応答を受信できなくなり、フォールバックが発生する可能性があります。この知識は、実装によって自動検出されるか、人間の管理者によって提供されます。
Note that a 512-octet UDP payload requires a 576-octet IP reassembly buffer. Choosing between 1280 and 1410 bytes for IP (v4 or v6) over Ethernet would be reasonable.
512オクテットのUDPペイロードには、576オクテットのIP再構成バッファーが必要です。イーサネット上のIP（v4またはv6）に1280〜1410バイトを選択するのが妥当です。
Where fragmentation is not a concern, use of bigger values SHOULD be considered by implementers. Implementations SHOULD use their largest configured or implemented values as a starting point in an EDNS transaction in the absence of previous knowledge about the destination server.
断片化が問題にならない場合、実装者はより大きな値の使用を検討する必要があります。実装では、宛先サーバーに関する事前の知識がない場合、EDNSトランザクションの開始点として、最大の構成または実装された値を使用する必要があります（SHOULD）。
Choosing a very large value will guarantee fragmentation at the IP layer, and may prevent answers from being received due to loss of a single fragment or to misconfigured firewalls.
非常に大きな値を選択すると、IPレイヤーでのフラグメンテーションが保証され、単一のフラグメントの損失やファイアウォールの設定ミスにより、応答が受信されない可能性があります。
The requestor's maximum payload size can change over time. It MUST NOT be cached for use beyond the transaction in which it is advertised.
リクエスタの最大ペイロードサイズは、時間とともに変化する可能性があります。アドバタイズされるトランザクションを超えて使用するためにキャッシュしないでください。
The responder's maximum payload size can change over time but can reasonably be expected to remain constant between two closely spaced sequential transactions, for example, an arbitrary QUERY used as a probe to discover a responder's maximum UDP payload size, followed immediately by an UPDATE that takes advantage of this size. This is considered preferable to the outright use of TCP for oversized requests, if there is any reason to suspect that the responder implements EDNS, and if a request will not fit in the default 512-byte payload size limit.
レスポンダの最大ペイロードサイズは時間の経過とともに変化する可能性がありますが、2つの近接する連続トランザクション間で一定のままであることが合理的に期待できます。たとえば、レスポンダの最大UDPペイロードサイズを検出するためのプローブとして使用される任意のQUERYの直後に、このサイズの利点。これは、レスポンダがEDNSを実装していると疑う理由があり、リクエストがデフォルトの512バイトのペイロードサイズ制限に収まらない場合、特大のリクエストに対してTCPを完全に使用するよりも望ましいと考えられています。
Due to transaction overhead, it is not recommended to advertise an architectural limit as a maximum UDP payload size. Even on system stacks capable of reassembling 64 KB datagrams, memory usage at low levels in the system will be a concern. A good compromise may be the use of an EDNS maximum payload size of 4096 octets as a starting point.
トランザクションのオーバーヘッドのため、アーキテクチャの制限を最大UDPペイロードサイズとしてアドバタイズすることはお勧めしません。 64 KBのデータグラムを再構成できるシステムスタックでも、システムの低レベルでのメモリ使用量が問題になります。開始点として、4096オクテットのEDNS最大ペイロードサイズを使用することは、適切な妥協案かもしれません。
A requestor MAY choose to implement a fallback to smaller advertised sizes to work around firewall or other network limitations. A requestor SHOULD choose to use a fallback mechanism that begins with a large size, such as 4096. If that fails, a fallback around the range of 1280-1410 bytes SHOULD be tried, as it has a reasonable chance to fit within a single Ethernet frame. Failing that, a requestor MAY choose a 512-byte packet, which with large answers may cause a TCP retry.
リクエスタは、ファイアウォールまたはその他のネットワーク制限を回避するために、より小さなアドバタイズサイズへのフォールバックを実装することを選択できます。リクエスタは、4096などの大きなサイズで始まるフォールバックメカニズムを使用することを選択する必要があります（SHOULD）。これが失敗した場合、単一のイーサネット内に収まる可能性があるため、1280-1410バイトの範囲のフォールバックを試行する必要があります。フレーム。これに失敗すると、リクエスターは512バイトのパケットを選択できます（MAY）。これにより、大きな応答があると、TCP再試行が発生する可能性があります。
Values of less than 512 bytes MUST be treated as equal to 512 bytes.
512バイト未満の値は、512バイトに等しいものとして扱われる必要があります。
In a network that carries DNS traffic, there could be active equipment other than that participating directly in the DNS resolution process (stub and caching resolvers, authoritative servers) that affects the transmission of DNS messages (e.g., firewalls, load balancers, proxies, etc.), referred to here as "middleboxes".
DNSトラフィックを運ぶネットワークでは、DNSメッセージの送信に影響を与えるDNS解決プロセス（スタブおよびキャッシングリゾルバー、権限のあるサーバー）に直接関与するもの以外のアクティブな機器（ファイアウォール、ロードバランサー、プロキシなど）が存在する可能性があります。 。）、ここでは「ミドルボックス」と呼びます。
Conformant middleboxes MUST NOT limit DNS messages over UDP to 512 bytes.
適合ミドルボックスは、UDP上のDNSメッセージを512バイトに制限してはなりません（MUST NOT）。
Middleboxes that simply forward requests to a recursive resolver MUST NOT modify and MUST NOT delete the OPT record contents in either direction.
リクエストを再帰リゾルバに単純に転送するミドルボックスは、どちらの方向でもOPTレコードの内容を変更および削除してはなりません（MUST NOT）。
Middleboxes that have additional functionality, such as answering queries or acting as intelligent forwarders, SHOULD be able to process the OPT record and act based on its contents. These middleboxes MUST consider the incoming request and any outgoing requests as separate transactions if the characteristics of the messages are different.
クエリへの応答やインテリジェントフォワーダーとしての機能などの追加機能を備えたミドルボックスは、OPTレコードを処理し、その内容に基づいて動作できる必要があります（SHOULD）。これらのミドルボックスは、メッセージの特性が異なる場合、着信要求と発信要求を別々のトランザクションと見なす必要があります。
A more in-depth discussion of this type of equipment and other considerations regarding their interaction with DNS traffic is found in [RFC5625].
このタイプの機器の詳細と、DNSトラフィックとの相互作用に関するその他の考慮事項は、[RFC5625]に記載されています。
The presence of an OPT pseudo-RR in a request should be taken as an indication that the requestor fully implements the given version of EDNS and can correctly understand any response that conforms to that feature's specification.
要求内のOPT疑似RRの存在は、要求者がEDNSの特定のバージョンを完全に実装し、その機能の仕様に準拠するすべての応答を正しく理解できることを示すものと見なされます。
Lack of presence of an OPT record in a request MUST be taken as an indication that the requestor does not implement any part of this specification and that the responder MUST NOT include an OPT record in its response.
リクエストにOPTレコードが存在しないことは、リクエスタがこの仕様のどの部分も実装していないこと、およびレスポンダがその応答にOPTレコードを含めてはならないことを示していると見なす必要があります。
Extended agents MUST be prepared for handling interactions with unextended clients in the face of new protocol elements and fall back gracefully to unextended DNS when needed.
拡張エージェントは、新しいプロトコル要素に直面して拡張されていないクライアントとの対話を処理する準備ができており、必要に応じて拡張されていないDNSに適切にフォールバックする必要があります。
Responders that choose not to implement the protocol extensions defined in this document MUST respond with a return code (RCODE) of FORMERR to messages containing an OPT record in the additional section and MUST NOT include an OPT record in the response.
このドキュメントで定義されているプロトコル拡張を実装しないことを選択したレスポンダは、追加セクションにOPTレコードを含むメッセージにFORMERRのリターンコード（RCODE）で応答する必要があり、応答にOPTレコードを含めてはなりません。
If there is a problem with processing the OPT record itself, such as an option value that is badly formatted or that includes out-of-range values, a FORMERR MUST be returned. If this occurs, the response MUST include an OPT record. This is intended to allow the requestor to distinguish between servers that do not implement EDNS and format errors within EDNS.
フォーマットが正しくない、または範囲外の値が含まれているオプション値など、OPTレコード自体の処理に問題がある場合は、FORMERRを返す必要があります。これが発生した場合、応答にはOPTレコードを含める必要があります。これは、リクエスターがEDNSを実装していないサーバーとEDNS内のフォーマットエラーを区別できるようにすることを目的としています。
The minimal response MUST be the DNS header, question section, and an OPT record. This MUST also occur when a truncated response (using the DNS header's TC bit) is returned.
最小限の応答は、DNSヘッダー、質問セクション、およびOPTレコードである必要があります。これは、（DNSヘッダーのTCビットを使用して）切り捨てられた応答が返されたときにも発生する必要があります。
Requestor-side specification of the maximum buffer size may open a DNS denial-of-service attack if responders can be made to send messages that are too large for intermediate gateways to forward, thus leading to potential ICMP storms between gateways and responders.
中間ゲートウェイが転送するには大きすぎるメッセージをレスポンダが送信するようにできる場合、リクエスタ側の最大バッファサイズを指定すると、DNSサービス拒否攻撃が開始される可能性があり、ゲートウェイとレスポンダの間でICMPストームが発生する可能性があります。
Announcing very large UDP buffer sizes may result in dropping of DNS messages by middleboxes (see Section 6.2.6). This could cause retransmissions with no hope of success. Some devices have been found to reject fragmented UDP packets.
非常に大きなUDPバッファサイズをアナウンスすると、ミドルボックスによってDNSメッセージがドロップされる可能性があります（セクション6.2.6を参照）。これにより、再送信が成功する可能性がない可能性があります。一部のデバイスは、断片化されたUDPパケットを拒否することが判明しています。
Announcing UDP buffer sizes that are too small may result in fallback to TCP with a corresponding load impact on DNS servers. This is especially important with DNSSEC, where answers are much larger.
小さすぎるUDPバッファーサイズをアナウンスすると、対応する負荷がDNSサーバーに影響して、TCPにフォールバックする可能性があります。これは、回答がはるかに大きいDNSSECで特に重要です。
The IANA has assigned RR type code 41 for OPT.
IANAはOPTにRRタイプコード41を割り当てました。
[RFC2671] specified a number of IANA subregistries within "DOMAIN NAME SYSTEM PARAMETERS":
[RFC2671]は、「ドメイン名システムパラメータ」内にいくつかのIANAサブレジストリを指定しました：
o DNS EDNS(0) Options
o Duns Addons（0）オプション
o EDNS Version Number
o バージョン番号を追加
o EDNS Header Flags
o EDNSヘッダーフラグ
Additionally, two entries were generated in existing registries:
さらに、既存のレジストリに2つのエントリが生成されました。
o EDNS Extended Label Type in the DNS Label Types registry
o DNSラベルタイプレジストリのEDNS拡張ラベルタイプ
o Bad OPT Version in the DNS RCODES registry
o DNS RCODESレジストリの不適切なOPTバージョン
IANA has updated references to [RFC2671] in these entries and subregistries to this document.
IANAは、このドキュメントのこれらのエントリとサブレジストリで[RFC2671]への参照を更新しました。
[RFC2671] created the DNS Label Types registry. This registry is to remain open.
[RFC2671]はDNSラベルタイプレジストリを作成しました。このレジストリは開いたままにします。
The registration procedure for the DNS Label Types registry is Standards Action.
DNSラベルタイプレジストリの登録手順は、標準アクションです。
This document assigns option code 65535 in the DNS EDNS0 Options registry to "Reserved for future expansion".
このドキュメントでは、DNS EDNS0オプションレジストリのオプションコード65535を「将来の拡張のために予約」に割り当てています。
The current status of the IANA registry for EDNS Option Codes at the time of publication of this document is
このドキュメントの公開時点におけるEDNSオプションコードのIANAレジストリの現在のステータスは、
o 0-4 assigned, per references in the registry
o レジストリの参照ごとに0〜4が割り当てられます
o 5-65000 Available for assignment, unassigned
o 5-65000割り当て可能、未割り当て
o 65001-65534 Local/Experimental use
o 65001-65534ローカル/実験的使用
o 65535 Reserved for future expansion
o 65535将来の拡張のために予約済み
[RFC2671] expands the RCODE space from 4 bits to 12 bits. This allows more than the 16 distinct RCODE values allowed in [RFC1035]. IETF Review is required to add a new RCODE.
[RFC2671]は、RCODEスペースを4ビットから12ビットに拡張します。これにより、[RFC1035]で許可されている16を超える個別のRCODE値が許可されます。新しいRCODEを追加するには、IETFレビューが必要です。
This document assigns EDNS Extended RCODE 16 to "BADVERS" in the DNS RCODES registry.
このドキュメントでは、DNS RCODESレジストリの「BADVERS」にEDNS拡張RCODE 16を割り当てています。
[RFC2671] called for the recording of assignment of extended label types 0bxx111111 as "Reserved for future extended label types"; the IANA registry currently contains "Reserved for future expansion". This request implied, at that time, a request to open a new registry for extended label types, but due to the possibility of ambiguity, new text registrations were instead made within the general DNS Label Types registry, which also registers entries originally defined by [RFC1035]. There is therefore no Extended Label Types registry, with all label types registered in the DNS Label Types registry.
[RFC2671]拡張ラベルタイプ0bxx111111の割り当てを「将来の拡張ラベルタイプ用に予約」として記録することを要求しました。 IANAレジストリには現在、「将来の拡張のために予約済み」が含まれています。このリクエストは、当時、拡張ラベルタイプの新しいレジストリを開くリクエストを意味していましたが、あいまいさの可能性があるため、代わりに新しいテキストレジストレーションが一般的なDNSラベルタイプレジストリ内で作成されました。 RFC1035]。したがって、拡張ラベルタイプレジストリはなく、すべてのラベルタイプがDNSラベルタイプレジストリに登録されています。
This document deprecates Binary Labels. Therefore, the status for the DNS Label Types registration "Binary Labels" is now "Historic".
このドキュメントでは、バイナリラベルは廃止されます。したがって、DNSラベルタイプの登録「バイナリラベル」のステータスは「履歴」になります。
IETF Standards Action is required for assignments of new EDNS(0) flags. Flags SHOULD be used only when necessary for DNS resolution to function. For many uses, an EDNS Option Code may be preferred.
新しいEDNS（0）フラグの割り当てには、IETF標準アクションが必要です。フラグは、DNS解決が機能するために必要な場合にのみ使用してください。多くの用途で、EDNSオプションコードが推奨されます。
IETF Standards Action is required to create new entries in the EDNS Version Number registry. Within the EDNS Option Code space, Expert Review is required for allocation of an EDNS Option Code. Per this document, IANA maintains a registry for the EDNS Option Code space.
EDNSバージョン番号レジストリに新しいエントリを作成するには、IETF標準アクションが必要です。 EDNSオプションコードスペース内で、EDNSオプションコードの割り当てにはエキスパートレビューが必要です。このドキュメントによれば、IANAはEDNSオプションコードスペースのレジストリを維持しています。
OPT Option Codes are assigned by Expert Review.
OPTオプションコードはエキスパートレビューによって割り当てられます。
Assignment of Option Codes should be liberal, but duplicate functionality is to be avoided.
オプションコードの割り当ては自由であるべきですが、機能の重複は避けてください。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", 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月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671] Vixie、P。、「DNSの拡張メカニズム（EDNS0）」、RFC 2671、1999年8月。
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001.
[RFC3225]コンラッド、D。、「DNSSECのリゾルバーサポートを示す」、RFC 3225、2001年12月。
[RFC2673] Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, August 1999.
[RFC2673]クロフォード、M。、「ドメインネームシステムのバイナリラベル」、RFC 2673、1999年8月。
[RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)", RFC 3363, August 2002.
[RFC3363] Bush、R.、Durand、A.、Fink、B.、Gudmundsson、O。、およびT. Hain、「インターネットプロトコルバージョン6（IPv6）アドレスをドメインネームシステム（DNS）で表す」、RFC 3363 、2002年8月。
[RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)", RFC 3364, August 2002.
[RFC3364] Austein、R。、「インターネットプロトコルバージョン6（IPv6）のドメインネームシステム（DNS）サポートにおけるトレードオフ」、RFC 3364、2002年8月。
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, August 2009.
[RFC5625] Bellis、R。、「DNSプロキシ実装ガイドライン」、BCP 152、RFC 5625、2009年8月。
Following is a list of high-level changes to RFCs 2671 and 2673.
以下は、RFC 2671および2673の高レベルの変更のリストです。
o Support for the OPT record is now mandatory.
o OPTレコードのサポートが必須になりました。
o Extended label types remain available, but their use is discouraged as a general solution due to observed difficulties in their deployment on the Internet, as illustrated by the work with the "Binary Labels" type.
o 拡張ラベルタイプは引き続き使用できますが、「バイナリラベル」タイプの使用で示されているように、インターネット上での展開に問題が見られるため、それらの使用は一般的なソリューションとしては推奨されません。
o RFC 2673, which defined the "Binary Labels" type and is currently Experimental, is requested to be moved to Historic.
o 「Binary Labels」タイプを定義し、現在実験的であるRFC 2673は、Historicに移動するように要求されています。
o Made changes in how EDNS buffer sizes are selected, and provided recommendations on how to select them.
o EDNSバッファーサイズの選択方法を変更し、それらの選択方法に関する推奨事項を提供しました。
Authors' Addresses
著者のアドレス
Joao Damas Bond Internet Systems Av Albufera 14 S.S. Reyes, Madrid 28701 ES
Joao Damas Bond Internet Systems Av Albufera 14 S.S.レイエス、マドリード28701 ES
Phone: +1 650.423.1312
EMail: joao@bondis.org
Michael Graff
マイケル・グラフ
EMail: explorer@flame.org
Paul Vixie Internet Systems Consortium 950 Charter Street Redwood City, California 94063 US
Paul Vixie Internet Systems Consortium 950 Charter Street Redwood City、California 94063 US
Phone: +1 650.423.1301
EMail: vixie@isc.org