RFC2671-JP.txt 2000/09/27 (initial version)
(C)JPNIC RFC-JP project, 2000. All rights reserved.
Network Working Group P. Vixie
Request for Comments: 2671 ISC
Category: Standards Track August 1999
DNS用拡張メカニズム (EDNS0)
本メモの状態について
この文書はインターネットコミュニティにおけるインターネット標準プロ
トコルを規定しており、品質向上のための議論や意見を要求するものであ
る。標準化の状態およびこのプロトコルの状態については最新の
「Internet Official Protocol Standards」(STD 1)を参照していただきた
い。このメモは無制限に配布してかまわない。
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
要約
ドメイン名システム(DNS)用の伝送プロトコルには固定長フィールドが存在
する。これらの固定長フィールドにはすでにあふれてしまっているものや
あふれる直前のフィールドが多数存在しているため、クライアントのケー
パビリティをサーバに伝達できないものがある。本文書はプロトコルを拡
張する後方互換性のある機構について論じている。
1 - 原理および対象範囲
1.1.
DNS([RFC1035]参照)はメッセージ形式を規定している。また、これらの
メッセージにおいて符号化オプション、エラー、名前圧縮に関する標準
形式も定義している。DNSメッセージの最大許容長は固定である。DNSプ
ロトコルの多くは将来にわたって標準として利用できるようにするため
にプロトコル上のきびしい制約のもとで設計されている。そのため、DNS
のケーパビリティを伝える手段を実装する方法は存在しない。
1.2
既存のクライアントは本文書でのプロトコル拡張を解釈するすべを持た
ない。このようなクライアントが更新されるのは新しい機能が必要になっ
たときだけで、提案されている拡張はその新しい機能でしか意味を持た
ない。だが、既存クライアントが余分なフィールドを受け取ったときの
挙動の考察や、そのようなクライアントと相互運用性を保つための方法
の設計が必要である。
Vixie Standards Track [Page 1]
RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999
2 - プロトコル要素中で影響をうけるもの
2.1
DNSメッセージヘッダ([RFC1035 4.1.1]を参照)の2番目の16ビットワード
は4ビットのOPCODE、4ビットのRCODE、多数の1ビットフラグに分割でき
る。規格策定当初は予約となっていたZビットもすでにさまざまな用途に
割り当てられ、RCODE値に関しても大部分が利用中である。したがって、
さらに多くのフラグや用途の広いRCODEが必要となっている。
2.2
伝送形式ドメインラベルの最初の2ビットはラベルの種類を表現するため
に用いられている。[RFC1035 4.1.4]では利用できる4種類のうち2種類を
割り当てており、残りの2種類は予約になっている。これらの残っている
エントリの割り当てを希望する要求は実際に残っている数よりもずっと
多い。したがって、さらなるラベルの種類が必要である。
2.3
DNSメッセージをUDPを利用して送信する場合、そのサイズは512オクテッ
ト以下でなければならない。UDPペイロードの512オクテット制限は最大
再構築バッファの最小長を考慮したものであるとはいえ、現在インター
ネットに接続しているほとんどのホストはこのサイズ以上のデータグラ
ムを再構築できる。したがって、要求ホスト側から返答ホストに対して
大きなバッファ長を伝達するためのなんらかの機構が必要である。
3 - 拡張ラベル型
3.1
ラベルタイプ「0 1」は、今後は拡張ラベル型を示すようになる。ラベル
型はラベルの最初のオクテット中の下位6ビットに符号化される。今後開
発されるすべてのラベルタイプは拡張ラベルタイプを使って符号化する
ほうがよい(should)。
3.2
拡張ラベルタイプ「1 1 1 1 1 1」は拡張ラベルタイプコード空間を将来
拡張する場合に備えて予約される。
4 - OPT疑似RR(OPT pseudo-RR)
4.1
OPT疑似RRは要求および応答の付加データセクションにひとつだけ追加で
きるRRである。OPTは特定のトランスポートレベルメッセージに付随する
もので、実際のDNSデータではないことから疑似RRと呼ばれる。OPT RRの
キャッシュ、フォワード、主ファイルへの保存、主ファイルからの呼び
込みは推奨されない。また、メッセージに含まれるOPT疑似RRの数はひと
つ以下にすべきである。
4.2
OPT RRは固定部分および{属性, 値}の組で表現されるさまざまなオプショ
ンで構成される。固定部分にはいくつかのDNSメタデータと、{属性, 値}
の組として符号化するのは通信効率上無駄だと思われるくらい一般的な
プロトコル要素が含まれる。
Vixie Standards Track [Page 2]
RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999
4.3
OPT RRの固定部分の構造を以下に示す。
フィールド名 フィールドタイプ 説明
------------------------------------------------------
NAME ドメイン名 空(ルートドメイン)
TYPE u_int16_t OPT
CLASS u_int16_t 送信者のUDPペイロードサイズ
TTL u_int32_t 拡張RCODEおよびフラグ
RDLEN u_int16_t RDATAを記述
RDATA オクテットストリーム {属性, 値}の組
4.4
OPT RRの可変部分はRDATA中に符号化され、ゼロ個以上の以下の形式から
なる構造を持つ。
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | OPTION-CODE(オプションコード) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | OPTION-LENGTH(オプション長) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: | |
/ OPTION-DATA /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
OPTION-CODE(オプションコード) (IANAによって割り当てられる)
OPTION-LENGTH(オプション長) OPTION-CODEの(オクテットでの)大きさ
OPTION-DATA OPTION-CODEごとに異なる
4.5
RR CLASSフィールド中にOPTを格納しているペイロードの送信者側のUDP
ペイロード長は送信側のネットワークスタックで再構築および送信が可
能な最大オクテット数である。パケットの断片化の有無にかかわらずこ
の大きさより経路MTU(Path MTU)が小さくなるかもしれない可能性に留意
すること。
4.5.1
512オクテットのUDPペイロードは576オクテットのIP再構築バッファを必
要とすることに注意。要求側がEthernetに接続されているのなら1280を
選ぶのが妥当だろう。過大な値を選ぶと中間ゲートウェイからICMPメッ
セージが送られてしまうかもしれないし、さらには返答メッセージがだ
まって捨てられてしまうかもしれない。
4.5.2
メッセージの大きさについて考える場合、要求側および応答側のどちら
も(もし既知であるならば)経路MTU探索の結果を考慮に入れるほうがよい。
Vixie Standards Track [Page 3]
RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999
4.5.3
要求側からの最大ペイロード長は時間の経過に従って変化するかもしれ
ないため、通知されたトランザクションが終わった後はキャッシュすべ
きではない。
4.5.4
応答側の最大ペイロードサイズは時間の経過に従って変化するかもしれ
ないが、ふたつの連続トランザクションの間は一定であることが十分に
予想できる。たとえば、応答側の最大UDPペイロードサイズを知るために
行われる特に意味のない問い合わせ(QUERY)の後には、すぐにこのサイズ
を使った更新(UPDATE)が続くことになる。(応答側がEDNSを実装しており
要求がデフォルトの512ペイロードサイズ制限に適さないと考えられる理
由がある場合には、サイズが512オクテットを超える要求に対して無条件
でTCPを使うため、この動作が適当だと考えられている。)
4.5.5
アーキテクチャ的な制限を最大UDPペイロードサイズとして通知すること
は、トランザクションが過負荷となることから望ましいとはいえない。
スタックが64Kバイトのデータグラムを再構築できるという理由だけで、
進行中のトランザクションごとに約4Kバイト以上の状態メモリを使いた
くなったりはしないだろうからである。
4.6
(OPTがRR TTLフィールドに格納する)拡張RCODEおよびフラグの
構造を以下に示す。
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | EXTENDED-RCODE(拡張RCODE) | VERSION |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | Z |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
EXTENDED-RCODE(拡張RCODE)
拡張された12ビットRCODEの上位8ビット。
EXTENDED-RCODEの値「0」は非拡張RCODEが使われている
(値「0」から「15」)ことを示す。
VERSION 実装レベルを示す。この値は任意に設定される。値「0」
は本仕様に完全に適合していることを示す。要求側と応
答側の間で共通の実装レベルのうち最も適した実装レベ
ルを発見するために必要となるネットワークおよび応答
側の負荷を抑えるためには、要求側では、このフィール
ドにはトランザクションを表現するために必要最低限の
実装レベルを設定することが推奨される。この値に関す
る要求側の決定戦略は理想的には実行時設定オプション
となるべきだろう。
Vixie Standards Track [Page 4]
RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999
応答側が要求されたVERSIONレベルを実装していない場合
は、RCODE=BADVERSを返す。すべての応答の形式は要求の
VERSIONレベルに制限されるが、各応答のVERSIONは応答
側の最高実装レベルに設定される。この方法により、要
求側は各応答の副作用として応答側の実装レベルを検知
できる。これはRCODE=BADVERSなどのエラー応答の場合に
も相当する。
Z 今後の仕様で変更されない限り、送信者はゼロに設定し
受信者は無視する。
5 - 配送に関する考察
5.1
要求にOPT疑似RRが含まれている場合、要求側には示されているEDNSのバー
ジョンが完全に実装されており、該当バージョンの仕様に従うすべての
応答を正しく理解できると考えるべきである。
5.2
要求中にOPT疑似RRが使われていない場合、要求側にはこの仕様はまった
く実装されておらず、また、応答側からの応答にはここで記述されてい
るプロトコル拡張は使われないはずだ、と考えなければならない。
5.3
これらのプロトコル拡張が応答側で理解されなかった場合、RCODE
NOTIMPL、FORMERR、SERVFAILのいずれかが返答されることが予想される。
したがって拡張を使う場合には、拡張をサポートしているかを判別でき
ない応答者がこれらのRCODEを返答した場合に拡張を使わずに再試行でき
るよう、拡張の使用を探査(probe)すべきである。応答側で可能なレベル
が要求側にキャッシュされているなら、定期的に探査を送信して応答側
の性能に変化がないかを確かめるほうがよい。
6 - セキュリティに関する考察
応答側が中間ゲートウェイで転送できない過大な送信メッセージを作成で
きる場合、要求側の最大バッファサイズに関する仕様によってはゲートウェ
イと応答側の間における潜在的なICMPストームを引き起こす原因となる可
能性があるため、新しいDNSのサービス不能攻撃を招く可能性がある。
7 - IANAに関する考察
IANAはOPT用にRRタイプ41を割り当てた。
本文書および当分科会は、EDNSオプションコードおよびEDNSバージョン番
号に対するEDNS拡張ラベルタイプ用レジストリをIANAが作成することを推
奨する。
本文書は「EDNS拡張ラベルタイプ」としてラベルタイプ0b01xxxxxxを割り
当てる。我々はIANAにこの割り当てを登録することを要求する。
Vixie Standards Track [Page 5]
RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999
本文書は"将来の拡張ラベルタイプのための予約"として拡張ラベルタイプ
0bxx111111を割り当てる。我々はIANAにこの割り当てを登録することを要
求する。
本文書は"将来の拡張のための予約"としてオプションコード65535を割り当
てる。
本文書はRCODE空間を4ビットから12ビットに拡張する。これによりIANAは
[RFC1035]で認められている16種類のRCODE値よりも多くのRCODE値を割り当
てられるようになる。
本文書はEDNS拡張RCODE「16」を「BADVERS」に割り当てる。
新たなエントリをEDNS拡張ラベルタイプやEDNSバージョン番号レジストリ
内で作成する際にはIESGによる認可を必要とすべきである。また、どのよ
うな種類のRFC(Informational、Experimental、BCPを含む)であろうとも公
開されるRFCはEDNSオプションコード割り当ての基盤要素とすべきである。
8 - 謝辞
本仕様を作成していく過程において以下の人々の協力を得た。Paul
Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley,
Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, Thomas
Narten
9 - 参考文献
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
10 - 著者の連絡先
Paul Vixie
Internet Software Consortium
950 Charter Street
Redwood City, CA 94063
Phone: +1 650 779 7001
EMail: vixie@isc.org
Vixie Standards Track [Page 6]
RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999
11 - 完全な著作権表示
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 implmentation 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."
Copyright (C) The Internet Society (1999). All Rights Reserved.
本記述とその翻訳は複写し他に提供することができる。また論評を加えた
派生的製品や、この文書を説明したり、その実装を補助するもので、上記
の著作権表示およびこの節を付加するものはすべて、全体であってもその
一部であっても、いっさいの制約を課されること無く、準備、複製、発表、
配布することができる。しかし、この文書自体にはいかなる方法にせよ、
著作権表示やインターネットソサエティもしくは他のインターネット関連
団体への参照を取り除くなどの変更を加えてはならない。インターネット
標準を開発するために必要な場合は例外とされるが、その場合はインター
ネット標準化過程で定義されている著作権のための手続きに従わなければ
ならない。またRFCを英語以外の言語に翻訳する必要がある場合も例外であ
る。
以上に述べられた制限は永久的なものであり、インターネットソサエティ
もしくはその継承者及び譲渡者によって破棄されることはない。
本文書とここに含まれた情報は「無保証(AS IS)」で提供され、インターネッ
トソサエティおよびIETFは、この情報がいかなる権利も侵害していないと
いう保証、商用利用および特定目的への適合性への保証を含め、また、こ
れらだけに限らずすべての保証について、明示的もしくは暗黙的の保証は
行われない。
謝辞
RFC Editorの職務に関する財政的支援はインターネットソサエティーによっ
て行われている。
Vixie Standards Track [Page 7]
RFC-JP日本語翻訳物の著作権に関する告知
本文書は、インターネット技術の正しい普及と振興を目的として、社団法人
日本ネットワークインフォメーションセンター(JPNIC)が行っているRFC翻訳
プロジェクト(RFC-JP)の成果物である。rfc-copyright-storyに従い、
RFC2220以降のものについては“Full Copyright Statement”を含め、
RFC2219以前のものについては原著者の了解を得て翻訳している。これによ
り作成された二次的著作物である本文書の著作権はJPNICが保持するが、こ
の権利の設定は原文から新たな翻訳を作成し公開することを妨げるものでは
ない。
また、RFC-JPとしてこの文書に記載された情報の内容が正確であることに努
めているが、正確性を含めいっさいの品質についてこれを保証するものでは
ない。したがって、この文書に記載された情報に基づいて貴方あるいは貴組
織がとられた行動によって引き起こされる結果に対して、JPNICは何ら保証
を与えない。
本文書は、本著作権表示を含めて改変しないことを条件に再配布を許可する。
ただし日本語訳は固定ではなく、誤りの発見や正確性の向上のために必要に
応じて適宜更新される可能性がある。常に最新の版を入手するようにしてい
ただきたい。最新版は<URL:http://rfc-jp.nic.ad.jp/>から入手できる。
JPNICはインターネットの円滑な運営を支えるための組織です
- JPNIC
-
IPアドレス・AS番号
指定事業者向け各種申請手続/お知らせ
一般ユーザーの方
-
JPNIC会員
会員向け情報/各種変更手続
入会のご案内
