ネットワークワーキンググループ O. Gudmundsson Request for Comments: 3226 2001年12月 更新(Updates): 2874, 2535 分類: 標準化過程(Standards Track) DNSSECおよびIPv6対応サーバ/リゾルバのメッセージサイズに関する要件 本文書の位置づけ 本文書はインターネットコミュニティのためにインターネット標準化過程に あるプロトコルを規定し、改善に向けた議論と提案を求めるものである。 このプロトコルの標準化の状況については"Internet Official Protocol Standards"(STD 1)の最新版を参照のこと。本文書の配布は制限されない。 Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. 要旨 本文書は、DNSSEC RRまたはA6 RRサポートを表示するDNS実装にEDNS0の サポートを要求するものである。これらの新しいレコードはDNSメッセージ サイズを増大させるので、この要求は必須である。EDNS0がサポートされない場合、 TCPへのフォールバックが発生し、問合わせの応答遅延やDNSサーバの負荷増大 などの悪影響が発生する。本文書は、新しい要件を追加することにより、 RFC 2535とRFC 2874を更新する。 1. はじめに DNS[RFC1034、RFC1035]、DNSSEC[RFC2535]、EDNS0[RFC2671]、A6[RFC2874]に 精通していることが本文書の理解の助けとなる。 STD 13またはRFC 1035のセクション2.3.4では、UDPで配送されるDNSメッセージは データペイロードを512オクテット以下にするように要求している。今日存在する ほとんどのDNSソフトウェアは、512オクテットを越えるUDPデータグラムを 受理しない。512オクテットを越えるサイズの回答は、切り詰め処理ビット (Truncation Bit)が設定された部分的な回答となり、時にそれは役に立たない ものになる。したがって、ほとんどの場合、問合わせ側はTCPを使用して リトライを行う。更に、サーバ側の応答切り詰め処理は非常に多様であるため、 リゾルバの切り詰め処理対応も多様となる。その結果、切り詰め処理対応は 更なる非効率を生むことになる。 DNSのような簡素なトランザクションに使用する場合、TCPはUDPと比べてコストの 高いプロトコルである。TCPは接続と解除のためにデータパケット以外に5パケット 必要であるから、オリジナルのUDP問合わせに加えて3往復分の通信を必要とする。 また、DNSサーバもトランザクションの間、接続の状態を維持する必要がある。 多くのDNSサーバは1秒間に数千の問合わせに応答するため、TCPの使用を 要求すると、深刻なオーバヘッドと遅延を生じることになる。 Gudmundsson Standards Track [Page 1] RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 1.1. 要求に関連する用語 本文書におけるキーワード"しなければならない(MUST)"、"要求される (REQUIRED)"、"すべきである(SHOULD)"、"推奨される(RECOMMENDED)"、 "してもよい/することができる(MAY)" は、RFC 2119の記述どおりに 解釈するものとする。 2. 本提案の動機付けを与える要素 2.1. DNSSECに関するもの DNSSEC[RFC2535]は、各RRsetに公開鍵暗号による署名を追加することでDNSを 保護するものである。これらの署名サイズは、およそ80オクテットから800 オクテットの間に分布しており、そのほとんどは80オクテットから200オクテットの 範囲に存在する。応答に含まれる全RRsetまたは大半のRRsetに署名を追加すると、 署名ゾーンからの応答サイズは著しく増加する。 パフォーマンスを維持し、DNSサーバの負荷を軽減するためにも、DNSSEC対応 サーバおよびリゾルバが、1度の問合わせで回答部(Answer Section)および 権威部(Authority Section)の全データを切り詰め処理無しで取得できることが 重要である。サーバが問合わされたデータに対して権威を持つ場合、応答に 付加情報部(Additional Section)のデータを含められれば有用であり、往復の 通信回数を減らすことができる。 DNSSEC OKビット(DOビット)は、クライアントがEDNS0を使用して、DNSSEC RRの 受信に関心があることを表明する方法を規定する。しかし、DOビットによって DNSSEC対応クライアントに対してサイズの大きい応答を返す必要がなくなる わけではない。 2.1.1. メッセージ認証またはTSIGに関するもの TSIG[RFC2845]は、軽量なDNSメッセージ認証を可能にするが、メッセージ サイズを少なくとも70オクテット増加させる。DNSSECは、標準の公開鍵暗号署名 を使用するSIG(0)という計算コストの高いメッセージ認証を規定している。 各DNS応答には、TSIGまたはSIG(0)を1つしか添付できないため、メッセージ認証の ためのサイズ増加はそれほど深刻ではないが、依然として切り詰め処理が発生する 可能性がある。 2.2. IPv6に関するもの IPv6アドレス[RFC2874]は128ビットであり、DNSでは複数のA6レコードで表現 される。各A6レコードはドメイン名とビットフィールドから構成される。 ドメイン名はアドレスプレフィクスを参照しており、これは、応答において 追加のA6 RRを要求するものである。A6アドレスを含む場合、512オクテットの UDPパケットサイズをオーバフローする可能性がある。 Gudmundsson Standards Track [Page 2] RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 2.3. ルートサーバおよびTLDサーバに関するもの ルートサーバの現在の数は13に制限されている。この数がルートのSOAに対する 512オクテットの応答1つに収まるネームサーバ(訳注: NSレコード)と アドレスレコード(訳注: Aレコード)の最大数だからである。ルートサーバが A6またはKEYレコードの公開を開始すると、ルートのNSレコードに対する 問合わせの応答は、512オクテットのDNSメッセージ1つには収まらない。 結果として膨大な数のTCPの問い合わせがルートサーバに対して発生する。 全てのクライアントリゾルバがキャッシュサーバを経由して問合わせを行うに しても(訳注: そうなるとTCPの問合わせ数はキャッシュサーバの数に減少する) これらのサーバは数百万ある。また、キャッシュサーバは定期的に上位レベルの ネームサーバについてのキャッシュ情報を更新しなければならない。 冗長性確保、応答遅延の均一化、負荷分散の実現など、様々な理由により、 特定のゾーンでは多数のDNSサーバが必要とされる。ルートゾーンはインターネット 全体から使用されるため、可能な限り多くのサーバを持つことが重要である。 大規模なTLD(と、非常に認知度の高い多くのSLD)は、A6レコードまたはKEY レコードによってNSの応答が512バイトの制限を越えてしまうのに充分な数の サーバを持つ場合がある。多数のサーバを持つこれらのゾーンは、多くの場合 ネットワーク運用のために重要であり、既にかなり高い負荷がかかっていることに 注意してもらいたい。 2.4. DNSメッセージにおけるUDPとTCPの対比 これまでに記述した全ての要素を考慮すると、DNSSECやA6をサポートするあらゆる 実装は、512オクテットよりも大きいサイズのDNSメッセージを使用できることが 不可欠である。 オリジナルの512オクテットという制限は、DNS応答が断片化される可能性を 低くするために設定された。断片が消失したUDPメッセージは、無意味な応答に なるため、問合わせはリトライが必要となる。TCP接続は、接続の確立、データの 転送、接続の解除のためにより多くのパケットの往復を必要とするが、消失した データセグメントだけが再送される。 ごく初期の頃は、多数のIP実装は断片化をうまく処理できなかったが、現代の オペレーティングシステムは全てこの問題を克服しているので、断片化された メッセージを送信しても問題はない。未解決の問題は、断片化されたメッセージの 一部が消失した場合の影響である。パケット消失率が高い場合には、TCPでしか DNSデータを確実に転送することができない。しかし、ほとんどのリンクでは パケット消失率は低いので、断片化されたUDPパケットを1往復の通信で送信する ほうが、数千オクテットのデータ転送のためにTCP接続を確立するよりも望ましい。 Gudmundsson Standards Track [Page 3] RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 2.5. EDNS0とサイズの大きいUDPメッセージ EDNS0[RFC2671]は、処理できるUDPメッセージの最大サイズをクライアントが 宣言することを可能としている。したがって、予想される応答サイズが512 オクテットからクライアントが受理可能な最大サイズの間になるならば、 TCP接続の余分なオーバヘッドを回避することができる。 3. プロトコルの変更 本文書は、新しい要件を追加することにより、RFC 2535とRFC 2874を更新する。 RFC 2535準拠の全サーバ・リゾルバは、EDNS0をサポートし、最低1220オクテットの メッセージサイズを広報しなければならない(MUST)。しかし4000オクテットの メッセージサイズを広報すべきである(SHOULD)。ここに示した値は、上位レベルの サーバからの応答全てを得るには小さすぎるかもしれないため、本文書を 継承する文書では、より大きな値を要求する可能性がある。 RFC 2874準拠の全サーバ・リゾルバは、EDNS0をサポートし、最低1024オクテットの メッセージサイズを広報しなければならない(MUST)。しかし2048オクテットの メッセージサイズを広報すべきである(SHOULD)。IPv6データグラムは、パスMTUが 明らかでない限り1024オクテットにすべきである。(この値は、IPv6の最小MTUを 超えずに拡張ヘッダ適用やカプセル化を可能とするために、IPv6 最小MTUより 小さくなっていることに注意してもらいたい)。 RFC 2535とRFC 2874に準拠する全ての実装は、断片化したIPv4およびIPv6の UDPパケットを処理できなければならない。 RFC 2535とRFC 2874の両方をサポートする全てのホストは、それぞれの プロトコルがEDNS0の広報において要求するメッセージサイズのうち、 大きい方の値を使用しなければならない(MUST)。 4. Acknowledgments Harald Alvestrand, Rob Austein, Randy Bush, David Conrad, Andreas Gustafsson, Jun-ichiro itojun Hagino, Bob Halley, Edward Lewis Michael Patton and Kazu Yamamoto were instrumental in motivating and shaping this document. 5. セキュリティに関する考慮点 RFC 2671記載のもの以外に追加のセキュリティ上の考慮点は無い。 6. IANAに関する考慮点 無し。 Gudmundsson Standards Track [Page 4] RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 7. References [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987. [RFC2535] Eastlake, D. "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000. [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001. 8. Author Address Olafur Gudmundsson 3826 Legation Street, NW Washington, DC 20015 USA EMail: ogud@ogud.com Gudmundsson Standards Track [Page 5] RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 9. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. 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. Gudmundsson Standards Track [Page 6]