ネットワークワーキンググループ R. Elz Request for Comments: 2181 University of Melbourne 更新(Updates): 1034, 1035, 1123 R. Bush 分類: 標準化過程(Standards Track) RGnet, Inc. 1997年7月 DNS仕様の明確化 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. 1. 要旨 本文書は、ドメイン名システム(DNS)の仕様に関して、これまでに確認された 幾つかの問題点を検討し、判明している仕様の不備に対する改善を提案する。 以下に示す8個の独立した問題を検討する。 + マルチホームサーバーにおけるIPパケットヘッダーのアドレス使用法 + 同じ名前・クラス・タイプを持つレコードセットにおけるTTLの扱い + ゾーンカットの正しい処理 + SOAレコードとその使用法に関する三つの軽微な問題 + TTLの厳密な定義 + TC (切り詰め) ヘッダービットの使用法 + 正式名(authoritative name, canonical name)とは何かに関する問題 + 正当なDNSラベルとは何かに関する問題 はじめの6項目は、正しい振る舞いが不明確になっているので、本文書でこの 是正を試みる。残りの二つは、適切な規定がなされているにもかかわらず、それが 時折無視されているものである。本文書で、既存の仕様の補強に努める。 Elz & Bush Standards Track [Page 1] RFC 2181 Clarifications to the DNS Specification July 1997 目次 1 要旨 ....................................................... 1 2 はじめに ................................................... 2 3 用語 ....................................................... 3 4 サーバーが応答する際に使用する発信元アドレスの選定 ........... 3 5 RRSet ...................................................... 4 6 ゾーンカット ............................................... 8 7 SOA RR ..................................................... 10 8 TTL(Time to Live) .......................................... 10 9 TC (切り詰め)ヘッダービット .................................. 11 10 名前付けの問題 ............................................. 11 11 名前の構文 ................................................. 13 12 セキュリティに関する考慮点 ................................. 14 13 References ................................................. 14 14 Acknowledgements ........................................... 15 15 Authors' Addresses ......................................... 15 2. はじめに 長年の間、DNS仕様 [RFC1034, RFC1035]の幾つかの問題点が指摘されてきた [RFC1123]。本文書は、付加的な幾つかの問題点を扱う。これらの問題点は互いに 独立である。具体的に、マルチホームDNSサーバーが問い合わせに応答する際にどの 発信元アドレスを使用すべきかという問題、同一のラベル・クラス・タイプを持つ DNSレコードにおける異なるTTLの使用に関する問題、正式名とは何か、CNAME レコードとの関連はどうなるかに関する問題、DNS仕様における正当な名前付け とはどのようなものかに関する問題、DNS名の正当な構文とは何かに関する問題 等について扱う。 これらの問題点を回避するためにDNS仕様を明確化したものが本文書である。 また、RFC 1034に記載されたSOAレコードに関する軽微な不明確さを修正した。 同様に、TTL (Time To Live) の定義の不明確な点と、TC ビットの 使用時に混乱が生じる可能性があった点を修正した。 Elz & Bush Standards Track [Page 2] RFC 2181 Clarifications to the DNS Specification July 1997 3. 用語 本文書は、しばしば利用される MUST, SHOULD, MAY やその否定形表現を使用 しない。幾つかのセクションにおいて、仕様が穏当な表現で規定されるので、 これらの規定は任意(optional)であると推察されるかもしれないが、それは 正しくない。特定の用語を使用するかにかかわらず、本文書の中で提言される、 何からの処理が実行されるべきである/実行されなければならない、何らかの 振る舞いは許容される/されない、といった内容は、本仕様の基本的な側面で ある。何らかの振る舞いまたは処理が本当に任意であれば、そのように明確に 規定する。 4. サーバーが応答する際に使用する発信元アドレスの選定 すべてではないにせよ、大半のDNSクライアントは、問い合わせを送信したアドレスと 同じアドレスから応答を受信することを期待する。これは、単純なリゾルバー クライアントだけではなく、クライアントに再帰的な名前解決を提供するサーバーに おいても同様である。発信元アドレスは、応答に含まれるIDとあわせて、応答の あいまいさを排除し、偽造された応答をフィルタするために使用される。DNSが設計 された際に意図されたものであるかは不明だが、これは紛れもない事実である。 DNSサーバーを稼働している一部のマルチホームホストでは、クライアントの 問い合わせパケットの送信先アドレスとは異なる発信元アドレスで応答が生成 される。このような応答は、クライアントがオリジナルの問い合わせを送信した ホストと受信した応答の発信元アドレスが異なるため、クライアント側で 破棄される。つまり、クライアントからは勝手に送りつけられた応答に見えて しまう。 4.1. UDPの発信元アドレス選定 この問題を回避するため、サーバーがUDPを使用した問い合わせに応答する場合、 問い合わせを配送したIPパケットのIPヘッダーの送信先アドレスフィールドに設定 されたアドレスを、応答を配送するIPパケットのIPヘッダーの発信元アドレスに 設定しなければならない。この処理を経て設定されたIPアドレスで応答を送信する ことが許容されない場合、当該応答はサーバーに割り当てられた他の許容される アドレスで送信してもよい。そのアドレスは、クライアントが以後の問い合わせで 使用できる可能性が最も高いアドレスを選択すべきである。サーバーに設定された すべてのアドレスが、あらゆるクライアントから等しく到達可能ではない状況に おいては、エニーキャストアドレス・マルチキャストアドレスまたは同様の アドレスに対して送信された問い合わせへの応答には特別な配慮を必要とする。 Elz & Bush Standards Track [Page 3] RFC 2181 Clarifications to the DNS Specification July 1997 4.2. ポート番号の選定 すべての問い合わせについて、応答は問い合わせの発信元ポートに送られなければ ならない。問い合わせをTCP経由で受信した場合、応答はトランスポートプロトコル 固有の規定に従う。問い合わせをUDP経由で受信した場合、サーバーは発信元ポートに 注意し、応答の送信先ポートに同じ番号を設定しなければならない。応答は、 常に指定されたポートから送信されるべきである。特別な状況を除き、この ポートはDNS問い合わせに割り当てられたウェルノウンポート [RFC1700] となる。 5. RRSet DNSリソースレコード(RR)は、それぞれラベル・クラス・タイプ・データを 保持する。二つのレコードが同一のラベル・クラス・タイプ・データを持つのは 無意味で、そのような重複を発見した場合、サーバーはこれを削除すべきである。 しかし、ほとんどのレコードタイプにおいて、ラベル・クラス・タイプが同一で データが異なるものが存在できる。ここで、そのようなレコードのグループを RRSet (Resource Record Set) と定義する。 5.1. RRSetに属するRRの送信 特定の(あるいは不特定の)ラベル・クラス・タイプを指定した問い合わせに 対しては、常に関連するRRSetに属するすべてのレコード、一つ以上のRRが 返される。全RRSetが応答に取り入れられない場合、"切り詰め(truncate)"と マークされなければならない。 5.2. RRSetに属するRRのTTL また、リソースレコードはTTLを持つ。RRSetに属する個々のRRが異なるTTLを持つ ことは可能である。これについて、別の方法では成し遂げることができないような 利用方法は見つかっていない。異なるTTLを使用すると、RRSetに属する一部のRRの TTLだけが終了した場合、キャッシュサーバーからの応答が "切り詰め" とマーク されていないにもかかわらず、実際には部分的な応答になってしまうことがある。 以上より、RRSetにおける異なるTTLの使用を非推奨とする。RRSetに属するすべての RRは同じTTLでなければならない。 RRSetに属するRRが異なるTTLを持つ応答をクライアントが受信した場合、エラーと して処理すべきである。当該RRSetが権威を持たない情報源から取得したもので ある場合、クライアントは単にRRSetを無視すべきである。その情報が必要 ならば、権威を持つ情報源からの取得を試みるべきである。すべての問い合わせを 一つ以上の特定のサーバーに送信するように設定されたクライアントは、 この目的の場合には、これらのサーバーを権威を持つ情報源と扱うべきである。 Elz & Bush Standards Track [Page 4] RFC 2181 Clarifications to the DNS Specification July 1997 権威サーバーが異なるTTLを持つ不正なRRSetを送信する場合、クライアントは、 RRSetに属するすべてのRRのTTLに、RRSet内のTTL最小値が設定されているものとして 処理すべきである。いかなる場合も、サーバーが異なるTTLを持つRRSetを送信しては ならない。 5.3. DNSSEC関連の特別な処理 DNSSEC [RFC2065] で追加された二つのレコードタイプは、RRSetの構成を考える際に 特別な注意を必要とする。二つのレコードとはSIGとNXTレコードを指す。DNSSECは 依然として新しく、今のところわずかな経験しか得られていないことに注意すべき である。読者は、DNSSEC仕様が成熟した際に、本文書に記載されたDNSSEC関連の 情報が時代遅れになる事について心づもりをしておくべきである。 5.3.1. SIGレコードとRRSet SIGレコードは、DNSにおけるSIG以外のRRSetの署名(検証)データを提供する。 ゾーンが署名付きである場合、ゾーン内の全RRSetは関連するSIGレコードを持つ。 RRSetのデータタイプは、SIG RRのデータに含まれる。これにより、そのSIG レコードが関連づけられた特定のRRSetを提示する。このルールを適用すると、 応答を検証するためにSIGレコードを付加する場合、該当するノードに関連する 他の全RRSetに関するSIGレコードを付加する必要が生じる。場合によっては、 この結果レコード数が膨大になるかもしれない。SIG RRのサイズが幾分大きい ことも追い討ちをかける。 そこで、権威部(authority section)においては、返される回答のタイプフィールド と同じ"署名対象(type covered)"フィールドを持つSIG RRだけを付加することを 特別に許容することにする。ただし、SIGレコードへの問い合わせや、名前に関連する 全レコードへの問い合わせ(type=ANY)に対する応答として回答部(answer section)に SIGレコードが存在する場合、他のレコードタイプに対してと同様に、SIG RRSet すべてを付加しなければならない。 権威部または(恐らくは誤って)付加情報部(additional data section)にSIG レコードを含む応答を受信したサーバーは、ほぼ間違いなく全RRSetは含まれて いないと判断しなければならない。従って、サーバーは、SIGレコードへの 問い合わせへの回答で使えるように、それらのSIGレコードをキャッシュしては ならない。RFC 2065は、ここに述べた問題を回避するために、SIGへの 問い合わせは権威サーバーに送るように実質的に要求している。SIGレコードの 特別な性質を理解しないサーバーが存在する間、この規定は必要だろう。しかし、 新しい実装におけるSIGレコード処理の注意深い設計においては、この制約は 今後緩和されるべきであるから、リゾルバーがSIGレコードへの問い合わせに対して 特別な処理をする必要はなくなる。 Elz & Bush Standards Track [Page 5] RFC 2181 Clarifications to the DNS Specification July 1997 これまでに、SIGレコードへの問い合わせを受信した場合、キャッシュのデータから 回答せずに、権威サーバーに転送すべきだとの記述がなされてきたが、必ずしも その必要はない。SIGが特別な処理を要することをサーバーが認識しているので あれば、SIGの特性を考慮して適切にSIGレコードをキャッシュするほうが賢明 である。その場合サーバーは、キャッシュから応答しても安全かどうか、もしくは 応答は利用できず問い合わせが転送されるべきか、について判断できる。 5.3.2. NXT RR NXT(Next) リソースレコードは、更に特殊である。ゾーン内で、特定のラベルに 対するNXTレコードは一つしか存在しないので、RRSetの問題は意味がない。 しかし、ゾーンカットにおいては、親ゾーンと子ゾーン(RFC 2065の用語では スーパーゾーンとサブゾーン)の両方で、同じ名前に対するNXTレコードが存在 する。この二つのNXTレコードは、たとえ両ゾーンが同じサーバー上に存在する場合に おいてもRRSetを形成しない。NXT RRSetは常に単一のRRだけを保持する。 両方のNXTレコードが利用できる場合、二つのRRSetが存在することになる。 しかし、サーバーが応答でNXTレコードを受信した場合、これを特別な場合として 処理する必要はない。サーバーは、二つの異なるNXT RRSetが存在することに気づいた 場合、他のタイプにおける二つの異なるRRSetと同様に見なして処理してよい。 つまり、片方をキャッシュしてもう片方を無視するということである。ただし、 DNSSEC対応(security aware)サーバーは、受信した応答に含まれるNXTレコードを 適切に処理する必要があるだろう。 5.4. RRSetの受信 サーバーは、応答に含まれるRRとキャッシュを混合してRRSetを形成してはならない。 サーバーが保持するキャッシュと組み合わせてRRSetを形成できるデータが応答に 含まれる場合、サーバーは、必要に応じて応答に含まれるRRを無視するか、 キャッシュに含まれるRRSet全体を破棄するか、どちらかを選択しなければ ならない。従って、キャッシュと応答とでTTLが異なるという懸念は生じない。 片方は無視されるからである。つまり、応答に含まれるデータとキャッシュに 含まれるデータが異なるのであれば、どちらかのデータセットが必ず誤っている。 サーバーの課題は、どちらのデータセットが正しいかを判断し、正しい方を残し、 そうでないものを無視することである。サーバーが受信した回答に含まれるRRSetと キャッシュが同一だがTTLだけが異なる場合、任意で(optional)キャッシュのTTLを 受信した回答の値に更新してもよいことに注意。受信した回答がキャッシュした 回答よりも権威あるものと見なせる場合(次セクションで議論する)、この処理を 行うべきである。 Elz & Bush Standards Track [Page 6] RFC 2181 Clarifications to the DNS Specification July 1997 5.4.1. データ出自の信頼性順位 応答に含まれるRRSetについて、キャッシュ済みのRRSetを残すか受理する (置き換える)かを検討する場合、サーバーは各データの相対的な信頼性を考慮 すべきである。応答に含まれるものが権威付き回答(authoritative answer)で、 キャッシュデータが付加情報部から取得したものであるならば、キャッシュを 置き換えるべきである。一方で、キャッシュが権威付き回答またはゾーン ファイルから得たデータである場合、応答に含まれる付加情報部のデータは 無視される。 利用可能なデータの正確性は、その出自から推定される。 信頼性の高いものから低いものへの順位付けは以下の通りとする。 + プライマリゾーンファイルから得たデータ(グルーデータは除く) + ゾーン転送で得たデータ(グルーデータは除く) + 権威付き応答の回答部に含まれる権威付きデータ + 権威付き応答の権威部に含まれるデータ + プライマリゾーンファイルまたはゾーン転送で得たグルーデータ + 権威無し応答の回答部に含まれるデータ、権威付き応答の回答部に含まれる 権威無しデータ + 権威付き応答に含まれる付加情報部、権威無し応答の権威部に含まれるデータ、 権威無し応答に含まれる付加情報部 通常、権威付き応答の回答部には権威付きデータのみが含まれることに注意。 しかし、問い合わせた名前が別名(alias)の場合(セクション10.1.1参照)、 それが別名だと記載するレコードだけが権威付きとなる。クライアントは、 他のレコードはサーバーのキャッシュから来た可能性を想定すべきである。 権威付き回答が必要な場合、クライアントは別名に対して設定された正式名を 使用して再度問い合わせをすべきである。 上記順位付けで信頼性が最も低いグループから取得しキャッシュした、出自が 未検証のRR、具体的に付加情報部のデータや権威無し応答の権威部に含まれる データといったものは、問い合わせへの回答に使用する目的でキャッシュすべきでは ない。これらの情報は、必要に応じて応答の付加情報部に付加することはできる。 不必要に行うと、相対的に信頼性の低いデータの信頼性を、目的や理由もなく 向上させることになる。 DNSSEC [RFC2065] を使用していて、署名付き応答を受信し署名検証を行った場合、 署名検証済みデータは同じタイプの未検証データよりも信頼性が高いものとする。 本文書全体を通して、"権威付き(authoritative)"とはAAビットが設定されている ものを意味することに注意。 Elz & Bush Standards Track [Page 7] RFC 2181 Clarifications to the DNS Specification July 1997 DNSSECでは、データの信頼性を判定するために、SIGとKEYレコードで構成された 信頼の連鎖を使用するので、AAビットはほとんど意味がない。しかし、DNSSEC対応 サーバーは、DNSSEC非対応(現時点でほぼすべて)のサーバーが適切に処理できるよう、 依然として応答にAAビットを正しく設定しなければならない。 二つの正しく設定されたプライマリゾーンファイルや、二つの正しく設定された セカンダリゾーン(ゾーン転送で得たデータ)、正しく設定されたプライマリ とセカンダリのゾーンからそれぞれデータを得た場合、そこに不整合が 生じることはあり得ない。ただしグルーは例外であることに注意。 複数のゾーンに同じ名前のグルーが存在する状況で、レコードの保持する値が 異なる場合、ネームサーバーはプライマリゾーンファイルから得たデータを セカンダリから得たデータに優先して選択すべきである。プライマリゾーン ファイルから得ていない場合はどのデータを選択してもよい。権威付き情報源に より近い出自から来たと思われるデータを選択するのが妥当な判断であろう。 プライマリのデータをセカンダリのデータに優先することで、誤ったグルー データが存在する場合、その情報源を容易に発見できるようになる。 二つのゾーンファイルのうち一つ以上が誤って設定され、不整合が生じる 状況では、不整合が判明したゾーンはロードを拒否し、適切な診断を実施すべき である。 先のセクションの"グルー"は、ゾーンファイル内に存在するが、そのゾーンの 一部ではないすべてのレコードが含まれる。具体的に、サブゾーン委任時のネーム サーバー(NS)レコード、当該NSレコードに付随するアドレスレコード(A, AAAAなど)、 他に存在し得る、ゾーンに属さないあらゆるデータである。 5.5. RRSetの送信 (繰り返しの扱い) RRSetはDNS応答の中に一つだけ付加されるべきである。RRSetは、必要に応じて 回答部や権威部、または付加情報部に現れる。しかし、仕様で明示的に要求 されない限り、同一または別の部分でRRSetが繰り返されるべきではない。 例えば、AXFR応答は、SOAレコード(常に単一のRRを含むRRSet) を応答の最初と 最後に付加することを要求している。このように重複が要求される場合、転送 されるどちらのレコードのTTLも同じでなければならない。 6. ゾーンカット DNS木構造は"ゾーン"に分割される。ゾーンはドメインの集合体で、特定の管理 目的に従う単位として扱われる。ゾーンは"ゾーンカット"で区切られる。 各ゾーンカットは"子"ゾーン(カットの下側)と"親"ゾーン(カットの上側)を 分離する。ゾーンの先頭(ゾーンを親から分離するゾーンカットの直下)に現れる ドメイン名をゾーンの"起点(origin)"と呼ぶ。ゾーン名はゾーンの起点の ドメイン名と同じである。各ゾーンは、ゾーンの起点以下で、かつ(存在するなら) 子ゾーンを分離するカットの上に位置するDNS木構造のサブセットで構成される。 Elz & Bush Standards Track [Page 8] RFC 2181 Clarifications to the DNS Specification July 1997 ゾーンカットの存在は、子ゾーンの起点を指定するNSレコードの存在によって、 親ゾーンに示される。子ゾーンは親ゾーンへの明示的な参照を持たない。 6.1. ゾーンの権威 ゾーンの権威サーバーは、ゾーンの起点に対するNSレコードで列挙される。 SOA(Start of Authority)レコードと同様に、各ゾーンで必須のレコードである。 権威サーバーは、ゾーンに含まれるレコードのうち、他ゾーンに属すものを 除く全レコードについて権威を持つ。ゾーンカットを示すNSレコードは、 生成される子ゾーンの起点またはそのサブドメインに位置する他のレコード同様に、 子ゾーンに属するものである。ゾーンの権威サーバーは、他ゾーンに属する名前への 問い合わせに対して、ゾーンカットに位置するNS及び場合によってはAレコードを 含み、かつ権威付きの応答を返すべきではない。ただし権威サーバーが たまたま問い合わされた他ゾーンの権威サーバーでもある場合は例外である。 この直後のセクションで記載するDNSSECの案件を除き、権威サーバーは、ゾーンに 含まれるゾーンカットにあるデータは、NSレコードとNSレコードで指定された サーバーの特定に必要なAレコードを除き、それを無視すべきである。 6.2. DNSSEC関連の処理 DNSSEC の仕組み[RFC2065]は、ゾーンカットの処理を若干複雑にする。新たに 導入されたリソースレコードは、従来のDNS RRと比べて特殊だからである。 特に、NXT RRタイプはどの名前がゾーン内に存在するか、従ってどの名前 が存在しないか、という情報を含むので、そのNXTレコードが存在するゾーンに 必然的に関連付けられる。親ゾーンと子ゾーンで、同じドメイン名が異なる NXTレコードを持つ場合があり、どちらも有効で、しかもそれらはRRSetを 形成しない。セクション5.3.2参照のこと。 NXTレコードは、DNSオペレーターが手動で設定するのではなく、自動生成される ことが意図されているので、サーバーは、セクション5.4のルールにかかわらず、 異なるすべてのNXTレコードを保持してもよい(保持するよう要求はされない)。 署名付(secure)な親ゾーンが、サブゾーンは未署名(insecure)であると署名付きで 明示したい場合、DNSSECはサブゾーンが未署名であることを示すKEY RRと、 親ゾーンで生成された、KEYに対応するSIG RRが親ゾーン側に存在することを 要求している。定義により、それらのデータを子ゾーン側に配置できないから である。サブゾーンも署名付である場合、KEY及びSIGレコードはサブゾーン側に 存在し、サブゾーン側が権威を持つ。ただし(親ゾーンが署名付ならば)親ゾーン側 にも存在すべきである。 Elz & Bush Standards Track [Page 9] RFC 2181 Clarifications to the DNS Specification July 1997 これらのいずれの場合であっても、親ゾーンの権威サーバーは、サブゾーンの 権威サーバーでない限り、ゾーンカットに位置するラベルに対する任意の応答に AAビットを設定できないことに注意。 7. SOA RR SOA(Start of Zone of Authority)レコードに関する三つの軽微な問題は、 仕様の明確化を必要とする。 7.1. 権威付き応答におけるSOA RRの位置 RFC 1034のセクション3.7で、権威付き応答の権威部が回答を得たゾーンの SOAレコードを含む場合があると記されている。一方で、RFC 1034の セクション4.3.4でネガティブキャッシュを議論する際に、応答にSOAを付加する この手法が参照されているが、そこでは応答の付加情報部に付加すると記述されて いる。RFC 1034のセクション6.2.5で示される例で示されるように、 前者が正しい。SOAが応答に追加される場合、権威セクションに配置される。 7.2. SOAのTTL リソースレコードのフォーマットを定義しているRFC 1035のセクション3.2.1を 見るとわかるが、TTLフィールドの定義部分で、SOAレコードのTTLはキャッシュを 防ぐため常に0で送信されるべきだ、とさりげなく記述されている。この記述は 他のどこにも無く、大抵の場合この実装はなされていない。実装者は、SOA レコードのTTLが0であると想定すべきではなく、またTTLを0に設定してSOAを送信 することも要求されない。 7.3. SOA.MNAME フィールド 仕様では、SOAレコードのMNAMEフィールドに、SOAが特定するゾーンのプライマリ (マスター)サーバー名を設定すべきだと明確に規定しているが、これまで 広く無視されているように思われる。MNAMEにゾーン名を設定すべきではない。 その情報は検索時に無意味である。ゾーン名を検索するにはSOAレコードの ドメイン名から始める必要があるが、それがゾーン名そのものである。 8. TTL(Time to Live) STD 13に記述されたTTLフィールドの適正値の定義は、有効ビット何桁か、 符号付き(signed)か符号なし(unsigned)か等が不明確である。 ここで、TTL値は、最小値0、最大値2147483647の符号なし整数であると 規定する。最大値は2^31-1となる。転送時には、この値は32ビットのTTL フィールドのうち下位31ビットにエンコードされ、最上位ビットまたは符号 ビットは0に設定されるものとする。 Elz & Bush Standards Track [Page 10] RFC 2181 Clarifications to the DNS Specification July 1997 実装は、受信したTTLの最上位ビットが設定されている場合、受信したTTLは 0であったものとして処理すべきである。 実装は、受信したTTLの上限をいつでも自由に設定でき、上限を越える値は上限値 として処理してもよい。TTL値はキャッシュ有効期間の最大値を指定するもので あり、キャッシュ維持を強制される期間ではない。 9. TC (切り詰め)ヘッダービット TCビットは、応答の一部にRRSetを付加するように要求されたが、すべてを付加でき なかった場合にだけ応答に設定されるべきものである。何か他の情報を応答に 付加しようとしたが充分な容量が無かったというだけの理由でTCビットを設定 すべきではない。これは付加情報部の処理の結果、容量が不足した場合も含む。 そのような場合、応答にすべてが入らないRRSetを除外し、そのままTCビットを クリアして応答を送信すべきである。応答受信者が除外されたデータを必要と する場合、そのデータに対する問い合わせを生成し、別途送信することができる。 TCが設定される状況では、すべてが入りきらなかったRRSetの一部は応答に 取り残されている場合がある。TCの設定された応答をDNSクライアントが受信 した場合、その応答は無視し、TCPコネクションのような、より大きな応答を 許容する仕組みで再度問い合わせすべきである。 10. 名前付けの問題 これまでに、DNS仕様[RFC1034, RFC1035]の幾つかのセクションから、ホストや、 恐らくはホストのインターフェースに対して、一つの正式名(canonical name) と呼ばれる権威あるもしくは公式な名前しか許容されないと推察されることが 時折あった。しかしDNSにそのような要件は存在しない。 10.1. CNAMEリソースレコード DNS CNAME("canonical name(正式名)")レコードは、別名に関連づけられた 正式名を提供するために存在する。一つの別名に対する正式名は一つしか存在 しない。正式名は、一般にDNS空間のどこかに既に存在している名前にすべき である。ただしDNS未定義の正式名を対応づけた別名を使用するアプリケーションも わずかに存在する。DNSSECを使用する場合、別名(CNAMEレコードのラベル)は SIG、NXT、KEY RRを保持するが、他のデータは持たない。従って、DNS内の 任意のラベル(任意のドメイン名)について、以下のうち一つだけが真になる。 Elz & Bush Standards Track [Page 11] RFC 2181 Clarifications to the DNS Specification July 1997 + CNAMEレコード一つが存在する。SIG, NXT, KEY RRが付随する場合もある。 + 一つ以上のレコードが存在するが、CNAMEレコードは存在しない。 + 名前は存在するが、どのタイプのRRも関連づけられていない。 + 名前自体が存在しない。 10.1.1. CNAMEに関連する用語 従来、CNAMEレコードのラベルを"CNAME"と称してきた。これは不幸なこと である。"CNAME"は"canonical name(正式名)" の略称なのだが、CNAME レコードのラベルは間違いなく正式名ではない。しかし、そのような用語の 使用法は既に定着している。従って、CNAMEリソースレコードがラベル または値のどちらを意味するのかを明確にするよう注意が必要である。 本文書において、CNAMEリソースレコードのラベルは別名(alias)を意味する。 10.2. PTRレコード 正式名に関する混乱は、RRSet内でPTRレコードを一つしか持つべきではないとの 迷信を産み出した。これは誤りである。RFC 1034の関連セクション(セクション 3.6.2)で、PTRレコードの値は正式名にすべきだと提示されている。これは単に、 別名にすべきでないと言っているだけである。当該セクション内に、一つの名前に 対してPTRレコードは一つしか許容されないとの意味づけは存在しない。そのような 制約を推察すべきではない。 PTRレコードの値が別名であってはならないが、PTRレコードの名前解決処理の 過程で別名が現れないという要件は存在しないことに注意。データを検索しようと しているPTRのラベルはCNAMEレコードを持っているかもしれない。つまり別名かも しれないということである。CNAME RRの値が別に設定された別名でなければ (そうあるべきだが)、検索すべきPTRレコードの所在が得られる。その情報に 基づいてPTRタイプの検索(lookup)を行うことで結果が得られる。最終的に 得られた結果、つまりPTR RRの値は、別名であってはならないラベルである。 10.3. MXレコード・NSレコード NSリソースレコードやMXリソースレコードの値として使用されるドメイン名は、 別名であってはならない。仕様でこの点が明記されているだけではなく、これらの レコードのどちらかで別名を使用すると、期待通りに動作しない可能性や、 このアプローチをとることにした意図を満たさない可能性がある。これらの ドメイン名は、一つ以上のアドレスレコードを保持しなければならない。現在、 アドレスを保持するレコードはAレコードだが、将来アドレス情報を保持する 別のレコードタイプも容認されるかもしれない。また、別のRRも保持できる ようになるかもしれないが、それがCNAME RRであってはならない。 Elz & Bush Standards Track [Page 12] RFC 2181 Clarifications to the DNS Specification July 1997 NSまたはMXレコードのどちらかの検索処理を行うと、検索レコードの値に 関連づけられたアドレスレコードを回答に付加する"付加情報部処理"が生じる。 これにより、初めの問い合わせを行う際に容易に想像できる不要な追加問い合わせを 回避している。 付加情報部の処理では、CNAMEは付加されない。ここには、別名から得られた 正式名のアドレスレコードだけが付加される。従って、NSやMXレコードで 別名が使用されると、NSまたはMXの値と一緒にアドレスを応答できなくなる。 その結果余分な問い合わせが生じるので、問い合わせごとに余分なネットワーク負荷 が生じる。この問題を回避するために、DNS管理者がシステムを導入または更新 する際に、影響を受けるレコードに設定された別名を名前解決して、直接正式名に 置き換える作業を一度だけ実行するのは大した手間ではない。特定の厄介な条件下 では、NSレコードの検索結果の付加情報部にアドレスレコードがない場合、 問い合わせが失敗する。 11. 名前の構文 ドメイン名システム(DNS)は、ホスト名からデータ、インターネットアドレスから ホスト名への変換だけを提供すると想定されることがある。これは正しくない。 DNSは(若干の制約はあるが)汎用の階層型データベースであり、任意の目的に対する あらゆる種類のデータを保存できる。 DNSそれ自体には、リソースレコードを特定するために使用するラベルの制約は 一つしか存在しない。その制約は、ラベル及び完全名(full name)の長さに 関するものである。単一ラベルの長さは、1～63オクテットに制限される。FQDNの 長さは、(セパレータを含めて)255オクテットに制限される。長さ0のFQDNは DNS木構造のルートを表現すると定義し、通常 "." と表記・表示される。 これらの制約に外れない限り、どんなバイナリ文字列も任意のリソースレコードの ラベルで使用できる。同様に、ドメイン名を値として保持する任意のレコード (SOA、NS、MX、PTR、CNAME、他も追加されるかもしれない)で、一部またはすべてが バイナリ文字列で構成されたものを値として提供できる。DNSプロトコルの実装では、 使用されるラベルに関して一切の制限を課してはならない。特に、 DNSサーバーは、一部のDNSクライアントプログラムが受理できない可能性がある ラベルを含むからという理由で、ゾーン情報の提供を拒否してはならない。 DNSサーバーは、問題があると思われるラベルを含むプライマリゾーンをロードする 場合に警告を発行したり、ロードを拒否したりするように設定できてもよいが、 その設定をデフォルトにすべきではない。 しかし、DNSデータを使用する多様なアプリケーションは、各環境に応じて特定の 値しか許容しないという制限を設定できることに注意。例えば、バイナリラベルに 対してMXレコードを設定できるからといって、E-Mailアドレスのホスト部に バイナリ名が使用できるわけではない。 Elz & Bush Standards Track [Page 13] RFC 2181 Clarifications to the DNS Specification July 1997 DNSクライアントは、DNS検索で使用する値や、DNSから返される値について、 クライアントの状況に適した何らかの制約を課すことができる。 クライアントがそのような制約を課す場合、DNSから返されたデータを使用する 前に、データが制約に準拠した適正なものであることを保証する責任は クライアントにある。 [RFC1123] のセクション6.1.3.5も参照のこと。 12. セキュリティに関する考慮点 本文書はセキュリティに関して考慮しない。 特に、セクション4はセキュリティ関連の目的に全く合致せず、また有用でもない。 同様にセクション5.4.1もセキュリティに無関係である。DNSデータのセキュリティは DNSSEC[RFC2065]で達成されるが、本文書とはほぼ直交的関係にある。 本文書の何らかの記述が既存のDNSにセキュリティ問題を追加したり、問題を軽減 したりするとは考えられない。本文書で明確化された仕様に準拠して正しく実装 することで、悪意はなくとも不正(bad)なデータが広がるのを限定することに 少しだけ寄与できるかもしれない。しかし、意図的にDNSデータを破壊する試みを 防ぐ役割を果たせるのはDNSSECだけである。 13. 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. [RFC1123] Braden, R., "Requirements for Internet Hosts - application and support", STD 3, RFC 1123, January 1989. [RFC1700] Reynolds, J., Postel, J., "Assigned Numbers", STD 2, RFC 1700, October 1994. [RFC2065] Eastlake, D., Kaufman, C., "Domain Name System Security Extensions", RFC 2065, January 1997. Elz & Bush Standards Track [Page 14] RFC 2181 Clarifications to the DNS Specification July 1997 14. Acknowledgements This memo arose from discussions in the DNSIND working group of the IETF in 1995 and 1996, the members of that working group are largely responsible for the ideas captured herein. Particular thanks to Donald E. Eastlake, 3rd, and Olafur Gudmundsson, for help with the DNSSEC issues in this document, and to John Gilmore for pointing out where the clarifications were not necessarily clarifying. Bob Halley suggested clarifying the placement of SOA records in authoritative answers, and provided the references. Michael Patton, as usual, and Mark Andrews, Alan Barrett and Stan Barber provided much assistance with many details. Josh Littlefield helped make sure that the clarifications didn't cause problems in some irritating corner cases. 15. Authors' Addresses Robert Elz Computer Science University of Melbourne Parkville, Victoria, 3052 Australia. EMail: kre@munnari.OZ.AU Randy Bush RGnet, Inc. 5147 Crystal Springs Drive NE Bainbridge Island, Washington, 98110 United States. EMail: randy@psg.com Elz & Bush Standards Track [Page 15]