Internet Engineering Task Force (IETF) J. Damas RFC: 6891 Bond Internet Systems STD: 75 M. Graff 廃止(Obsoletes): 2671, 2673 分類: 標準化過程(Standards Track) P. Vixie ISSN: 2070-1721 Internet Systems Consortium 2013年4月 DNSの拡張方式(EDNS(0)) 要旨 DNS(Domain Name System)のワイヤープロトコルは、多数の固定フィールドを 含む。これらの領域は既に使い切られたか、間もなく使い切られてしまう ため、リクエスターが自身の機能をレスポンダーに通知することができなく なる。本文書は、プロトコル拡張を可能とする、後方互換性を持つ仕組みを 記述する。 本文書は、幾つかの実装の普及経験から得られたフィードバックに基づいて、 EDNS(0)(Extension Mechanisms for DNS)の仕様を更新(し、RFC 2671を廃止) する。また、本文書はRFC 2673("DNSにおけるバイナリーラベル")も廃止し、 DNSにおける拡張ラベルの仕様に関する考慮点を追加する。 Status of This Memo This is an Internet Standards Track document. 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. 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. Damas, et al. Standards Track [Page 1] RFC 6891 EDNS(0) Extensions April 2013 Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. 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. 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. Damas, et al. Standards Track [Page 2] RFC 6891 EDNS(0) Extensions April 2013 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. 用語 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. EDNSサポートの要件 . . . . . . . . . . . . . . . . . . . . . . 5 4. DNSメッセージの変更 . . . . . . . . . . . . . . . . . . . . . 5 4.1. メッセージヘッダー . . . . . . . . . . . . . . . . . . . . 5 4.2. ラベルタイプ . . . . . . . . . . . . . . . . . . . . . . . 5 4.3. UDPメッセージサイズ . . . . . . . . . . . . . . . . . . . 6 5. 拡張ラベルタイプ . . . . . . . . . . . . . . . . . . . . . . . 6 6. OPT疑似RR . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. OPTレコードの定義 . . . . . . . . . . . . . . . . . . . . 6 6.1.1. 基本要素 . . . . . . . . . . . . . . . . . . . . . . . 6 6.1.2. ワイヤーフォーマット . . . . . . . . . . . . . . . . . 7 6.1.3. OPTレコードのTTLフィールドの使用 . . . . . . . . . . . 9 6.1.4. フラグ . . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. 振る舞い . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.2.1. キャッシュの振る舞い . . . . . . . . . . . . . . . . . 10 6.2.2. フォールバック . . . . . . . . . . . . . . . . . . . . 10 6.2.3. リクエスターのペイロードサイズ . . . . . . . . . . . . 10 6.2.4. レスポンダーのペイロードサイズ . . . . . . . . . . . . 11 6.2.5. ペイロードサイズの選択 . . . . . . . . . . . . . . . . 11 6.2.6. 中間機器のサポート . . . . . . . . . . . . . . . . . . 11 7. トランスポートに関する考慮点 . . . . . . . . . . . . . . . . . 12 8. セキュリティに関する考慮点 . . . . . . . . . . . . . . . . . . 13 9. IANAに関する考慮点 . . . . . . . . . . . . . . . . . . . . . . 13 9.1. DNS EDNS0 Option Code への変更 . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 Appendix A. Changes since RFCs 2671 and 2673 . . . . . . . . . . 16 Damas, et al. Standards Track [Page 3] RFC 6891 EDNS(0) Extensions April 2013 1. はじめに DNS[RFC1035]は、メッセージフォーマット、メッセージ内におけるエンコーディング オプション、エラー、名前圧縮の標準フォーマットを規定している。本文書記載の 拡張方式を使用しない場合、UDPでやりとりされるDNSメッセージの最大許容 サイズは512バイトである。UDP上における最大メッセージサイズといったDNSの プロトコル上の制限は、DNSで伝達可能な付加的情報(例えば複数個のIPv6アドレスや DNSSECの署名等)を効率良くサポートするには小さすぎる。最後に、RFC 1035は、 実装が互いにやりとりを行うどのような相手に対しても、自身が保持する機能を 広報する仕組みを何も定義していない。 [RFC2671]はDNSに拡張方式を追加した。これらの拡張方式は広範囲にサポート されている。多数の新しいDNS実装はこれを使用しており、プロトコル拡張は この拡張方式の存在に依存している。本文書は[RFC2671]を洗練し、同時に廃止 する。 EDNS非対応(unextended)エージェントは、[RFC2671]で定義されここで 再記述されるプロトコル拡張をどのように解釈するかを知らないだろう。 EDNS対応エージェントは、新しいプロトコル要素に直面した際に、EDNS非対応 エージェントとの相互運用に対処しEDNS非対応DNSに円滑にフォールバック できるよう準備がなされている必要がある。 EDNSはDNSに対するホップバイホップな拡張である。これはDNSの名前解決 処理において、ホストの各ペア間、例えばスタブリゾルバーと再帰リゾルバー、 あるいは再帰リゾルバーと権威サーバーの間でEDNSの使用がネゴシエート されるという意味である。 [RFC2671]は拡張ラベルタイプを規定している。このようなラベルは、[RFC2671]に おける"ビットストリングラベル"または"バイナリーラベル"と呼ばれるラベル タイプの提案だけであり、最後の語(バイナリーラベル)が通常使用されている。 さまざまな理由により、新しいラベルタイプの導入は極めて困難であることが わかっており、[RFC2673]は実験的(Experimental)に移された。本文書は [RFC2673]を廃止し、バイナリーラベルを廃止見込み(deprecate)とする。 拡張ラベルの定義は維持されるが、普及の現実的な困難さのため、その使用は 推奨されない。将来における使用についても、普及の障害を慎重に評価した後 にだけ考慮されるべき(SHOULD)である。 2. 用語 "リクエスター"は、リクエストを送信する側を指す。"レスポンダー"は、 権威サーバー、再帰リゾルバー、または問い合わせに応答する他のDNS構成 要素を指す。ここで使用される他の用語は、本文書内で引用されるRFCの 中で定義されている。 Damas, et al. Standards Track [Page 4] RFC 6891 EDNS(0) Extensions April 2013 本文書におけるキーワード"しなければならない(MUST)"、"してはならない (MUST NOT)"、"要求される(REQUIRED)"、"するものとする(SHALL)"、 "しないものとする(SHALL NOT)"、"すべきである(SHOULD)"、 "すべきでない(SHOULD NOT)"、"推奨される(RECOMMENDED)"、 "してもよい/することができる(MAY)"、"任意である(OPTIONAL)"等は、 RFC 2119[RFC2119]の記述どおりに解釈されるものとする。 3. EDNSサポートの要件 EDNSはDNSのスケーラビリティを改善する仕組みを提供する。その使用に より、インターネット上で選択できる選択肢が増えるからである。 これは、DNSメッセージ用にUDPトランスポートを使用する際に、RFC 1035で 規定された上限を超えるサイズを扱えるようにする事に加えて、付加的な フラグとリターンコード(RCODE)用の追加のデータ領域を提供することで 実現される。しかし実装の経験は、新しいRCODEの追加は避けるべきことを 示している。稼働中の既存の実装をアップグレードさせることは困難だから である。フラグは、DNS名前解決がその機能を果たすために必要である場合に だけ使用されるべき(SHOULD)である。 多くの用途では、EDNSオプションコードを使用する方が望ましいだろう。 多年にわたり、幾つかのDNSアプリケーションはEDNSをその普及の要件に してきた。例えばDNSSECはDNS応答にDNSSECを含めるリクエストを通知する ために、EDNSで導入された付加的なフラグ領域を使用する。 従来より大きいデータ要素、例えばAAAAレコード、DNSSEC情報(例えばRRSIGや DNSKEY)、大きいTXTレコードをDNS応答に含めると、DNS応答サイズが増大する。 そのような状況において、EDNSによって提供される付加的なUDPペイロード 機能は、DNSのスケーラビリティ改善を補助することができる。同機能により DNSトランスポートとしてTCPが広範に使用されるのを回避できるからである。 4. DNSメッセージの変更 4.1. メッセージヘッダー DNSメッセージヘッダーの2番目の16ビットワードは、4ビットのOPCODE、 4ビットのRCODE、多数の1ビットフラグに分割されている([RFC1035]の セクション4.1.1参照)。これらのフラグ値の幾つかは将来の利用向けと 明示されたが、その大部分はその後フラグの割り当てがなされた。また、 RCODE値の大部分も現在使用中である。以下で規定するOPT疑似RR(pseudo-RR)は、 RCODEビットフィールドの拡張に加えて追加のフラグビットを含む。 4.2. ラベルタイプ ワイヤーフォーマットのドメインラベルの最初の2ビットは、ラベルのタイプを 示すために使用されている。[RFC1035]は四つの可能なタイプのうち二つに割り当て を行い、残り二つを将来のために予約した。[RFC2671]で、ラベルタイプが更に 定義された。[RFC2671]で定義された拡張ラベルタイプを識別するための 2ビットの組み合わせの使用は依然として有効である。 Damas, et al. Standards Track [Page 5] RFC 6891 EDNS(0) Extensions April 2013 しかし、新しいラベルタイプの普及は著しく困難であることがわかっているため、 他の選択肢や普及の必要性を慎重に評価した後にだけそれを実行することが 推奨される。 4.3. UDPメッセージサイズ 従来のDNSメッセージは、UDP上で送信される場合そのサイズは512オクテット に制限される[RFC1035]。DNSで転送される可能性のあるデータ量はますます 増加しており、それを512バイトの制限に適合させることはより難しくなりつつ ある。例えばDNSSECレコードを含める場合、512バイトのメッセージが保持 できるよりもはるかに大きい応答を要求することが頻繁に生じる。 EDNS(0)は従来より大きい応答サイズを受理できる機能といった付加的な特性 を広報する方法を規定している。これはUDP応答が切り詰め(truncate)られ、 その結果発生するTCP上のリトライを回避する一助となることを意図している。 つまり、EDNS(0)はトランスポートにTCPを用いる必要なく、大きなパケット サイズの転送のサポートを提供する。 5. 拡張ラベルタイプ ワイヤー上のDNSラベル表現において、第1オクテットはラベルタイプを指定 する。基本DNS仕様[RFC1035]は第1オクテットの上位2ビットをこの目的の ために割り当てた。 [RFC2671]はDNSラベルタイプ0b01を拡張ラベルタイプ提示用として定義した。 固有の拡張ラベルタイプは第1オクテットの下位6ビットで選択される。 従って拡張ラベルタイプはラベルの第1オクテット値64-127(0b01xxxxxx) によって提示される。 [RFC3363]に記述されるように、拡張ラベルタイプの普及は、クライアントと 中間機器のサポートを欠くことから極めて困難である。このため[RFC2673]は 実験的(Experimental)に移行した。従って拡張ラベルを検討する提案に 際しては、この普及コストと他の方法で同じ機能を実装する可能性とを 比較検討すべき(SHOULD)である。 最後に、実装者は通信においてバイナリーラベルを生成したり通過させたり してはならない(MUST NOT)。バイナリーラベルは現在廃止見込みだからである。 6. OPT疑似RR 6.1. OPTレコードの定義 6.1.1. 基本要素 OPT疑似RR(メタRRと呼ばれることもある)は、リクエストの付加情報部に 追加することができる(MAY)。 Damas, et al. Standards Track [Page 6] RFC 6891 EDNS(0) Extensions April 2013 OPT RRはRRタイプ41を持つ。 受信したリクエスト内にOPTレコードが存在する場合、OPT対応レスポンダーは 個々の応答内にOPTレコードを含めなければならない(MUST)。 OPTレコードはDNSデータを何も配送しない。特定のトランザクションの 問い合わせ・回答の連鎖に関連した制御情報を保持するだけである。 OPT RRは、キャッシュ、転送、マスターファイルへの保存、マスター ファイルへのロードがされてはならない(MUST NOT)。 OPT RRは付加情報部内であればどこに置かれていてもよい(MAY)。 OPT RRがDNSメッセージに含まれる場合、そのメッセージ内にはOPT RRだけ しか存在してはならない(MUST)。二つ以上のOPT RRを持つ問い合わせメッセージ が受信された場合、FORMERR(RCODE=1)が返されなければならない(MUST)。 OPT RR配置の柔軟性は、TSIGまたはSIG(0) RRが存在する場合に付加情報部の 最後でなければならないという要求に優先するものではない。 6.1.2. ワイヤーフォーマット OPT RRは、固定部分と、{属性, 値}のペアで表現される可変個数のオプションの 集まりを持つ。固定部分は、幾つかのDNSメタデータと、{属性, 値}のペアと してエンコードするのはワイヤー空間の無駄になるくらいに普及していると 思われる、基本拡張要素の少量のまとまりを保持する。 OPT RRの固定部分は、以下のように構造化される。 +------------+--------------+------------------------------+ | フィールド名 | フィールドタイプ | 説明 | +------------+--------------+------------------------------+ | NAME | ドメイン名 | 0必須(MUST)(ルートドメイン) | | TYPE | u_int16_t | OPT (41) | | CLASS | u_int16_t | リクエスターのUDPペイロードサイズ | | TTL | u_int32_t | 拡張RCODEとフラグ | | RDLEN | u_int16_t | 全RDATA長 | | RDATA | オクテットストリーム | {属性, 値}のペア | +------------+--------------+------------------------------+ OPT RRのフォーマット Damas, et al. Standards Track [Page 7] RFC 6891 EDNS(0) Extensions April 2013 OPT RRの可変部分はゼロ個以上のオプションをRDATAに含んでよい。 各オプションはビットフィールドとして処理されなければならない(MUST)。 各オプションは以下のようにエンコードされる。 +0 (上位ビット) +1 (下位ビット) +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0: | オプションコード | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2: | オプション長 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 4: | | / オプションデータ / / / +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ オプションコード DNSTXTワーキンググループ及びIESGによって定義されたように、 エキスパートレビューによって割り当てられる。 オプション長 オプションデータの(オクテット単位の)サイズ オプションデータ オプションコードごとに異なる。ビットフィールドとして処理されなければ ならない(MUST)。 オプションのペアが現れる順番は定義されない。あるオプションが他の オプションの振る舞いを変更する場合、または複数のオプションが何らかの 形でお互いに影響し合う関係にある場合、RDATAワイヤーエンコーディングの 順番にかかわらず同じ結果となる。 レスポンダーまたはリクエスターに理解されないオプションコード値は どれも無視されなければならない(MUST)。そのようなオプションの仕様が ある種の確認応答通知を含めることを希望する可能性がある。例えば あるオプション仕様は、レスポンダーがオプションXYZをサポートし 同オプションを検知した場合、応答にオプションXYZを含めなければならない (MUST)と規定するかもしれない。 Damas, et al. Standards Track [Page 8] RFC 6891 EDNS(0) Extensions April 2013 6.1.3. OPTレコードのTTLフィールドの使用 OPTがRRのTTL(Time to Live)フィールドに保存する拡張RCODEとフラグは 以下のように構造化される。 +0 (上位ビット) +1 (下位ビット) +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0: | 拡張RCODE | バージョン | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2: | DO| Z | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 拡張RCODE ([RFC1035]定義の4ビットとあわせて)12ビットに拡張されたRCODEの 上位8ビットを構成する。拡張RCODE値0は非拡張RCODEが使用されて いる(値は0から15)ことを示すことに注意。 バージョン 値を設定した実装の実装レベルを示す。本仕様に完全準拠の場合、 バージョン'0'が提示される。リクエスター・レスポンダー間で共通な 最上の実装レベルを発見するために生じるレスポンダー及びネット ワークの負荷を最小化するために、リクエスターは、このフィールドの 値をトランザクションを伝達するために必要な最低限のレベルに設定する ことが推奨される。リクエスターのバージョン選定戦略は、理想的には 実行時設定オプションにしてもよい(MAY)。 レスポンダーがリクエストのバージョンレベルを実装していない場合、 RCODE=BADVERSを設定して応答しなければならない(MUST)。すべての応答は リクエストのバージョンレベルのフォーマットに制限されなければならない (MUST)が、各応答のバージョン値は、レスポンダーが設定し得る最大の 実装レベルに設定されるべき(SHOULD)である。このようにすることで、 リクエスターはレスポンダーの実装レベルを(エラー応答やRCODE=BADVERSの 応答も含めて)各応答から副次的に学習するようになる。 6.1.4. フラグ DO [RFC3225]で定義されたDNSSEC OKビット。 Z 後続の仕様で変更されない限り、送信者によってゼロに設定され、受信者 には無視される。 Damas, et al. Standards Track [Page 9] RFC 6891 EDNS(0) Extensions April 2013 6.2. 振る舞い 6.2.1. キャッシュの振る舞い OPTレコードはキャッシュされてはならない(MUST NOT)。 6.2.2. フォールバック 対向側がEDNS(0)をサポートしないとリクエスターが検知した場合、リクエスター はOPTレコード無しで問い合わせを発行してもよい(MAY)。リクエスターは将来に おけるフォールバックの遅延を回避するために、この知識を短期間キャッシュ してもよい(MAY)。しかしDNSSECやEDNSを使用する未来のオプションが要求 される場合はフォールバックを実行すべきではない。これらのオプションは EDNSを通してしか通知されないからである。あるゾーンについて、幾つかの サーバーはEDNS(0)をサポートするが他のものは全データ取得のためにTCPの 使用を強制することを実装が検知した場合、EDNS(0)をサポートするサーバーを 優先してもよい(MAY)。実装者は、この選択と両エンドポイントへの影響を分析 すべきである(SHOULD)。 6.2.3. リクエスターのペイロードサイズ (RRのCLASSフィールドにエンコードされた)リクエスターのUDPペイロード サイズは、リクエスターのネットワークスタックで再構成・送信可能な 最大UDPペイロードサイズのオクテット数である。フラグメンテーションの 有無にかかわらず、パスMTUはこの値より小さいかもしれないことに注意せよ。 512より小さい値は、512に等しいものとして処理されなければならない(MUST)。 リクエスターは、実際に受信可能な値をこのフィールドに設定すべきである (SHOULD)。例えばリクエスターが断片化されたIPパケットをブロックする ファイアウォールの背後に位置する場合、リクエスターはフラグメンテーションを 生じさせる値を選択すべきではない(SHOULD NOT)。それをしてしまうと サイズの大きい応答の受信が阻害されるので、フォールバックを生じさせる 可能性がある。この知識は実装によって自動で検出されるか、人間の管理者に よって提供されることになるだろう。 512オクテットのUDPペイロードは576オクテットのIP再構成バッファーを 必要とすることに注意せよ。IP(v4またはv6)をイーサーネットで配送するので あれば、1280から1410バイトの間の値を選択するのが妥当である。 フラグメンテーションが懸念事項でない状況では、実装者はより大きな値の 使用を検討すべき(SHOULD)である。送信先サーバーに関する予備知識がない 場合、実装はEDNSトランザクションの出発点として、設定または実装された 最大値を使用すべき(SHOULD)である。 Damas, et al. Standards Track [Page 10] RFC 6891 EDNS(0) Extensions April 2013 極端に大きい値を選択するとIPレイヤーでフラグメンテーションが確実に 発生するので、単一のフラグメント消失や誤った設定のファイアウォールに よって回答の受信が阻害されるかもしれない。 リクエスターの最大ペイロードサイズは時間と共に変化してもよい。広報 されたトランザクション外の使用のために、この値がキャッシュされては ならない(MUST NOT)。 6.2.4. レスポンダーのペイロードサイズ レスポンダーの最大ペイロードサイズは時間と共に変化するかもしれないが、 二つの密接した連続トランザクションの合間は、一定のまま維持されると 妥当に期待できる。例えば、レスポンダーの最大UDPペイロードサイズを発見する ために任意の問い合わせをプローブとして使用し、その直後にプローブで 得たサイズを利用した更新を続けられると期待できる。レスポンダーが EDNSを実装していると推察する何らかの理由があり、リクエストが512バイトの ペイロードサイズ制限に適さない場合、512バイトを越えるサイズのリクエストに 対してTCPを無条件に使うよりもこの方が望ましいと考えられる。 6.2.5. ペイロードサイズの選択 トランザクションオーバーヘッドのため、アーキテクチャー上の上限を 最大UDPペイロードサイズとして広報することは推奨されない。64KBデータ グラムを再構成する能力のあるシステムスタックでさえ、システムの低レベルの メモリ使用量が懸念事項になるだろう。良い妥協案は、4096オクテットのEDNS 最大ペイロードサイズを出発点として使用することだろう。 リクエスターは、ファイアウォールや他のネットワークの制限に対する次善策 として、より小さなサイズを広報するフォールバックの実装を選択してもよい (MAY)。リクエスターは、4096のような大きいサイズから始まるフォールバックの 仕組みの使用を選択すべき(SHOULD)である。それが失敗した場合、単一の イーサーネットフレーム内に収まる妥当な可能性を考慮し、1280-1410バイトの 範囲近辺へのフォールバックを試みるべき(SHOULD)である。それも失敗した場合、 リクエスターは512バイトのパケットを選択してもよい(MAY)が、サイズの大きい 回答はTCPによるリトライを生じさせるかもしれない。 512バイトより小さい値は、512バイトと等しいものとして処理されなければ ならない(MUST)。 6.2.6. 中間機器のサポート DNSトラフィックを運ぶネットワークには、DNS名前解決処理に直接参加して いるもの(スタブ・キャッシュリゾルバー、権威サーバー)以外にも、DNS メッセージの配送に影響を与えるアクティブな装置が存在する可能性がある (例えば、ファイアウォール、ロードバランサー、プロキシー等)。ここでは、 これらの装置類を"中間機器(middlebox)"と呼ぶ。 Damas, et al. Standards Track [Page 11] RFC 6891 EDNS(0) Extensions April 2013 EDNS準拠の中間機器は、UDP上におけるDNSメッセージサイズを512バイトに 制限してはならない(MUST NOT)。 リクエストを再帰リゾルバーに転送する単純な中間機器は、どちらの方向に おいてもOPTレコードの内容を変更してはならない(MUST NOT)。また削除も してはならない(MUST NOT)。 問い合わせに回答したり知的なフォワーダーとして動作するといった付加的な 機能を持つ中間機器は、OPTレコードを処理しその内容に応じて動作 できるべき(SHOULD)である。これらの中間機器は、メッセージの特性が異なる 場合、到着するリクエストと出て行くリクエストを独立したトランザクションと 見なさなければならない(MUST)。 この種の装置に関するより深い議論と、DNSトラフィックとの相互作用に関する 考慮点については[RFC5625]で得られる。 7. トランスポートに関する考慮点 リクエストにOPT擬似RRが存在する場合、リクエスターがEDNSの特定のバージョンを 実装しており、その機能の仕様に準拠した応答は何であれ正確に理解できる通知 だと解釈されるべきである。 リクエストにOPTレコードが存在しない場合、リクエスターはこの仕様を全く 実装しておらず、レスポンダーは応答にOPTレコードを含めてはならない (MUST NOT)という通知だと解釈されなければならない(MUST)。 EDNS対応エージェントは、新しいプロトコル要素に直面した際に、EDNS非対応 エージェントとの相互運用に対処し、必要であればEDNS非対応DNSに円滑に フォールバックできるよう準備がなされていなければならない(MUST)。 本文書定義のプロトコル拡張を実装しないと選択したレスポンダーは、付加 情報部にOPTレコードを含むメッセージに対し、FORMERRのリターンコード (RCODE)で応答しなければならず(MUST)、応答にOPTレコードを含めてはならない (MUST NOT)。 OPTレコード自身の処理で問題が生じた場合、例えばオプションの値が不正な フォーマットであったり値が適正範囲外だったりした場合、FORMERRが返されな ければならない(MUST)。このような事態が生じた場合、応答はOPTレコードを 含まなければならない(MUST)。これは、サーバーがEDNSを実装していなかった のかEDNSでフォーマットエラーが生じたのかをリクエスターが区別できる ようにするためである。 Damas, et al. Standards Track [Page 12] RFC 6891 EDNS(0) Extensions April 2013 最小限の応答は、DNSヘッダー、問い合わせ部、OPTレコードで構成されて いなければならない(MUST)。これは(DNSヘッダーのTCビットを使用した) 切り詰められた応答でも同様でなければならない(MUST)。 8. セキュリティに関する考慮点 中間機器が転送できないほど巨大なメッセージをレスポンダーが送信できる 場合、中間機器とレスポンダーの間にICMPストームを生じさせる可能性がある ため、リクエスター側の最大バッファーサイズの指定によってはDNSの サービス不能攻撃が発生してしまうかもしれない。 非常に大きいUDPバッファーサイズを広報すると、中間機器によってDNS メッセージが破棄される結果となるかもしれない(セクション6.2.6参照)。 これは成功する見込みのない再転送を生じさせる可能性がある。幾つかの デバイスは、断片化されたUDPパケットを拒否することがわかっている。 小さすぎるUDPバッファーサイズを広報すると、TCPへのフォールバックが 生じるかもしれず、相応の負荷の影響がDNSサーバーに課される結果となる かもしれない。DNSSECでは回答が非常に大きくなるため、これが特に重要な ものとなる。 9. IANAに関する考慮点 IANAはOPTに対し、RRタイプコード41を割り当てた。 [RFC2671]は "DOMAIN NAME SYSTEM PARAMETERS(DNSパラメーター)"内で 以下に示す幾つかのIANAサブレジストリを規定した。 ・DNS EDNS(0) Options (DNS EDNS(0)オプション) ・EDNS Version Number (EDNSバージョン番号) ・EDNS Header Flags (EDNSヘッダーフラグ) 加えて、既存のレジストリ内に以下に示す二つのエントリが生成された。 ・DNS Label Types(DNSラベルタイプ)レジストリのEDNS Extended Label Type (EDNS拡張ラベルタイプ)エントリ ・DNS RCODESレジストリのBad Opt Version(不正OPTバージョン)エントリ IANAは、これらのエントリとサブレジストリにおける[RFC2671]への参照を 本文書へと更新した。 [RFC2671]はDNS Label Typesレジストリを開設した。このレジストリは オープンな状態を維持する予定である。 DNS Label Typesレジストリへの登録手段は標準化活動である。 Damas, et al. Standards Track [Page 13] RFC 6891 EDNS(0) Extensions April 2013 本文書は、DNS EDNS0 Optionsレジストリにおいてオプションコード65535を "Reserved for future expansion(将来の拡張用に予約)"に割り当てる。 本文書公開時点における、EDNS Option Codeに関するIANAレジストリの現状は 以下の通りである。 ・0-4 割り当て済み。それぞれレジストリ内で参照を提示。 ・5-65000 割り当て可。未割り当て。 ・65001-65534 ローカル/実験に使用。 ・65535 将来の拡張用に予約。 [RFC2671]は、RCODE空間を4ビットから12ビットに拡張した。これにより、 [RFC1035]で許容された16種類より多くのRCODE値を扱えるようになった。 新しいRCODEを追加するにはIETFの審査が必要である。 本文書は、DNS RCODESレジストリにおいて、EDNS拡張RCODE 16を"BADVERS"に 割り当てる。 [RFC2671]は拡張ラベルタイプ0bxx111111について"将来の拡張ラベルタイプ用 に予約"と記録することを求めていた。これに対し、IANAレジストリは、現在 (DNS Label Typesレジストリに)"将来の拡張用に予約"エントリを含んでいる。 当時、このリクエストは拡張ラベルタイプ用に新しいレジストリを開設する リクエストを暗に意味していたが、解釈があいまいである可能性があったため、 代わりに一般的なDNS Label Typesレジストリ内に新しい項目で登録を行った。 同レジストリは[RFC1035]で当初定義されたエントリも登録している。 以上の理由により、Extended Label Typesレジストリは存在せず、すべてのラベル タイプはDNS Label Typesレジストリ内に登録された。 本文書はバイナリーラベルを廃止する。従って、DNS Label Typesレジストリにおける"Binary Labels"の状態は現在"歴史的(Historic)" である。 新しいEDNS(0)フラグの割り当てにはIETF標準化活動が要求される。 フラグはDNS名前解決がその機能を果たすために必要である場合にだけ 使用されるべき(SHOULD)である。多くの用途では、EDNSオプションコードを 使用する方が望ましいだろう。 EDNS Version Numberレジストリにおける新しいエントリ作成には、IETF 標準化活動が要求される。EDNS Option Code空間内において、EDNSオプション コードを割り当てるにはエキスパートレビューが要求される。本文書を通して IANAはEDNS Option Code空間用のレジストリを維持する。 Damas, et al. Standards Track [Page 14] RFC 6891 EDNS(0) Extensions April 2013 9.1. DNS EDNS0 Option Code への変更 本文書は、既存のレジストリ DNS EDNS0 Options を DNS EDNS Option Codes (OPT)に変更し、その登録手段をエキスパートレビューに更新する。 (訳注: 本段落は Errata ID: 3604を反映している)。 オプションコードの割り当ては寛大であるべきだが、機能の重複は回避される べきである。 10. References 10.1. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001. 10.2. Informative References [RFC2673] Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, August 1999. [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. [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)", RFC 3364, August 2002. [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, August 2009. Damas, et al. Standards Track [Page 15] RFC 6891 EDNS(0) Extensions April 2013 Appendix A. Changes since RFCs 2671 and 2673 Following is a list of high-level changes to RFCs 2671 and 2673. o Support for the OPT record is now mandatory. 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 RFC 2673, which defined the "Binary Labels" type and is currently Experimental, is requested to be moved to Historic. o Made changes in how EDNS buffer sizes are selected, and provided recommendations on how to select them. Authors' Addresses Joao Damas Bond Internet Systems Av Albufera 14 S.S. Reyes, Madrid 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 Phone: +1 650.423.1301 EMail: vixie@isc.org Damas, et al. Standards Track [Page 16]