ネットワークワーキンググループ D. Conrad Request for Comments: 3225 Nominum, Inc. 分類: 標準化過程(Standards Track) 2001年12月 リゾルバのDNSSECサポートの表示 本文書の位置づけ 本文書はインターネットコミュニティのためにインターネット標準化過程に あるプロトコルを規定し、改善に向けた議論と提案を求めるものである。 このプロトコルの標準化の状況については"Internet Official Protocol Standards"(STD 1)の最新版を参照のこと。本文書の配布は制限されない。 Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. 要旨 DNSSEC(Domain Name System Security Extensions)の運用を展開していくに あたり、リゾルバがDNSSEC RRを理解できるという明示的な表示がある場合に限り DNSSEC対応サーバがDNSSEC RRの自動包含処理を行えるようにすべきである。 本文書は、EDNS0ヘッダ中のビットを使用してリゾルバがDNSSEC対応であることを 明示する方法を提案し、その通知を実装するために必要なプロトコルの変更を 記述する。 1. はじめに DNSSEC[RFC2535]は、デジタル暗号署名を使用することでDNSSEC対応リゾルバ およびアプリケーションにデータの出自・完全性の検証を提供するために 規定された。しかし、DNSSECを展開していく段階で、DNSSEC未対応クライアントが DNSSEC対応サーバに問合わせを行うことが起こり得る。その場合、DNSSEC対応 サーバは(署名ゾーンのデータに対する問合わせの応答として)SIG、KEY、NXT レコードを含めた応答を返すだろう。以下のセクションで示される理由により、 そのような応答はDNSインフラストラクチャに対して運用上深刻な悪影響を及ぼす 可能性がある。 本文書はこれらの悪影響を回避する方法を記述する。すなわち、DNSSEC対応 サーバは、リゾルバからSIG、KEY、 NXT RRを理解できると明示された場合にだけ それらのRRを応答で返すようにすべきである。 本文書において"DNSSEC RR"はSIG、KEY、NXTを指すものとする。 Conrad Standards Track [Page 1] RFC 3225 Indicating Resolver Support of DNSSEC December 2001 本文書におけるキーワード"しなければならない(MUST)"、"してはならない (MUST NOT)"、"要求される(REQUIRED)"、"するものとする(SHALL)"、 "しないものとする(SHALL NOT)"、"すべきである(SHOULD)"、 "すべきでない(SHOULD NOT)"、"推奨される(RECOMMENDED)"、 "してもよい/することができる(MAY)"、"任意である(OPTIONAL)"は、 [RFC2119]の記述どおりに解釈するものとする。 2. 本提案の動機付け DNSSEC展開の初期段階では、大半の問合わせはDNSSEC未対応でDNSSEC RRを理解 またはサポートしないリゾルバからのものである。そのようなリゾルバから DNSSEC署名ゾーンへの問合わせを受信した場合、DNSSEC仕様はネームサーバに対し 適切なDNSSEC RRを含めた応答をするよう指示している。DNS UDPデータグラムは 512バイトに制限されている[RFC1035]ため、DNSSEC RRを含む応答は高い確率で 切り詰め処理が行われるので、リゾルバはTCPを使用して問合わせをリトライする ことになる。 TCPによるDNS問合わせでは、TCP接続の開始・終了に伴う大幅なオーバーヘッドが 生じる。運用面から見ると、TCPによる問合わせの影響は、おそらく極めて有害 である。その理由として、ネットワークトラフィックの増加(一般に、単一の 問合わせ/応答でUDPでは2パケットだがTCPは5パケット必要とする)、パケットが 増えた分ラウンドトリップタイムも増えることによる全体的な応答遅延の増加、 タイムアウトによる問合わせ失敗の発生率の増加、ネームサーバ負荷の大幅な 増加などが挙げられる。 加えて、DNSSECの予備的・試験的導入において、DNSSEC RRを含む応答を処理 できないDNSSEC未対応リゾルバが(最悪の場合)障害を引き起こしたり、(より ましな場合)応答全体が無視されるといった結果になることが報告されている。 これらの運用上の経験を考慮すると、クライアントがDNSSEC RRを受信する 用意がある(DNSSEC RRを処理できないとしても)ことをネームサーバに 明示的に通知するのが賢明なやり方だろう。 クライアント側のDNSSECサポートは2つの選択肢しかない。クライアントは DNSSEC RRを全て受理したいか、全く受理したくないかのどちらかである。 したがって、クライアント側のDNSSECサポートを表示するには1ビットあれば 充分である。DNSSECを効果的に使用するにはEDNS0[RFC2671]が必要なことが示唆 されていること、"従来の"(ENDS拡張されていない)DNSヘッダはビットが不足して いること、プロトコル非準拠のキャッシュサーバまたは転送サーバが問合わせを 権威サーバに中継する際に、従来ヘッダから適切にデータをコピーできないような 状況が想定されることから、本文書ではEDNS0ヘッダ内のビットを使用することを 提案する。 別のアプローチとして、クライアント側のDNSSECサポートを暗に示す手段として EDNS0ヘッダの存在そのものを利用する方法もあるかもしれない。しかし、この アプローチは選択されなかった。EDNS0はサポートするがDNSSECは利用できない アプリケーションが存在するかもしれないからである。 Conrad Standards Track [Page 2] RFC 3225 Indicating Resolver Support of DNSSEC December 2001 3. プロトコルの変更 クライアントがDNSSEC RRを(処理できないとしても)受理する機能があることを 明示するために、問合わせのEDNS0 OPTヘッダのZフィールドの最上位ビットを 使用する方法を選択する。このビットを"DNSSEC OK"(DO)ビットと呼ぶ。 DOビットは、EDNS0 OPT擬似(メタ)RRの"拡張RCODEおよびフラグ(extended RCODE and flags)"部の第3、第4バイトの先頭1ビット目であり、以下の構造を持つ。 +0 (MSB) +1 (LSB) +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0: | 拡張RCODE | バージョン | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2: |DO| Zフィールド | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 問合わせのDOビットを1に設定することにより、リゾルバがDNSSEC RRを 受理可能であることをサーバに表示する。クリアされた(0に設定された)DOビット は、リゾルバがDNSSEC RRを処理する準備ができていないことを示すので、 (DNSSEC RRが明示的に問合わされていなければ)DNSSEC RRを応答で返しては ならない(MUST NOT)。問合わせのDOビットは応答にコピーされなければならない (MUST)。 より明確に記述すると、DNSSEC対応ネームサーバは、問合わせにDOビットが設定 されていないならば、[RFC2535]記載の応答の認証のためにSIG、KEY、NXT RRを 返してはならない(MUST NOT)。明示的なSIG、KEY、NXTへの問い合わせまたは ANYへの問い合わせに一致した場合、あるいは署名ゾーンのデータに対して AXFRまたはIXFRが要求された場合、DOビットの設定に関わらずDNSSEC RRは応答に 含められる。 DNSSEC対応再帰ネームサーバは、リゾルバからの問合わせにDOビットが設定 されていたかに関わらず、再帰検索の問合わせにはDOビットを設定しなければ ならない(MUST)。リゾルバからの問合わせにDOビットが設定されていなかった 場合、DNSSEC対応ネームサーバはリゾルバに回答する前にDNSSEC RRを取り除かな ければならない(MUST)。ただしキャッシュされたデータを変更してはならない (MUST NOT)。 DOビットを設定した問合わせに対してサーバからNOTIMP、FORMERR、SERVFAIL 応答を返された場合、リゾルバはDNSSEC RRを期待すべきではなく(SHOULD NOT)、 [RFC2671]のセクション5.3に従ってEDNS0無しでリトライすべきである(SHOULD)。 Conrad Standards Track [Page 3] RFC 3225 Indicating Resolver Support of DNSSEC December 2001 セキュリティに関する考慮点 DOビットを設定した問合わせに対してDNSSECデータが応答されない場合に、 そのゾーンをDNSSEC使用不能と判断してはならない(MUST NOT)。 応答は偽造されたものかもしれないし、改変された(DOビットがクリアされた) 問合わせに対する正常な応答かもしれないからである。 IANAに関する考慮点 EDNS0[RFC2671]は、OPTレコードの拡張フラグとして16ビットを定義している。 これらのビットは、OPTレコードのTTLフィールドにエンコードされる(RFC2671 セクション4.6)。 本文書は、これらのビットの1つをDOビットとして予約しており、左端ビットが 割り当てられることを要求している。したがって、OPTレコードのTTLフィールドの 使用形態は以下のようになる。 +0 (MSB) +1 (LSB) +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0: | 拡張RCODE | バージョン | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 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. References [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specifications", 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. [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. Conrad Standards Track [Page 4] RFC 3225 Indicating Resolver Support of DNSSEC December 2001 Author's Address David Conrad Nominum Inc. 950 Charter Street Redwood City, CA 94063 USA Phone: +1 650 381 6003 EMail: david.conrad@nominum.com Conrad Standards Track [Page 5] RFC 3225 Indicating Resolver Support of DNSSEC December 2001 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. Conrad Standards Track [Page 6]