ネットワークワーキンググループ M. Andrews RFC: 2308 CSIRO 更新(Updates): 1034, 1035 1998年3月 分類: 標準化過程(Standards Track) DNSの問い合わせのネガティブキャッシュ(DNS NCACHE) Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. 要旨 [RFC1034]は不在応答のキャッシュ方法を記述している。しかし、RFC 1034の 記述は、ネームサーバーがキャッシュした不在応答をリゾルバーに配信することを 許可しないという根本的な欠陥があるため、キャッシュの効果を著しく減じて しまっている。本文書は、運用経験を通して明らかになった問題に対応すると ともに、[RFC1034 Section4.3.4]を置き換える。 ネガティブキャッシュは DNS 仕様の任意(optional)な部分であり、RRset [RFC2181] またはドメイン名の不在情報をキャッシュするものである。 ネガティブキャッシュは不在応答を返す時間を短縮できるので有用である。 また、リゾルバーとネームサーバーとの間でやりとりされる多数のメッセージを 削減するので、ネットワークトラフィックの全体的な抑制にも寄与する。 全リゾルバーがネガティブキャッシュを実装すれば、インターネットの DNS トラフィックの大部分を取り除くことができるだろう。この点を考慮すると、 ネガティブキャッシュを今後も DNS リゾルバーの任意実装部分にしておくべき ではない。 Andrews Standards Track [Page 1] RFC 2308 DNS NCACHE March 1998 1 - 用語 本文書における "しなければならない(MUST)"、"してはならない(MUST NOT)"、 "要求される(REQUIRED)"、"するものとする(SHALL)"、"しないものとする (SHALL NOT)"、"すべきである(SHOULD)"、"すべきではない(SHOULD NOT)"、 "推奨される(RECOMMENDED)"、"してもよい/することができる(MAY)"、 "任意である(OPTIONAL)" というキーワードは、RFC 2119に記述される通りに 解釈するものとする。 "ネガティブキャッシュ": 何かが存在しないという情報の保存場所。サーバーは レコードが特定の値を保持するという情報を保存できる。その逆も可能である。 つまり、レコードが存在しないという情報も保存できる。何かが存在しない、 回答が提供できない/されないといった情報を保存する場所をネガティブ キャッシュと呼ぶ。 "QNAME": 回答の問い合わせ部で指定された名前。問い合わせの結果が CNAME や CNAME の連鎖になる場合は、最後の CNAME のデータフィールドで指定された 名前。ここで言う "最後の CNAME" とは、ラベルを名前解決した結果(データ フィールドに指定される名前)が他の CNAME でないものを指す。 実装者は、CNAME レコードを順序立てて応答に保存するよう注意すべきである。 具体的に、問い合わせ部から得た名前をラベルに持つ CNAME を先頭にし、 (複数の CNAME が必要な場合)次の CNAME のラベルは前の CNAME のデータ フィールド値となるように順序づけを行う。このように順序立てておくことで、 先頭から順番に処理できるため、受信者側の処理負担が大幅に軽減される。 (SIG RR [RFC2065]のような)他の関連レコードが CNAME と CNAME の間に 存在できる。 "NXDOMAIN": [RFC1065 セクション4.1.1]記載の "Name Error(名前エラー)" RCODE の別の表記法。本文書ではこの二つの用語を同じ意味を持つものとして扱う。 "NODATA": 指定されたクラスを持つ名前としては正当だが、指定されたタイプの レコードは持たないことを示す擬似 RCODE。NODATA 応答は、回答からの推論を 必要とする。 "フォワーダー": 問い合わせの名前解決の際に、複数の権威サーバーの連鎖を直接 たどる代わりに使用されるネームサーバー。大抵の場合、フォワーダーは インターネットアクセスがより良好であるか、多数のリゾルバーで共有する より大きいキャッシュを保持しているかのどちらかである。あるサーバーが フォワーダーかどうかを判定する、あるいはフォワーダーとして使用されているか どうかを判定する方法は、本文書の対象外である。しかし、サーバーが フォワーダーとして使用されているのであれば、問い合わせには再帰要求(RD) フラグが設定されているだろう。 本文書を読み解くにあたり、[RFC1034]、[RFC1035]、[RFC2065]の理解が 前提となる。 Andrews Standards Track [Page 2] RFC 2308 DNS NCACHE March 1998 2 - 不在応答 最も目にする機会の多い不在応答は、特定の RRset が DNS 内に存在しない ことを示すものである。本文書の最初のセクションでこの事例を扱う。他にも 否定的な応答があり、ネームサーバー障害を通知することができる。これらに ついてはセクション7 (他の否定的応答) で扱う。 不在応答は以下のサブセクションに示す内容の一つが提示される。 2.1 - Name Error Name Error (NXDOMAIN) は、RCODEフィールド値が "Name Error" になっている ことで提示される。この場合、QNAME が参照しようとしたドメイン名は存在 しない。注：回答部はSIG、CNAME RRを、権威部は SOA、NXT [RFC2065]、 SIG RRsetを保持する場合がある。 権威部に NS または SOA レコードがあるかどうかに拘わらず、RCODE の値が NXDOMAIN になっているので、応答が参照応答なのか NXDOMAIN なのかを区別する ことは可能である。 NXDOMAIN 応答は、権威部の内容に応じて4タイプに分類することができる。 この4タイプと、比較のために参照応答をあわせて以下に示す。記載のない フィールドは、この例示においては重要でないものである。 NXDOMAIN 応答: タイプ1 ヘッダー部: RDCODE=NXDOMAIN 問い合わせ部: AN.EXAMPLE. A 回答部: AN.EXAMPLE. CNAME TRIPPLE.XX. 権威部: XX. SOA NS1.XX. HOSTMASTER.NS1.XX. .... XX. NS NS1.XX. XX. NS NS2.XX. 付加情報部: NS1.XX. A 127.0.0.2 NS2.XX. A 127.0.0.3 NXDOMAIN 応答: タイプ2 ヘッダー部: RDCODE=NXDOMAIN 問い合わせ部: AN.EXAMPLE. A Andrews Standards Track [Page 3] RFC 2308 DNS NCACHE March 1998 回答部: AN.EXAMPLE. CNAME TRIPPLE.XX. 権威部: XX. SOA NS1.XX. HOSTMASTER.NS1.XX. .... 付加情報部: <空> NXDOMAIN 応答: タイプ3 ヘッダー部: RDCODE=NXDOMAIN 問い合わせ部: AN.EXAMPLE. A 回答部: AN.EXAMPLE. CNAME TRIPPLE.XX. 権威部: <空> 付加情報部: <空> NXDOMAIN 応答: タイプ4 ヘッダー部: RDCODE=NXDOMAIN 問い合わせ部: AN.EXAMPLE. A 回答部: AN.EXAMPLE. CNAME TRIPPLE.XX. 権威部: XX. NS NS1.XX. XX. NS NS2.XX. 付加情報部: NS1.XX. A 127.0.0.2 NS2.XX. A 127.0.0.3 参照応答 ヘッダー部: RDCODE=NOERROR 問い合わせ部: AN.EXAMPLE. A 回答部: AN.EXAMPLE. CNAME TRIPPLE.XX. 権威部: XX. NS NS1.XX. XX. NS NS2.XX. 付加情報部: NS1.XX. A 127.0.0.2 NS2.XX. A 127.0.0.3 Andrews Standards Track [Page 4] RFC 2308 DNS NCACHE March 1998 NXDOMAIN 応答の四つの例の場合、問い合わせた "AN.EXAMPLE." は存在し、 CNAME レコードを保持していることがわかる。NXDOMAIN は "TRIPLE.XX" に 対応することから、この名前が存在しないことがわかる。一方、参照応答の 例では、"AN.EXAMPLE" が存在し、CNAME RR を持つことが示されているが、 "TRIPPLE.XX" が存在するかどうかは不明で、その情報を得たいならば 次の処理段階で "NS1.XX" または "NS2.XX" に問い合わせ可能であること しかわからない。 CNAME レコードがない場合、NXDOMAIN 応答は問い合わせ部のRRのラベルに 含まれる名前に対応する。 2.1.1 - Name Error の特別な処理 本セクションは、NXDOMAIN 応答のネガティブキャッシュを実装する際に 直面するエラーを採り上げる。 現時点で、NXDOMAIN 応答の全形式を正確に判別して処理できないリゾルバーが 多数存在している。あるリゾルバーは、タイプ1の NXDOMAIN 応答を参照応答として 処理する。この問題を軽減するために、NXDOMAIN 応答を生成する権威サーバーは、 タイプ2の NXDOMAIN 応答だけを送信することを推奨する。これは権威部が SOA レコードを保持するが NS レコードを保持しないものである。権威のないサーバー (non-authoritative server)(訳注: フルリゾルバーやフォワーダーなど)がタイプ1の NXDOMAIN 応答を旧い(NXDOMAIN を正しく処理できない)リゾルバーに送信すると、 本来不要な権威サーバーへの問い合わせが発生する。これは望ましい挙動ではないが、 サーバーがフォワーダーとして使用されていないのであれば、致命的な問題には ならない。しかし、問題あるリゾルバーがサーバーをフォワーダーとして使用している 場合、そのようなリゾルバーに対するタイプ1の NXDOMAIN 応答の送信を無効にし、 替わりにタイプ2の NXDOMAIN 応答を送信する必要がある。 あるリゾルバーは、権威付き回答フラグ(AAビット)が設定されていない場合、 問い合わせ再試行の上限しきい値を超えるまで問い合わせを繰り返し、最後に SERVFAIL を返す。そのようなリゾルバーが使用するフォワーダーのリストに 加えられたネームサーバー管理者は問題に直面する。ネームサーバーが 問題あるリゾルバーにフォワーダーとして使用される場合、リゾルバーへの NXDOMAIN 応答には強制的に権威付き回答フラグを設定しなければならない。 実際に、常に権威付き回答フラグを設定しても何も問題は生じないし、 BIND は 4.9.3 以降でこれがデフォルトの振る舞いとなっている。 2.2 - No Data NODATA は、RCODE が NOERROR に設定されており、かつ回答部に関連する情報を 何も保持しないことで提示される。権威部は SOA レコードを保持する。権威部に SOAレコードがない場合は NS レコードも存在しない。 Andrews Standards Track [Page 5] RFC 2308 DNS NCACHE March 1998 NODATA を提示する RCODE 値は存在しないので、NODATA 応答は応答の内容から アルゴリズム的に判定する必要がある。NODATA が正当な応答だったことを 確認するために、更に問い合わせが必要な場合もある。 権威部は、NS、SOA レコードに加えて NXT、SIG RRset を保持する場合がある。 また、CNAME、SIG レコードが回答部に存在する場合もある。 SOA レコードが権威部に存在すること、または NS レコードが権威部に存在しない こと等を手がかりに、NODATA 応答と参照応答を区別することは可能である。 NODATA 応答は、権威部の内容に応じて3タイプに分類することができる。 この3タイプと、比較のために参照応答をあわせて以下に示す。記載のない フィールドは、この例示においては重要でないものである。 NODATA 応答: タイプ1 ヘッダー部: RDCODE=NOERROR 問い合わせ部: ANOTHER.EXAMPLE. A 回答部: <空> 権威部: EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. .... EXAMPLE. NS NS1.XX. EXAMPLE. NS NS2.XX. 付加情報部: NS1.XX. A 127.0.0.2 NS2.XX. A 127.0.0.3 NODATA 応答: タイプ2 ヘッダー部: RDCODE=NOERROR 問い合わせ部: ANOTHER.EXAMPLE. A 回答部: <空> 権威部: EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. .... 付加情報部: Andrews Standards Track [Page 6] RFC 2308 DNS NCACHE March 1998 NODATA 応答: タイプ3 ヘッダー部: RDCODE=NOERROR 問い合わせ部: ANOTHER.EXAMPLE. A 回答部: <空> 権威部: <空> 付加情報部: <空> 参照応答 ヘッダー部: RDCODE=NOERROR 問い合わせ部: ANOTHER.EXAMPLE. A 回答部: <空> 権威部: EXAMPLE. NS NS1.XX. EXAMPLE. NS NS2.XX. 付加情報部: NS1.XX. A 127.0.0.2 NS2.XX. A 127.0.0.3 先に示した NXDOMAIN の例と異なり、これらの例には CNAME が現れない。 しかし、NXDOMAIN の例と同様に回答部が CNAME を保持することがある。 その場合、最後の CNAME の値(QNAME)が NODATA であると判定される。 2.2.1 - No Data の特別な処理 現時点で、NODATA 応答の全形式を正確に判別して処理できないリゾルバーが 多数存在している。あるリゾルバーは、タイプ1の NODATA 応答を参照応答として 処理する。この問題を軽減するために、NODATA 応答を生成する権威サーバーは、 タイプ2の NODATA 応答だけを送信することを推奨する。これは権威部が SOA レコードを保持するが NS レコードを保持しないものである。権威のないサーバー (訳注: フルリゾルバーやフォワーダーなど)がタイプ1の NODATA 応答を問題ある リゾルバーに送信すると、本来不要な権威サーバーへの問い合わせが発生する。 サーバーがリゾルバーからフォワーダーとしてリストに加えられている場合、 権威のない NODATA 応答をする際にも、タイプ1の応答は無効にする必要が あるだろう。 Andrews Standards Track [Page 7] RFC 2308 DNS NCACHE March 1998 幾つかのネームサーバー実装では、回答部に CNAME があると RCODE を NXDOMAIN に 設定できない。確実な NXDOMAIN/NODATA の回答が必要な場合、リゾルバーは QNAME を問い合わせラベルに使用して再度問い合わせを実行しなければならない。 3 - 権威サーバーにおける不在応答の生成 ゾーンの権威を持つネームサーバーは、NXDOMAIN または NODATA を通知する場合、 そのゾーンの SOA レコードを応答の権威部に付加しなければならない(MUST)。 不在応答をキャッシュするためにこの情報が必要とされる。SOA レコードの TTL には、SOA の MINIMUM フィールドの値と、SOA 自身に対して設定された TTL の 最小値が設定され、その値が不在応答をリゾルバーがキャッシュしてよい期間を 提示する。SOA レコードに関連付けられた SIG レコードの TTL は、SOA の TTL に揃うよう短縮されるべきである。 ゾーンが署名付き [RFC2065] の場合、SOA に加えて適切な NXT、SIG レコードも 付加されなければならない(MUST)。 4 - SOA レコードの MINIMUM フィールド SOAレコードの MINIMUM フィールドは、過去に複数の定義がなされた結果、 ゾーン内の全 RR の最小 TTL 値、TTL を持たない RR のデフォルト TTL、 不在応答の TTL という三つの異なる意味を持つ。 三つのうちの一つめ、すなわち本来の定義であるゾーン内の全 RR の最小 TTL 値 という意味で使用されたことは実際には一度もなかったので、ここで廃止とする。 三つのうちの二つめ、マスターゾーンファイル内で明示的に TTL が指定されて いない RR のデフォルト TTL という用法に関係するのはプライマリサーバーだけ である。ゾーン転送後は、全 RR は明示的な TTL を持ち、各 TTL があらかじめ 明示的に指定されていたものか、デフォルト TTL から導出されたものかを 判別することはできない。プライマリサーバーが各 RR に対する明示的な TTL の 指定を要求しない場合、SOA レコードの MINIMUM フィールド値以外の方法で、 未指定の TTL 値を取得できるような仕組みが提供されるべきである。 これを実現する方法は実装依存となっている。 そこで、マスターファイルフォーマット [RFC 1035セクション5]を拡張し、 以下のディレクティブを導入する。 $TTL [コメント] Andrews Standards Track [Page 8] RFC 2308 DNS NCACHE March 1998 上記のディレクティブより後に位置する全リソースレコードのうち、明示的に 指定された TTL 値を持たないものは、$TTL ディレクティブで指定された TTL 値 が設定される。明示的に指定された TTL を持たない SIG レコードの場合、 SIG レコードの "オリジナルTTL" フィールドの値が使用される [RFC 2065セクション4.5]。 残されたもの、不在応答の TTL として使用する値という意味が、新たな SOA の MINIMUM フィールドの定義である。 5 - 不在応答のキャッシュ 通常の応答と同様に、不在応答も TTL を持つ。しかし、TTL を適用するレコードが 回答部に存在しないので、他の方法で TTL を通知しなければならない。これは 応答の権威部にゾーンの SOA レコードを付加することで達成される。権威サーバーが SOA レコードをロードする際に、SOA レコードの TTL には、SOA.MINIMUM フィールド の値と、SOA 自身に対して設定された TTL の最小値が設定される。この TTL は通常の 応答キャッシュと同じようにデクリメントされていく。ゼロ(0)になった不在応答 キャッシュを使用してはならない(MUST NOT)。 NXDOMAIN (Name Error)から生じた不在応答は、同じ の問い合わせ に対し、キャッシュを検索し、キャッシュから不在応答を返せるようにキャッシュ されるべきである。 NODATA(No Data エラー)から生じた不在応答は、同じ の 問い合わせに対し、キャッシュを検索し、キャッシュから不在応答を返せるように キャッシュされるべきである。 受信した不在応答の権威部に NXT レコードが含まれる場合、権威部に SOA レコードと共に付加して応答できるようにキャッシュされなければならない (MUST)。SIG レコードが権威部に含まれる場合、キャッシュすべきである。 NXDOMAIN 応答の場合、NXT レコードとQNAME の間で明確な関係は必要と されない。NODATA 応答の場合、NXT レコードは QNAME と同じ所有者名を 持たなければならない(MUST)。 SOA レコードを含まない不在応答はキャッシュすべきではない(SHOULD NOT)。 たとえサーバー側で設定される TTL が小さくても、サーバーのペア間で不在応答の ループが発生するのを防ぐ方法がないからである。 DNS はサーバーを木構造に関連付けるが、さまざまな設定誤りにより、問い合わせグラフ (query graph)内にループが生じることはあり得る。設定誤りは、例えば2台の サーバーが互いをフォワーダーにしている場合や lame サーバー等が考えられる。 不在応答キャッシュ専用の TTL をカウントダウンできないと、その不在情報を 受信した先のサーバーで TTL がリセットされてしまう。 Andrews Standards Track [Page 9] RFC 2308 DNS NCACHE March 1998 このようにして、専用の TTL を持たない不在応答キャッシュは、関連を持つ 複数のサーバー間を巡回しながら永久に存続する。 プロトコルはキャッシュ有効期間として最大68年をサポートするので、 肯定応答キャッシュと同様に、リゾルバーが不在応答のキャッシュ期間を 制限するのが賢明である。この制限は、肯定応答キャッシュに適用される 期間よりも大きくすべきでなく、また調整可能な方が望ましい。 1時間から3時間といった値はうまく機能することがわかっているので、 これらの値をデフォルトにするのが賢明だろう。一方で、1日を越える値は 問題が多いことがわかっている。 6 - キャッシュを使用した不在応答 サーバーが問い合わせに回答する際にキャッシュを使用した不在応答を行う場合、 応答の権威部に、キャッシュした SOA レコードを付加しなければならない(MUST)。 付加する SOA の TTL は、SOA キャッシュ後経過した時間を TTL から差し引いた値 としなければならない。これにより、NXDOMAIN/NODATA 応答のキャッシュを 適切に廃棄できるようになる。 NXT レコードが SOA レコードとあわせてキャッシュされている場合、NXT レコードも 権威部に付加されなければならない(MUST)。NXT レコードに対応する SIG レコードが キャッシュされている場合、SIG レコードは権威部に付加されるべき(SHOULD) である。 キャッシュを使用した他の全回答と同じように、不在応答は暗黙の参照 (implicit referral)を応答に含めるべき(SHOULD)である。これにより、 リゾルバーは権威ある情報源の位置を特定できる。暗黙の参照とは、権威ある 情報源をリゾルバーに参照させる先として権威部に付加された NS レコード である。NXDOMAIN 応答タイプ1とタイプ4は暗黙の参照を含む。NODATA 応答の タイプ1も同様である。 7 - 他の否定的応答のキャッシュ 不在応答以外の否定的応答のキャッシュについては、既存のどの RFC も扱って いない。これらの応答の TTL として要望する値を通知する方法は存在しない。 問い合わせ転送のループが生じないことを保証するよう注意を払う必要がある。 7.1 - サーバー障害応答のキャッシュ (任意(OPTIONAL)) サーバー障害応答は二つの主要なクラスに分類される。一つめは、ゾーンの権威 サーバーが誤って設定されたと判断した場合に返される。例えば、権威サーバーの リストに加えられているがゾーンの設定がなされていない場合や、ゾーンの 権威サーバーとして設定されているが何らかの理由でゾーンデータが取得 できない場合が考えられる。後者の状況は、ゾーンファイルが存在しないか エラーが含まれているかのどちらかの場合、またはゾーンを取得できるはずの 別サーバーが応答しないかゾーン提供不能かゾーン提供を拒否しているかの いずれかの場合に起こり得る。 Andrews Standards Track [Page 10] RFC 2308 DNS NCACHE March 1998 二つめは、どこか別の場所から回答を得る必要のある場合に、サーバー(訳注: フルリゾルバーやフォワーダーなど)が返すものである。例えば、ネットワーク 障害、回答取得先が応答しない、回答取得先からサーバー障害エラーが返された、 等の理由で回答が得られない場合が考えられる。 どちらの場合でも、リゾルバーはサーバー障害応答をキャッシュしてもよい(MAY)。 キャッシュする場合、5分を越えてキャッシュしてはならない(MUST NOT)。 また、特定の問い合わせタプル <問い合わせ名, タイプ, クラス, サーバーIPアドレス> に対するキャッシュでなければならない(MUST)。 7.2 - サービス不能/到達不能なサーバーのキャッシュ(任意(OPTIONAL)) サービス不能/到達不能なサーバーとは、問い合わせに対して何も応答がないサーバー か、またはトランスポート層よりサーバーが存在しないか到達不能と通知された サーバーを指す。サーバーは、未解決の問い合わせに対して120秒以内に応答 しなかった場合、サービス不能または到達不能と見なされる場合がある。 トランスポート層からの通知は、例えば以下のようなものである。 ・ ホスト、ネット、ポートが到達不能であることを示すICMP エラーメッセージ ・ TCP のリセット ・ 上記のような問題を通知するIPスタックのエラーメッセージ リゾルバーは、サーバーのサービス不能通知をキャッシュしてもよい(MAY)。 キャッシュする場合、5分を越えてキャッシュしてはならない(MUST NOT)。 また、特定の問い合わせタプル <問い合わせ名, タイプ, クラス, サーバーIPアドレス> に対するキャッシュでなければならない(MUST)が、これはトランスポート層から サーバーが存在しないという通知がない場合に限る。サーバーが存在しない通知が あった場合、問題のIPアドレスに対する全問い合わせに対してキャッシュが適用 される。 (※本段落は Errata ID: 461 の内容を反映したものとなっている)。 8 - RFC 1034 からの変更点 リゾルバーにおけるネガティブキャッシュは任意(optional)でなくなる。リゾルバーが 何らかのキャッシュをしている場合、不在応答もキャッシュしなければならない。 権威のない不在応答をキャッシュしてもよい(MAY)。 権威部に付加された SOA レコードはキャッシュされなければならない(MUST)。 NXDOMAIN(Name Error) 不在応答は、<問い合わせ名, QCLASS> タプルに対して キャッシュされなければならない。NODATA(No Data) 不在応答は、 <問い合わせ名, QTYPE, QCLASS> タプルに対してキャッシュされなければならない。 キャッシュした SOA レコードは応答に付加されなければならない。 RFC 1034ではこれを明示的に禁止していた。肯定応答からキャッシュした SOAレコードと不在応答からキャッシュしたSOAレコードを区別する方法がなく、 単純に肯定応答からキャッシュしたSOAを不在応答に付加すると問題を 引き起こしたためである。 Andrews Standards Track [Page 11] RFC 2308 DNS NCACHE March 1998 $TTL TTL ディレクティブがマスターファイルフォーマットに追加された。 9 - ネガティブキャッシュの歴史 本セクションは、DNS におけるネガティブキャッシュの簡単な歴史を提示する。 これはネガティブキャッシュの技術仕様の一部ではない。 CHIVES と BIND の両方で、独立して同じ概念が考案されたのは興味深いこと である。 初期のCHIVESの取り組みの歴史(セクション9.1)は Rob Austein によって提供されたもので、彼が提供したそのままの 形式でここに再掲載する [MPA]。 9.1 - CHIVES (訳注：この行は原文には存在しないが、ないとおかしいので追加) 1985年春のある時期に、私は Paul Mockapetris に対し、彼の JEEVES DNS リゾルバーの運用経験から、ある種のネガティブキャッシュの仕組みの必要性を 認識したことを伝えた。Paulは、問い合わせた RR を含むゾーンの SOA MINIMUM を 使用して、単純に権威付きのエラーをキャッシュすることを提案した。 この会話が RFC 973 執筆前に行われたことは間違いないが、このアイディアが 私の質問に対する答えとして Paul がその場で思いついたものなのか、彼が既に 同様のことを思案していて、それを文書化したものが RFC 973 になったのかは 私には定かでない。いずれにせよ、彼も私も、SOA MINIMUM 値が使用すべき正しい メトリックなのかはわからなかった。しかし、SOA MINIMUM は利用可能な情報で あること、またゾーン管理者の管理下にあることなど、そのどちらもが当時の 我々には重要な特徴であると思えた。 1987年末に、私は CHIVES の初期ベータテストバージョンをリリースした。 これは Paul の JEEVES リゾルバーを置き換えるために私が書いた DNS リゾルバー実装 である。CHIVESには、複数サイト(私のサイトも含む)で多用されていた検索パス (search path) の仕組みと、SOA MINIMUM 値に基づくネガティブキャッシュの 仕組みが盛り込まれていた。基本戦略は、完全に一致する問い合わせパラメーター (QNAME, QCLASS, QTYPE)をキーにして検索可能な形で権威付きエラーコードを キャッシュすること、またキャッシュの TTL を SOA MINIMUM 値と等しい値にする ことであった。SOA RR が権威付き応答で提供されなかった場合、CHIVES はそれを 取得しようとは試みなかった。そのため権威を持たない(gratuitous) DNS エラー メッセージトラフィックは完全に削除できなかったが、それでもエラーメッセージ トラフィック削減に大きく寄与した。これらのことは、指数的な接続組織数増加と "古い" (VJ 前の) TCP 再転送アルゴリズムが原因のふくそうのために ARPANET が 崩壊寸前になっていた時に起きたことに留意してほしい。ネガティブキャッシュは 劇的に良好な DNS 応答時間をユーザー、メーラーデーモン、その他さまざまなものに もたらしたのである。 Andrews Standards Track [Page 12] RFC 2308 DNS NCACHE March 1998 私の知る限り、CHIVES がネガティブキャッシュを実装した最初のリゾルバー だった。CHIVESは、TOPS-20 (訳注: PDP-10 向けの OS)の晩年期に開発された ので、それほど多くのマシン上では稼働しなかった。しかし、CHIVES が稼働 していた一部のマシンは、たとえ運用コストがどれほどかかろうとも、 すぐに稼働停止させてしまうにはあまりにも重要なものだった。そのため、 ユーザーはほとんど居なかったが、CHIVES は非常にハードに運用される傾向に あった。興味深い幾つかの DNS 技術がこの運用経験から誕生した。本文書に 関係があるものとして MAXTTL 設定パラメーターが挙げられる。 JEEVES の運用経験から、途方もなく長い TTL を持つ RR をしばしば受信する ことがわかっていた。(BINDの初期の数バージョンに存在したコードと文書の バグのために、99999999 という TTL 値は長年に渡って広く使用されていた)。 ("受信に寛容であれ"の原則に従う)ロバストなソフトウェアは、そのような TTL を無分別に信用し、多岐にわたるおかしな障害を引き起こすため、この ゴミデータをキャッシュから取り除くためにリゾルバーを頻繁にリブートする 必要があった。そこで、CHIVES には "MAXTTL" という設定パラメーターを持たせた。 これは受信した RR に対して適用される、"妥当な" 最大 TTL を設定するもの である。MAXTTL より大きい TTL を持つ RR を受信した場合、他の設定パラメーター の値に基づき、TTL を MAXTTL まで減じるか、データをキャッシュせず破棄 するかどちらかとなる。 CHIVESのネガティブキャッシュコードのフィールド実験を開始した頃、 SOA MINIMUM の値は、長大な TTL を持つ RR をキャッシュした場合に生じるのと 同じ問題をネガティブキャッシュにも引き起こすほど大きすぎる場合があることが 明らかになった。(これもまた、BINDの初期の数バージョンに存在したバグに起因 する。セカンダリサーバーリブート時にプライマリにコンタクトできない場合、 そのセカンダリはゾーンの情報すべてについて権威付きで否認(不在通知)して しまう)。そこで、ネガティブキャッシュ の TTL を決定する際に、MAXTTL の 検査も行うようにし、実験を継続した。 最も良好に動作したと思われる設定は WSMR-SIMTEL20.ARMY.MIL のもので、 MAXTTL は約 3 日に設定されていた。(同マシンはインターネット上の主要な TOPS-20 マシンの中で最後に稼働停止したものである。従って最後まで 残った CHIVES の主要なユーザーであり、最も長い実験期間が得られた)。 最後の1年間で、SIMTEL20 から開始されたトラフィックの大半はメールに 関連したもので、メールキューのタイムアウトは1週間に設定されていた。 従って、多数の無用な問い合わせでシステムの足を引っ張ること無く、 "スタックした(キューにため込まれた)" メッセージに完全な DNS 名前解決 試行の機会を与えたことになる。(今となっては忘れてしまった理由で) 通常の キャッシュとネガティブキャッシュを分けずに単一の MAXTTL パラメーターだけを 持たせたので、MAXTTL の設定値がネガティブキャッシュコードにどの程度影響を 与えたのかは定かでない。 CHIVES には、ある状況下でネガティブキャッシュを実行する、物議を醸し そうな第 2 の仕組みが組み込まれていた。CHIVES のリゾルバーデーモンは、 今日 "ステルスセカンダリ" と呼ばれる機能を有効にするように、具体的には DNS マスターファイルをロードできるように設定できた。 Andrews Standards Track [Page 13] RFC 2308 DNS NCACHE March 1998 このように設定することで、リゾルバーは頻繁に利用されるゾーンの権威付き 情報に直接アクセスする手段を得られる。CHIVES の検索パスの仕組みは、 この機能を反映したものとなっており、実質的に二つの独立した検索パスが 存在した。一つは先の機能で取得したローカルな権威付きゾーンデータのみを 検索し、もう一つは通常の反復問い合わせを行うものである。この取り組みに より、ユーザーが頻繁に利用する先が予見可能である場合には、ネガティブ キャッシュの必要性が低減した。(例えば、XX.LCS.MIT.EDU のリゾルバーは、 常に LCS.MIT.EDU と AI.MIT.EDU の両ゾーンファイルをロードしておき、 両サフィックスを "local" な検索パスに設定した。これら二つのゾーン間の やりとりのために、各ゾーンに属するホストが大量の DNS トラフィックを 産み出す原因になっていたからである)。CHIVES を稼働させている全サイトが この機能を使用する選択をしていたわけではない。例えば、C.CS.CMU.EDU は、 あらゆる問い合わせに対して "remote" 検索パスを使用するという選択をした。 CMU にはあまりにも多くのサブゾーンが存在したため、それらのゾーンを ローカルに複製することは現実的ではなかったためである。従って、 ここではローカルなトラフィックに対してもネガティブキャッシュに極めて 強く依存していた。 全体的に見て、我々が行ったネガティブキャッシュの基本設計、具体的に、 ゾーン管理者は不在応答をキャッシュする期間を指定し、リゾルバーは設定に より、実際に適用するキャッシュ期間を0からゾーン管理者が指定した値の 範囲内で選択する、というアプローチは極めて妥当なものだったと今でも 考えている。細かい点を挙げれば、今なら異なる設計をしただろうという 箇所も多い (例えば MINIMUM フィールドの定義を増やす代わりに新しい SOA フィールドを使用するだろう)。しかし、10年以上が経過して、改善点を 少なくとも2, 3考えつかないのだとすれば、非常に心配なことである。 9.2 - BIND BIND にネガティブキャッシュを導入する最初の試みではないが、1993年7月に BIND 4.9.2 ALPHA で、ISI の Anant Kumar が実装した、応答の検証(問い合わせ との対応付けは正しいか、キャッシュは必要か等)とネガティブキャッシュ (NCACHE)のコードが提供された。このコードは、ネガティブキャッシュに対して 10分間の TTL を付与し、NXDOMAIN または NOERROR_NODATA が提示された 不在応答のみをキャッシュした。これが本文書前半で述べた NODATA 擬似 RCODE の起源である。 CSIRO の Mark Andrews は、類似した問い合わせに対して利用できるように SOA レコードをキャッシュするコード(RETURNSOA)を追加した。UUnetより、 新しいゾーンを読み込んだ後でも古い回答が返されるという苦情が寄せられ、 1994年4月の BIND 4.9.3-alpha5 でこのオプションは無効になった。事実、 これはゾーンが占めるであろう領域を named が除去する必要があることを 示していた。それを実現する機能は、1994年12月の BIND 4.9.3 BETA11 patch2 で追加された。 RETURNSOA は、1996年8月の BIND 4.9.5-T1A で再びデフォルトで有効となった。 Andrews Standards Track [Page 14] RFC 2308 DNS NCACHE March 1998 10 - 例 以下の例は、ネームサーバー情報以外は空の署名ゾーンに基づくものである。 このゾーンに対し、WWW.XX.EXAMPLE を問い合わせた際の最初の応答と、 10分後に再度問い合わせた応答を示す。注1: 問い合わせ間隔の10分間で、 XX.EXAMPLE の NS レコードは期限切れとなる。注2: SIG レコードの TTL は ゾーンファイル内で明示的に設定されていないので、署名対象 RRset の TTL が適用される。 ゾーンファイル: $TTL 86400 $ORIGIN XX.EXAMPLE. @ IN SOA NS1.XX.EXAMPLE. HOSTMATER.XX.EXAMPLE. ( 1997102000 ; serial 1800 ; refresh (30 mins) 900 ; retry (15 mins) 604800 ; expire (7 days) 1200 ) ; minimum (20 mins) IN SIG SOA ... 1200 IN NXT NS1.XX.EXAMPLE. A NXT SIG SOA NS KEY IN SIG NXT ... XX.EXAMPLE. ... 300 IN NS NS1.XX.EXAMPLE. 300 IN NS NS2.XX.EXAMPLE. IN SIG NS ... XX.EXAMPLE. ... IN KEY 0x4100 1 1 ... IN SIG KEY ... XX.EXAMPLE. ... IN SIG KEY ... EXAMPLE. ... NS1 IN A 10.0.0.1 IN SIG A ... XX.EXAMPLE. ... 1200 IN NXT NS2.XX.EXAMPLE. A NXT SIG IN SIG NXT ... NS2 IN A 10.0.0.2 IN SIG A ... XX.EXAMPLE. ... 1200 IN NXT XX.EXAMPLE. A NXT SIG IN SIG NXT ... XX.EXAMPLE. ... 最初の応答: ヘッダー部: RDCODE=NXDOMAIN, AA=1, QR=1, TC=0 問い合わせ部: WWW.XX.EXAMPLE. IN A 回答部: <空> 権威部: XX.EXAMPLE. 1200 IN SOA NS1.XX.EXAMPLE. ... XX.EXAMPLE. 1200 IN SIG SOA ... XX.EXAMPLE. ... Andrews Standards Track [Page 15] RFC 2308 DNS NCACHE March 1998 NS2.XX.EXAMPLE. 1200 IN NXT XX.EXAMPLE. NXT A NXT SIG NS2.XX.EXAMPLE. 1200 IN SIG NXT ... XX.EXAMPLE. ... XX.EXAMPLE. 86400 IN NS NS1.XX.EXAMPLE. XX.EXAMPLE. 86400 IN NS NS2.XX.EXAMPLE. XX.EXAMPLE. 86400 IN SIG NS ... XX.EXAMPLE. ... 付加情報部: XX.EXAMPLE. 86400 IN KEY 0x4100 1 1 ... XX.EXAMPLE. 86400 IN SIG KEY ... EXAMPLE. ... NS1.XX.EXAMPLE. 86400 IN A 10.0.0.1 NS1.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ... NS2.XX.EXAMPLE. 86400 IN A 10.0.0.2 NS3.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ... 10 分後の応答: ヘッダー部: RDCODE=NXDOMAIN, AA=0, QR=1, TC=0 問い合わせ部: WWW.XX.EXAMPLE. IN A 回答部: <空> 権威部: XX.EXAMPLE. 600 IN SOA NS1.XX.EXAMPLE. ... XX.EXAMPLE. 600 IN SIG SOA ... XX.EXAMPLE. ... NS2.XX.EXAMPLE. 600 IN NXT XX.EXAMPLE. NXT A NXT SIG NS2.XX.EXAMPLE. 600 IN SIG NXT ... XX.EXAMPLE. ... EXAMPLE. 65799 IN NS NS1.YY.EXAMPLE. EXAMPLE. 65799 IN NS NS2.YY.EXAMPLE. EXAMPLE. 65799 IN SIG NS ... XX.EXAMPLE. ... 付加情報部: XX.EXAMPLE. 65800 IN KEY 0x4100 1 1 ... XX.EXAMPLE. 65800 IN SIG KEY ... EXAMPLE. ... NS1.YY.EXAMPLE. 65799 IN A 10.100.0.1 NS1.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ... NS2.YY.EXAMPLE. 65799 IN A 10.100.0.2 NS3.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ... EXAMPLE. 65799 IN KEY 0x4100 1 1 ... EXAMPLE. 65799 IN SIG KEY ... . ... 11 セキュリティに関する考慮点 本文書は、DNS から得たデータを使用する際に、既に存在するセキュリティ上の 脅威以外に、何かしら重要なセキュリティ上の脅威を付加するものではない。 Andrews Standards Track [Page 16] RFC 2308 DNS NCACHE March 1998 ネガティブキャッシュを使用する場合、非常に大きい TTL の NXDOMAIN メッセージを拡散することで、サービス不能攻撃を拡大することができる 可能性がある。ネガティブキャッシュ無しにこれを実現することは、 はるかに困難である。あらかじめ不正な A レコードを拡散しておくことで 似たような効果が得られるかもしれない。それらのサーバーに到達不能に なるので、効果はほぼ同じに見える。しかし、エンドユーザーが行える作業への 影響は同じだが、心理的な影響は異なる。不正な A レコードを使用する攻撃 の場合、ユーザーは "くそっ！ネットワークがまた壊れている" と考え、 翌日再び試すだろう。これに対し、"NXDOMAIN" を使用する攻撃の場合、 "サーバーを稼働停止したようだ。もう何も残っていない" と考え、わざわざ もう一度同じサーバーを試そうとは思わないだろう。 2種類の攻撃で差異が生じる実例を SMTP サーバーで示す。SMTP サーバーは、 次の通り振る舞うようにプログラムされている。NXDOMAIN を使用する攻撃 の場合、メールメッセージは直ちにバウンス(宛先不明で送り返される)されるが、 不正な A レコードを使用する攻撃の場合、メールはキューに入れられ、攻撃が 中断した後に目的地に配送される可能性がある。 攻撃を成功させるためには、不正な NXDOMAIN 通知をSMTPサーバーが参照する ネームサーバー(かキャッシュリゾルバー)に注入しなければならない。これを 実現可能な方法の一つとして、攻撃者の用意したサーバーにネームサーバーが 問い合わせを発行するように CNAME を設定することが考えられる。 この攻撃の抑制を希望するリゾルバーは、問い合わせの応答に含まれる NS データをすべて無視し、最後の CNAME のデータフィールドとして与えられる QNAME を改めて問い合わせてもよい。 TTL の正当性検査を実装することで、この攻撃の効果が低減する。攻撃を成功 させるには、不正データをより頻繁に注入しなければならなくなるからである。 DNSSEC [RFC2065] は、NXT、SIG レコードを使用して、不在応答が正当な ものかを検証できる仕組みを提供する。本文書は、DNSSEC 非対応のサーバーで あっても関連するセキュリティレコードの転送(付加)を推奨することで、 DNSSEC の利用をサポートする。 Acknowledgments I would like to thank Rob Austein for his history of the CHIVES nameserver. The DNSIND working group, in particular Robert Elz for his valuable technical and editorial contributions to this document. Andrews Standards Track [Page 17] RFC 2308 DNS NCACHE March 1998 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. [RFC2065] Eastlake, D., and C. Kaufman, "Domain Name System Security Extensions," RFC 2065, January 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997. [RFC2181] Elz, R., and R. Bush, "Clarifications to the DNS Specification," RFC 2181, July 1997. Author's Address Mark Andrews CSIRO - Mathematical and Information Sciences Locked Bag 17 North Ryde NSW 2113 AUSTRALIA Phone: +61 2 9325 3148 EMail: Mark.Andrews@cmis.csiro.au Andrews Standards Track [Page 18] RFC 2308 DNS NCACHE March 1998 Full Copyright Statement Copyright (C) The Internet Society (1998). 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. Andrews Standards Track [Page 19]