RFC 8499により廃止（Obsoleted by: 8499） Internet Engineering Task Force (IETF) P. Hoffman RFC: 7719 ICANN 分類: 情報提供(Informational) A. Sullivan ISSN: 2070-1721 Dyn K. Fujiwara JPRS 2015年12月 DNSの用語 要旨 DNSは、文字通り何十もの異なるRFCで定義されている。DNSプロトコルの 実装者と開発者、及びDNSシステムの運用者によって使用される用語は、 DNSが最初に定義されて以来数十年の間に時々変化してきた。本文書は、 DNSで使用されている多数の用語の定義を単一の文書で与えるものである。 Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7719. Hoffman, et al. Informational [Page 1] RFC 7719 DNS Terminology December 2015 Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 名前 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. DNSヘッダー及び応答コード . . . . . . . . . . . . . . . . . 6 4. リソースレコード . . . . . . . . . . . . . . . . . . . . . . 7 5. DNSサーバー及びDNSクライアント . . . . . . . . . . . . . . 9 6. ゾーン . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. 登録モデル . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. DNSSEC全般 . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. DNSSECの状態 . . . . . . . . . . . . . . . . . . . . . . . . 20 10. セキュリティに関する考慮点 . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . 22 11.2. Informative References . . . . . . . . . . . . . . . . . 24 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 1. はじめに ドメイン名システム(DNS)は、シンプルな問い合わせ-応答プロトコルで、 そのメッセージフォーマットは問い合わせ、応答の両方向で同じである。 プロトコルとメッセージフォーマットは、[RFC1034]と[RFC1035]で定義 されている。これらのRFCは幾つかの用語を定義したが、後の文書で他の 用語が定義された。RFC 1034とRFC 1035に由来する用語の幾つかは、 現在、1987年の頃とは幾分異なる意味を持つようになっている。 本文書は、さまざまなDNS関連の用語を収集している。以前に発行されたRFCの 中で厳密に定義されているものもあれば、緩やかにしか定義されていない ものもある。以前に発行されたどのRFCでも全く定義されていない用語も 存在する。 Hoffman, et al. Informational [Page 2] RFC 7719 DNS Terminology December 2015 本文書記載の定義の大部分は、プロトコル開発者と運用者の両方を含む DNSコミュニティで合意された定義である。幾つかの定義は以前に発行された RFCのものとは異なっており、その場合、その違いが注記されている。本文書 では、合意された定義がRFCのものと同じである場合、そのRFCが引用される。 合意された定義がRFCのものから多少変化している場合、そのRFCは言及される が、新しい独立した定義が与えられる。 本文書の作成中に、幾つかのDNS関連の用語は、複数のDNSの専門家らによって 全く異なって解釈されていると判明したことには特に留意すべきである。 更に、以前に発行されたDNS RFCで定義された用語の幾つかは、現在一般に 合意された定義は存在するものの、それはオリジナルの定義とは異なっている。 従って、著者らは、そう遠くない将来において、大幅な改訂をすることで 本文書を継続的に支援するつもりである。その改訂販には、恐らく幾つかの 用語や新しい用語に関するより詳細な議論を載せることになるだろう。また 幾つかのRFCを新しい定義で更新することにもなるだろう。 用語は、話題ごとに緩やかに編成されている。幾つかの定義は、DNS コミュニティで一般的に話されているが、それを定義する用語を持たなかった 事象に対して新しい用語を定義するものである。 他の組織がDNS関連の用語を独自に定義していることもある。例えば、W3Cは "ドメイン(domain)"を以下に示すように定義している。 https://specs.webplatform.org/url/webspecs/develop/. "DNS"に関する一貫した単一の定義は存在しないことに注意せよ。その 定義は、以下に挙げる項目、すなわちインターネット上にあるオブジェクト に対して一般的に使用される名前付けの仕組み、それらのオブジェクトの 名前や特定の性質を表現する分散型データベース、そのデータベースに 対して分散型の保守や障害耐性、緩やかな一貫性などを提供する アーキテクチャー、及び(以下に述べるように)このアーキテクチャーを 実装するシンプルな問い合わせ-応答プロトコルといったものを幾つか 組み合わせたものだと考えられる。 DNSの用語における大文字表記は、RFCやさまざまなDNSの専門家達の間でも しばしば食い違いが起きている。本文書で使用されている大文字表記は、 現状の慣例では最も有力なものだが、他の大文字表記の様式が誤っている とか時代遅れであるといったことを示唆する意図はない。幾つかのものに ついては、異なるRFCからの引用のため、同じ用語に対して異なる様式の 大文字表記が使用されている。 Hoffman, et al. Informational [Page 3] RFC 7719 DNS Terminology December 2015 2. 名前 Domain name(ドメイン名): [RFC1034]のセクション3.1は、 "ドメイン名空間"をツリー構造として 説明している。"各ノードはラベルを持ち、その長さはゼロから63オクテット である。…ノードのドメイン名は、ツリーのルートからそのノードまでの パス上にあるノードのラベルを一覧に並べたものである。…実装を シンプルにするため、ドメイン名を表現するトータルオクテット数 (すなわち、全ラベルのオクテットと、各ラベルのオクテット長の和) は255に制限される"。ドメイン名に含まれる任意のラベルは、任意の オクテット値を保持できる。 Fully qualified domain name (完全修飾ドメイン名)(FQDN): 多くの場合、この用語は、単に上で概説した"ノードのドメイン名"と同じ ことを伝える明瞭な方法に過ぎない。しかし、この用語はあいまいである。 厳密に言えば、完全修飾ドメイン名には、ルートの長さゼロの最終ラベルを 含むすべてのラベルが含まれる。そのような名前は、"www.example.net." (終端ドットの存在に注意)のようになるだろう。しかし、あらゆる名前は 結局のところ共通のルートを共有するため、名前はしばしばルートに対して 相対的に("www.example.net"のように)書かれ、これも依然として"完全 修飾"と呼ばれている。この用語は、[RFC819]で初めて登場した。 本文書では、名前は大抵の場合ルートに対して相対的に記述される。 "完全修飾ドメイン名"という用語が必要な理由は、部分的に修飾された ドメイン名の存在である。これは、右端から幾つかの名前が省かれており、 コンテキストによってのみ理解される名前である。 Label(ラベル): FQDNによって特定される一連のノードを構成する個々のノードの識別子。 Host name(ホスト名): この用語及び同義の"hostname(ホスト名)"は広く使用されているが、 [RFC1034]、[RFC1035]、[RFC1123]、[RFC2181]のどの文書でも定義されて いない。[RFC952]で概説されているように、DNSはもともとホストテーブル 環境への普及が進められていたので、この"ホスト名"という用語は、ホスト テーブルに関連してなされた定義に非公式に従っていた可能性がある。時間 と共に、この定義は変化したように見える。"ホスト名"は、多くの場合 [RFC1034]のセクション3.5 "推奨される名前の構文"記載のルールに従う ドメイン名と考えられている。ドメイン名に含まれるどのラベルも任意の オクテット値を保持できることに注意せよ。これに対し、ホスト名は、一般に そこに含まれる各ラベルが"推奨される名前の構文"記載のルールに改訂 すなわちラベルはASCII数字で開始できるという事項を加えたもの(この 改訂は[RFC1123]のセクション2.1に由来する)に従うドメイン名であると 考えられている。 また、この用語は、"printer.admin.example.com"の"printer"のように、 FQDNの最初のラベルだけを参照するものとして使用されることもある。 (オペレーティングシステムの設定でこのような使用法が正式に認定 されている場合もある)。 Hoffman, et al. Informational [Page 4] RFC 7719 DNS Terminology December 2015 更に、機器を参照する任意の名前を記述するためにこの用語が使用 されることがあるが、その名前が"推奨される名前の構文"に従わない ラベルを含んでいる可能性がある。 TLD: トップレベルドメインのことで、"com"や"jp"のように、ルートの一つ下の レイヤーに位置するゾーンを意味する。DNSの観点からは、TLDだからと いって特別なことは何もない。その大部分は、委任が主たる内容の (delegation-centric)ゾーンであり、運用に関する重要なポリシーの課題 が存在する。TLDは、国コードトップレベルドメイン(Country Code Top-Level Domain:ccTLD)、分野別トップレベルドメイン(Generic Top-Level Domain:gTLD)などのサブグループに分類されることがよくある。この分類は ポリシーの問題であり、本文書の対象範囲外である。 IDN: "Internationalized Domain Name(国際化ドメイン名)"の一般的な略語。 IDNAプロトコルは、DNS内のアプリケーションで非ASCII文字のドメイン名を 取り扱う標準的な仕組みである。現在の標準は、通常"IDNA2008"と呼ばれ、 [RFC5890]、[RFC5891]、[RFC5892]、[RFC5893]、[RFC5894]で定義されて いる。これらの文書は、"LDHラベル"、"A-ラベル"、"U-ラベル"といった、 多数のIDN固有の用語を定義している。[RFC6365]は国際化に関するより多く の用語(その一部はIDNに関連する)を定義しており、[RFC6055]は幾つかの 新しい用語を含むIDNの非常に広範な議論を行っている。 Subdomain(サブドメイン): "ドメインが別のドメインに包含される場合、そのドメインのサブドメイン になる。この関係は、サブドメインの名前がそれを包含するドメイン名で 終わっているかどうかを見ることで検査できる"。([RFC1034]のセクション 3.1から引用)。例えば、ホスト名"nnn.mmm.example.com"において、 "mmm.example.com"と"nnn.mmm.example.com"のどちらも"example.com"の サブドメインである。 Alias(別名): CNAMEリソースレコードの所有者、またはDNAMEリソースレコード[RFC6672] の所有者のサブドメイン。"Canonical name(正式名)"も参照せよ。 Canonical name(正式名): CNAMEリソースレコードは、"その所有者名が別名であると特定し、RRの RDATA部で対応する正式名を指定する"。([RFC1034]のセクション3.6.2 から引用)。"canonical"という語は、数学の"canonical form(正準形)" の概念に関連している。 CNAME: "従来、CNAMEレコードのラベルを'CNAME'と称してきた。これは不幸なこと である。'CNAME'は'canonical name(正式名)' の略称なのだが、CNAME レコードの所有者はalias(別名)であって正式名ではない"。([RFC2181]の セクション10.1.1から引用)。 Hoffman, et al. Informational [Page 5] RFC 7719 DNS Terminology December 2015 Public suffix(Public Suffix): "公開されたレジストリに管理されるドメイン"。([RFC6265]のセクション 5.3から引用)。この用語の一般的な定義は、下位にサブドメインを登録 でき、かつHTTPクッキー([RFC6265])が設定されるべきではないドメイン名 である。それがPublic Suffixであるかを示す情報はドメイン名の中に存在 しないので、外部的な手段によってしか判定できない。実際、あるドメイン とそのサブドメインのどちらもがPublic Suffixという状況もあり得る。 本文書の発行時点において、IETF DBOUNDワーキンググループ[DBOUND]が Public Suffixに関する課題に取り組んでいる。 ドメイン名がもともと保持する特性の中に、それがPublix Suffixであるかを 示す情報はない。Public Suffixを特定するリソースの一つは、Mozillaに よって維持されているPublic Suffixリスト(PSL)(http://publicsuffix.org/) である。 例えば、本文書の発行時点では、"com.au"ドメインはPublix Suffixとして PSLに列挙されている。(この例は将来変更される可能性があることに注意 せよ)。 "Public Suffix"という用語は、さまざまな理由でDNSコミュニティにおいて 議論の的になっており、将来大幅に変更されるかもしれないことに注意 せよ。ドメインをPublic Suffixと呼ぶことが困難な例の一つとして、 本文書の発行前後における"uk"TLDのように、ゾーンの登録ポリシーの 変更といった理由で、Public Suffixの指定対象が時間と共に変化する ことが挙げられる。 3. DNSヘッダー及び応答コード DNSメッセージのヘッダーは先頭12オクテットである。[RFC1035]のセクション 4.1.1からセクション4.1.3までの間にあるヘッダー図に含まれる多くの フィールドとフラグは、その図に記載されている個々の名前で参照される。 例えば、応答コードは"RCODE"と呼ばれ、レコードのデータは"RDATA"と 呼ばれ、権威を持つ回答を示すビットはしばしば"AAフラグ"または"AAビット" と呼ばれる。 [RFC1035]で定義される応答コードの一部には、独自の簡略名がつけられて いる。応答コードの数値と無関係に現れる幾つかの一般的な応答コード名は、 "FORMERR"、"SERVFAIL"、"NXDOMAIN"等である(最後のものは"Name Error (名前エラー)"とも呼ばれる)。すべてのRCODEは http://www.iana.org/assignments/dns-parametersに一覧が掲載されている。 ただし、大半の文書はすべて大文字を使用しているにもかかわらず、この サイトは大文字・小文字を混在した形式を採用している。 NODATA: "指定されたクラスを持つ名前としては正当だが、指定されたタイプの レコードは持たないことを示す疑似RCODE。NODATA応答は、回答からの 推論を必要とする"。([RFC2308]のセクション1から引用)。"NODATAは、 RCODEがNOERRORに設定されており、かつ回答部に関連する情報を何も 保持しないことで提示される。 Hoffman, et al. Informational [Page 6] RFC 7719 DNS Terminology December 2015 権威部はSOAレコードを保持する。権威部にSOAレコードがない場合は NSレコードも存在しない"。([RFC2308]のセクション2.2から引用)。 参照はNODATA応答と似たフォーマットであることに注意せよ。[RFC2308] はそれらを区別する方法を説明している。 "NXRRSET"という用語は、NODATAの同義語として使用されることがある。 しかし、NXRRSETは[RFC2136]で定義される固有のエラーコードなので、 これは誤りである。 Negative response(ネガティブ応答): 特定のRRsetが存在しないことを示す応答。あるいはRCODEによってネーム サーバーが回答できないことを示す応答。[RFC2308]のセクション2及び セクション7で、ネガティブ応答の種類について詳細に記述している。 Referrals(参照): 権威を持たない回答の権威部にあるデータ。[RFC1035]のセクション2.1は、 "権威を持つ"データを定義している。しかし、(セクション6で定義される) ゾーンカットにある参照は権威を持たない。参照は、恐らくゾーンカット にあるNSリソースレコードとそのグルーレコードだろう。ゾーンカットの 親側のNSレコードは権威を持つ委任だが、通常権威を持つデータとしては 扱われない。一般に、参照とは、サーバーは問い合わせに対する回答を 知らないが、それを得るためにはどこに問い合わせを送るべきかは知っている という回答を返すための手段である。歴史的に、多くの権威サーバーは、 問い合わされた名前に対して自身が権威を持たない場合、ルートゾーンへの 参照を回答していた。しかし、この取り組みは減退している。 4. リソースレコード RR: リソースレコードの頭字語。([RFC1034]のセクション3.6)。 RRset: ラベル、クラス、タイプのすべてが同一だが、データが異なるリソース レコードの集合。([RFC2181]由来の定義)。幾つかの文書ではRRSetと つづられることもある。明確化しておくと、本定義における"同一のラベル" とは"同一の所有者名"を意味する。加えて、[RFC2181]は"RRsetに属する すべてのRRのTTLは同じでなければならない"と述べている。(この定義は "QTYPE=ANYの問い合わせで得られる応答"とは全く異なるものであり、 そのような解釈は残念な誤解である)。 EDNS: [RFC6891]で定義されているDNS拡張の仕組み。バージョン番号を示す ために、"EDNS0"または"EDNS(0)"と呼ばれることもある。EDNSにより、 DNSクライアント及びDNSサーバーは、オリジナルの512オクテットの 制限よりも大きいメッセージサイズの指定、応答コード空間の拡張が できるようになる。また、DNS問い合わせの処理に影響を与える追加 オプションの配送なども将来実現できるようになっている。 Hoffman, et al. Informational [Page 7] RFC 7719 DNS Terminology December 2015 OPT: 特定のトランザクションにおけるひと続きの問い合わせ、回答の連なりに関する 制御情報を保持するためにだけ使用される疑似RR("メタRR"と呼ばれることも ある)。([RFC6891]のセクション6.1.1由来の定義)。EDNSに使用される。 Owner(所有者): RRが見つかるドメイン名([RFC1034]のセクション3.6)。大抵の場合 "owner name(所有者名)"という用語の中に現れる。 SOA field names(SOAフィールド名): ここで示される定義も含めて、DNS文書はしばしばSOAリソースレコードの RDATAのフィールドをフィールド名で参照する。これらのフィールドは、 [RFC1035]のセクション3.3.13で定義されている。それらの名前は、(SOAの RDATAに現れる順序で)MNAME、RNAME、SERIAL、REFRESH、RETRY、EXPIRE、 MINIMUMである。MINIMUMフィールドの意味は、[RFC2308]のセクション4で 更新されていることに注意せよ。新しい定義では、MINIMUMフィールドは単に "ネガティブ応答に対して使用されるTTL"となる。本文書は、フィールドを 説明する用語の代わりにフィールド名を使用する傾向にある。 TTL: リソースレコードの"time to live(有効期間)"の最大値。"TTL値は、最小値0、 最大値2147483647の符号なし整数である。言い換えると、最大値は2^31-1 である。転送時には、この値は32ビットのTTLフィールドのうち下位31ビット にエンコードされ、最上位ビットまたは符号ビットは0に設定される"。 ([RFC2181]のセクション8から引用)。([RFC1035]は、これが符号付き整数 であると誤って述べていることに注意せよ。その誤りは[RFC2181]で修正 された)。 TTLは、"情報源が再び調査されるべき状況になるまでそのリソースレコード をキャッシュしてよい時間間隔を指定する"。([RFC1035]のセクション3.2.1 から引用)。また、"破棄されるべき状況になるまでそのリソースレコードを キャッシュしてよい時間間隔を(秒単位で)指定する"ものでもある。([RFC1035] のセクション4.1.3から引用)。リソースレコードに対して定義されているにも かかわらず、RRset内のすべてのリソースレコードのTTLは同一であることが 求められる([RFC2181]のセクション5.2)。 TTLが最大有効期間である理由は、キャッシュ運用者が、特定の値を 越えるTTL値を許可しないというポリシーがある場合などに、運用目的で 有効期間を短縮するという判断をするかもしれないからである。また、 TTL値がまだ正のときにキャッシュから値が消去されると、その値は 事実上ゼロになる。一部のサーバーは、RFC 1035の勧告には反するが、 一部のRRsetのTTLを(権威を持つデータが極端に短いTTLを持つ場合などに) 無視することが知られている。 Hoffman, et al. Informational [Page 8] RFC 7719 DNS Terminology December 2015 また、ゾーンの"デフォルトTTL"という概念があり、サーバーソフトウェアの 設定パラメーターになっていることがある。大抵の場合、サーバー全体の デフォルト値や、ゾーンファイルで$TTLディレクティブを使用して設定される ゾーンのデフォルト値によって表現される。$TTLディレクティブは、[RFC2308] によってマスターファイルフォーマットに追加された。 Class independent(クラス非依存): すべてのDNSクラスで構文と意味が同じリソースレコードタイプ。クラス非依存 でないリソースレコードタイプとは、レコードのDNSクラスに応じて異なる 意味を持つものか、IN(クラス1、インターネット)以外のクラスでは意味が 定義されていないものである。 5. DNSサーバー及びDNSクライアント 本セクションは、DNSクライアントまたはDNSサーバー、あるいは両者として 機能するシステムで使用される用語を定義する。 Resolver(リゾルバー): "クライアントのリクエストに応えてネームサーバーから情報を引き出す" プログラム。([RFC1034]のセクション2.4から引用)。"リゾルバーは、 リゾルバーのサービスをリクエストするプログラムと同じ機器上に配備 されるが、他のホスト上のネームサーバーの助力を必要とする場合もある"。 ([RFC1034]のセクション5.1から引用)。リゾルバーは、名前、タイプ、 クラスを指定して問い合わせを実行し、回答を受信する。この論理的機能は "resolution(名前解決)"と呼ばれる。実際には、この用語は、通常特定 タイプのリゾルバー数種(うち幾つかは以下で定義される)を総称的に参照する ので、この用語の使用法の理解は、コンテキストの理解にかかっている。 Stub resolver(スタブリゾルバー): 名前解決すべてを自身では実行できないリゾルバー。スタブリゾルバーは、 一般に実際の名前解決機能を請け負う再帰リゾルバーに依存する。 [RFC1034]のセクション5.3.1において、スタブリゾルバーの議論はされて いるものの完全な定義はされていない。これらは[RFC1123]のセクション 6.1.3.1で完全に定義されている。 Iterative mode(反復モード): DNS問い合わせを受信し、別のサーバーへの参照を応答するサーバーの名前解決 モード。[RFC1034]のセクション2.3は、これを"サーバーがクライアントに別の サーバーを参照させ、クライアントに問い合わせを続行させる"と記述している。 反復モードで動作するリゾルバーは、"iterative resolver(反復リゾルバー)" と呼ばれることがある。 Recursive mode(再帰モード): DNS問い合わせを受信し、ローカルキャッシュから問い合わせに応答するか、 オリジナルの問い合わせの最終回答を得るために他のサーバーに問い合わせを 送信するかのどちらかを行うサーバーの名前解決モード。[RFC1034]の セクション2.3は、これを"最初のサーバーがクライアントに替わって他の サーバーに問い合わせを続行する"と記述している。 Hoffman, et al. Informational [Page 9] RFC 7719 DNS Terminology December 2015 再帰モードで動作するサーバーは、(問い合わせに応答する)ネームサーバー 機能と(名前解決機能を実行する)リゾルバー機能を持つものと考えられる。 このモードで動作するシステムは、通常"再帰サーバー"と呼ばれる。"再帰 リゾルバー"と呼ばれることもある。厳密には、これらの違いは、一方は他の 再帰サーバーに問い合わせを送信するが、もう一方は送信しないことである。 しかし、現実に問い合わせを送信するサーバーが再帰的に動作するかを前もって 知ることはできない。両方の用語は互いに置き換え可能なものとして使用 されているように見える。 Full resolver(フルリゾルバー): この用語は[RFC1035]で使用されているが、定義はされていない。RFC 1123 は、[RFC1035]の"フルリゾルバー"という用語が意図したものと同じかは 定かでないが、"フルサービスリゾルバー"を定義している。この用語は、 どのRFCでも適切な定義がされていない。 Full-service resolver(フルサービスリゾルバー): [RFC1123]のセクション6.1.3.1は、この用語をキャッシュを使用し再帰 モードで動作する(加えて他の要件も満たす)リゾルバーを意味するものと 定義している。 Priming(プライミング): リゾルバーのキャッシュに何らかの関連データが保存される前に、問い合わせ を送信すべき場所を決定するためにリゾルバーに使用される仕組み。 プライミングは、ほとんどの場合ルートゾーンの権威サーバー一覧を含む 環境設定から実行される。 Negative caching(ネガティブキャッシュ): "何かが存在しない、回答が提供できないあるいは回答されないといった 情報の保存場所"。([RFC2308]のセクション1から引用)。 Authoritative server(権威サーバー): "自身が保持する情報からDNSゾーンの内容を把握するため、そのゾーンに 関する問い合わせに対して他のサーバーへの問い合わせをせずに回答可能な サーバー"。([RFC2182]のセクション2から引用)。これは、DNS問い合わせに 対し、応答のヘッダーに含まれるAAフラグを1に設定してゾーン関する情報 を回答するように設定されているシステムである。一つ以上のDNSゾーンに 対して権威を持つサーバーとも言える。権威サーバーは、親ゾーンから 権威をそのサーバーに委任されていなくても問い合わせに応答できることに 注意せよ。権威サーバーは、"参照"も提供する。通常、これはサーバーから 委任された子ゾーンである。これらの参照は0に設定されたAAビットを持ち、 権威部と(必要に応じて)付加情報部に保存された参照データを伴う。 Authoritative-only server(専用権威サーバー): 権威を持つデータのみを提供し、再帰を伴うリクエストを無視するネーム サーバー。"通常の場合、自分ではどのような問い合わせも生成しない。 代わりに、自身が提供するゾーンに含まれる情報を検索する反復リゾルバー からの非再帰の問い合わせに対して回答する"。([RFC4697]のセクション2.4 から引用)。 Hoffman, et al. Informational [Page 10] RFC 7719 DNS Terminology December 2015 Zone transfer(ゾーン転送): クライアントがゾーンのコピーをリクエストし、権威サーバーが必要とされる 情報を送信するという動作。(ゾーンの説明はセクション6を参照せよ)。 ゾーン転送の実行に関して二つの標準的な方法がある。一つはゾーンすべてを コピーする仕組みのAXFR("Authoritative Transfer(権威を持つゾーン 転送)")([RFC5936]に記載)で、もう一つは変更されたゾーンの一部だけを コピーする仕組みのIXFR("Incremental Transfer(差分ゾーン転送)") ([RFC1995]に記載)である。多くのシステムは、DNSプロトコルの範囲外に ある非標準のゾーン転送手法を使用している。 Secondary server(セカンダリサーバー): "ゾーン転送を使用してゾーンを取得する権威サーバー"。([RFC1996]の セクション2.1から引用)。[RFC2182]は、セカンダリサーバーについて 詳細に記述している。[RFC1996]のような以前に発行されたDNS RFCでは、 これを"スレーブ"と呼んでいたが、現在の一般的な用語法では"セカンダリ" と呼ぶように変わっている。セカンダリサーバーは[RFC1034]でも議論 されている。 Slave server(スレーブサーバー): セカンダリサーバーを参照せよ。 Primary server(プライマリサーバー): "一つ以上の(セカンダリ)サーバーに対してゾーン転送の転送源となるように 設定された、あらゆる権威サーバー"。([RFC1996]のセクション2.1から引用)。 より具体的には、"一つ以上の(セカンダリ)サーバーに対してAXFRデータ またはIXFRデータの転送源として設定された権威サーバー"。([RFC2136]から 引用)。[RFC1996]のような以前に発行されたDNS RFCでは、これを"マスター" と呼んでいたが、現在の一般的な用語法では"プライマリ"と呼ぶように 変わっている。プライマリサーバーは[RFC1034]でも議論されている。 Master server(マスターサーバー): プライマリサーバーを参照せよ。 Primary master(プライマリマスター): "プライマリマスターは、ゾーンのSOA MNAMEフィールドに加えて、任意で NS RRによって名前が指定される"。([RFC1996]のセクション2.1から引用)。 [RFC2136]は、"プライマリマスター"を"AXFR/IXFRの依存グラフのルート にあるマスターサーバー。プライマリマスターは、ゾーンのSOA MNAME フィールドに加えて、任意でNS RRによって名前が指定される。定義により、 一つのゾーンについて一つのプライマリマスターしか存在できない"と定義 している。プライマリマスターというアイディアは[RFC2136]だけでしか 使用されておらず、DNSの他の機能要素の議論においては、これは時代遅れ のものと考えられている。 Stealth server(ステルスサーバー): これは"ゾーンのNS RRに列挙されていないことを除けばスレーブサーバーの ようなもの"である。([RFC1996]のセクション2.1から引用)。 Hoffman, et al. Informational [Page 11] RFC 7719 DNS Terminology December 2015 Hidden master(非公開マスター): ゾーン転送のマスターとなるステルスサーバー。"この方式を採用する場合、 更新を行うマスターネームサーバーはNS RRsetに列挙されないので、インター ネット上の一般的なホストは利用できない"。([RFC6781]のセクション3.4.3から 引用)。以前に発行された[RFC4641]では、非公開マスターの名前は幾つかの 構成情報におけるSOA RRのMNAMEフィールドに現れるが、公開されているDNS データの中には全く現れないと述べている。非公開マスターは、セカンダリ やプライマリマスターのどちらかであってもよい。 Forwarding(転送): あるサーバーがDNS問い合わせを名前解決するため、その問い合わせのRDビットを 1に設定して別のサーバーに送信する処理。転送はDNSリゾルバーの機能で あり、問い合わせの無分別な中継とは異なるものである。 [RFC5625]は転送に関する特定の定義を与えないが、転送を行うシステムが サポートする必要のある機能を詳細に記述している。転送を行うシステムは "DNSプロキシー"と呼ばれることもあるが、その用語はこれまでにまだ定義 されていない([RFC5625]でも)。 Forwarder(フォワーダー): [RFC2308]のセクション1は、フォワーダーを"問い合わせの名前解決にあたり、 権威ネームサーバーの連鎖を直接たどる代わりに使用されるネームサーバー" と記述している。[RFC2308]は、更に"一般に、フォワーダーはインターネット へのアクセスがより良好であるか、多数のリゾルバーに共有されるより大きな キャッシュを保持しているかのどちらかである"とも述べている。この定義は、 フォワーダーは通常権威サーバーにしか問い合わせしないと示唆しているように 見える。しかし、現在の使用法では、フォワーダーはしばしばスタブ リゾルバーと再帰サーバーを仲介する。[RFC2308]は、フォワーダーが反復 リゾルバーなのかフルサービスリゾルバーなのかについて何も述べていない。 Policy-implementing resolver(ポリシー実装リゾルバー): 再帰モードで動作するリゾルバーだが、マルウェアサイトや好ましくない コンテンツへのアクセスを抑止するといったポリシー基準に基づき、返す回答 の一部を変更するもの。一般に、スタブリゾルバーは、上流のリゾルバーが そのようなポリシーを実装しているか、実装しているとして何を変更するかに 関する正確なポリシーはどのようなものかといった事は何もわからない。 スタブリゾルバーのユーザーがポリシーを実装するために使用するという 明示的意図のもとにポリシー実装リゾルバーを選択する場合もあるが、スタブ リゾルバーのユーザーに何も通知されないままポリシーが押し付けられる 場合もある。 Open resolver(オープンリゾルバー): あらゆる(またはそれに近い)スタブリゾルバーからの問い合わせを受理し、 処理するフルサービスリゾルバー。"public resolver(公開リゾルバー)" と呼ばれることもある。しかし、"公開リゾルバー"という用語は、オープンに なるように意図的に設定されたオープンリゾルバーを指すものとしてより多く 使用されるが、オープンリゾルバーの圧倒的多数は、恐らくは誤って オープンに設定されてしまったものである。 Hoffman, et al. Informational [Page 12] RFC 7719 DNS Terminology December 2015 View(ビュー): DNSサーバーが問い合わせの属性に応じて異なる回答を提供できるようにする 設定。通常の場合、ビューは問い合わせの送信元IPアドレスに応じて差別化 されるが、宛先IPアドレスや問い合わせのタイプ(AXFRなど)、再帰要求が設定 されているかなどに基づいて差別化されることもある。ビューは、多くの 場合、保護されたネットワークの"内側"からの問い合わせに対し、そのネット ワークの"外側"からの問い合わせよりも多くの名前や異なるアドレスを提供 するために使用される。ビューはDNSの標準化された要素ではないが、 サーバーソフトウェアに広く実装されている。 Passive DNS(パッシブDNS): サーバーからのDNS応答を保存することにより、大量のDNSデータを収集する 仕組み。これらのシステムの一部は、応答に関連するDNS問い合わせも収集する ので、プライバシーの課題が生じる可能性がある。パッシブDNSデータベース は、過去のある時点でどのレコードが利用可能だったかといった、DNSゾーン に関する歴史的な質問に答えるために使用することができる。パッシブDNS データベースにより、"特定の値のAレコードを持つ名前すべてを検索する" のように名前以外の検索キーを使用して保存されたレコードを検索できる ようになる。 Anycast(エニーキャスト): "特定のサービスアドレスを複数の異なる自律的な場所で利用可能にして おき、送信されたデータグラムが複数の利用可能な場所の一つに経路付け されるようにする実践的行為"。([RFC4786]のセクション2から引用)。 6. ゾーン 本セクションは、提供または検索されるゾーンについて議論する際に使用される 用語を定義する。 Zone(ゾーン): "権威を持つ情報は'zone(ゾーン)'と呼ばれる単位に組織化され、これらの ゾーンはゾーンのデータに対して冗長化サービスを提供するネームサーバー へと自動的に配付されるようにすることができる"。([RFC1034]のセクション 2.4から引用)。 Child(子): "親からのドメインの委任を持つレコードが提示するエンティティ"。 ([RFC7344]のセクション1.1から引用)。 Parent(親): "子が登録されるドメイン"。([RFC7344]のセクション1.1から引用)。以前は、 [RFC882]で"親ネームサーバー"は"ドメイン名空間内で新しいドメインを保持 することになる場所に対する権威を持つネームサーバー"と定義されていた。 ([RFC882]は[RFC1024]及び[RFC1035]によって廃止されていることに注意 せよ)。[RFC819]にも親と子の関係に関する若干の記述がある。 Hoffman, et al. Informational [Page 13] RFC 7719 DNS Terminology December 2015 Origin(起点): (a) "ゾーンの先頭(ゾーンを親から分離するゾーンカットの直下)に現れる ドメイン名。ゾーン名はゾーンの起点のドメイン名と同じである"。 ([RFC2181]のセクション6から引用)。最近では、"起点"と"頂点"(以下で 定義)がこの意味で参照される場合、しばしば互いに置き換え可能なもの として使用される。 (b) ゾーンファイル内で、そのドメイン名に対する任意の相対ドメイン名が 現れるドメイン名。この意味での参照は、一般に"$ORIGIN"のコンテキスト の中で見られる。$ORIGINはマスターファイルフォーマットの一部として [RFC1035]のセクション5.1で定義されている制御エントリーである。例えば、 $ORIGINが"example.org."に設定されている場合、マスターファイル内にある "www"に関する行は、実際には"www.example.org."に関するエントリーとなる。 Apex(頂点): ツリー内において、SOAの所有者と対応する権威を持つNS RRsetがある 場所。"ゾーン頂点"と呼ばれることもある。[RFC4033]は、これを"ゾーン カットの子側の名前"と定義している。"頂点"はツリー構造のデータ論的 記述であり、"起点"はゾーンファイルに同じ概念が実装された際の名前 であると考えられるだろう。しかし、それらの用語を使用する際に、違いが 常に維持されるわけではなく、この定義と微妙に矛盾する使用法を見出す こともあるかもしれない。[RFC1034]は、"頂点"の同義語として"ゾーンの トップノード"という用語を使用しているが、この用語は広く使用されては いない。最近では、"起点"(上述)と"頂点"の一つ目の意味は、しばしば 互いに置き換え可能なものとして使用されている。 Zone cut(ゾーンカット): 二つのゾーンの間を、片方のゾーンの起点がもう片方のゾーンの子となる ように区切る場所。 "ゾーンは'ゾーンカット'で区切られる。各ゾーンカットは'子'ゾーン (カットの下側)と'親'ゾーン(カットの上側)を分離する"。([RFC2181]の セクション6から引用。これはほとんど明示的とは言えない定義である ことに注意せよ)。[RFC1034]のセクション4.2は"カット"を"ゾーン カット"の意味で使用している。 Delegation(委任): 任意のドメインの頂点の下方にある名前空間内に独立したゾーンを作成する ための処理。子の起点に関するNS RRsetが親ゾーンに追加された時点で 委任が発生する。委任は、性質上ゾーンカットで発生する。この用語は 一般に名詞でもあり、委任という行為によって生成される新しいゾーン を指す。 Hoffman, et al. Informational [Page 14] RFC 7719 DNS Terminology December 2015 Glue records(グルーレコード): "[ゾーンの]権威を持つデータの一部ではなく、[サブゾーンに属する ネームサーバーの]アドレスRRを提供する[リソースレコード]。これらの RRは、ネームサーバーの名前がカットの'下位(below)'にある場合にのみ 必要で、参照応答の一部としてのみ使用される"。グルーがないと、"ネーム サーバーのアドレスを知るためには、その知りたいアドレスを使用して サーバーにコンタクトしなければならない、とNS RRが通知してくるような 状況が生じ得る"。([RFC1034]のセクション4.2.1から引用した定義)。 後になされた定義では、グルーとは"ゾーンファイル内に存在するが厳密 にはそのゾーンの一部ではないあらゆるレコード、具体的に、委任された サブゾーンのネームサーバー(NS)レコードや、そのNSレコードに付随する アドレスレコード(A、AAAAなど)、その他ゾーンに現れるかもしれないが ゾーンには属さないあらゆるデータなどを含むもの"([RFC2181]の セクション5.4.1)である。今日、グルーは後者のより広い定義を念頭に 置いて使用されることもあるが、[RFC2181]の定義部分周辺のコンテキスト は、グルーという用語の使用範囲はRFC 2181それ自身であり、必ずしも それ以外の場所は意図していなかったことを示唆している。 In-bailiwick(内部名): (a) ゾーンの起点の下位か(まれだが)同じであるかどちらかの名前を 持つネームサーバーを記述する形容詞。内部名のネームサーバーは、 親ゾーンのグルーレコードを必要とする(先の"グルーレコード"の一つめ の定義を使用)。 (b) 所有者名か所有者名の先祖（訳注：親、親の親など）に対して サーバーが権威を持つデータ。応答に含まれるグルーレコードの関連性 を議論する場合、この用語は大抵この意味で使用される。例えば、 親ゾーン"example.com"のサーバーは、"ns.child.example.com"に関する グルーレコードを返すかもしれない。"child.example.com"ゾーンは "example.com"ゾーンの子孫にあたるため、そのグルーレコードは内部名 である。 Out-of-bailiwick(外部名): in-bailiwick(内部名)の反意語。 Authoritative data(権威を持つデータ): "ゾーンのトップノードからリーフノードまたはゾーン最下部を区切る カットの上のノードに到るまでの全ノードに所属するRRすべて"。([RFC1034] のセクション4.2.1から引用)。この定義は、ゾーン内に現れるNSレコード のうち、ゾーンカット下側に同一のNS RRが存在することから、恐らく 本当は権威を持たないだろうあらゆるNSレコードをも不用意に含んで しまっている可能性があることに注意すべきである。 Hoffman, et al. Informational [Page 15] RFC 7719 DNS Terminology December 2015 これは、権威を持つデータに関する記述があいまいであることを明らかに している。なぜなら、親側のNSレコードは、たとえそれら自身が権威を持つ データでなくても権威を持つものとして委任を提示するからである。 Root zone(ルートゾーン): 頂点が長さゼロのラベルのゾーン。"DNSルート"と呼ばれることもある。 空の非終端ドメイン名(Empty Non-Terminal): "自身はリソースレコードを持たないが、そのサブドメインがリソース レコードを持つドメイン名"。([RFC4592]のセクション2.2.2から引用)。 典型的な例をSRVレコードで示す。"_sip._tcp.example.com"という名前に おいて、"_tcp.example.com"はRRsetを持っていない可能性があるが、 "_sip._tcp.example.com"は(少なくとも)SRV RRsetを持つ。 Delegation-centric zone(委任が主たる内容のゾーン): 大部分が子ゾーンへの委任で構成されるゾーン。この用語は、子ゾーンへの 委任を幾つか持つが、同時にそのゾーン自身と子ゾーンのどちらかあるいは 両方に関する大量のデータリソースレコードを持つゾーンと対照をなして 使用される。この用語は[RFC4956]と[RFC5155]で使用されているが、定義は されていない。 Wildcard(ワイルドカード): [RFC1034]は"ワイルドカード"を定義したが、それは実装者を混乱させる結果 となるものだった。ラベル"*"で始まる所有者名を持つRRには特別な処理が 行われる。"このようなRRは'ワイルドカード'と呼ばれる。ワイルドカードRR は、RRを合成する指示であると考えられる"。([RFC1034]のセクション4.3.3 から引用)。より明確な定義を含むワイルドカードの広範な議論については [RFC4592]を参照せよ。 Occluded name(遮蔽された名前): "動的更新によって委任点を追加すると、すべての下位ドメインの名前が 中途半端な状態(limbo)、すなわちゾーンの一部ではあるが検索処理からは 見えないという状態になる。DNAMEリソースレコードの追加も同じ影響が ある。そのような下位の名前は'occluded(遮蔽されている)'という"。 ([RFC5936]のセクション3.5から引用)。 Fast flux DNS(短時間で応答が変化するDNS): これは、"DNSで見つかったドメインが複数のIPアドレスに対応する複数の Aレコードを保持しており、かつそのAレコードのどれもが非常に短いTTL値を 関連付けられている場合に発生する。これは、そのドメインが短い期間内に さまざまなIPアドレスに解決されることを意味する"。([RFC6561]のセクション 1.1.5から引用。誤字訂正済み)。大抵の場合、マルウェア配送のために使用 される。アドレスが極めて速く変化するため、すべてのホストを突き止めるのは 困難である。この技法はAAAAレコードでも機能するが、本稿執筆時点において、 そのような使用法はインターネット上でほとんど観測されていないことに 留意すべきである。 Hoffman, et al. Informational [Page 16] RFC 7719 DNS Terminology December 2015 7. 登録モデル Registry(レジストリ): ゾーンに名前を登録できるようにするゾーンの管理作業。この用語は、 しばしば(TLDのような)委任が主たる内容の大規模ゾーンで登録作業を行う 組織だけを参照するために使用される。しかし、正式には、どのデータを ゾーンに加えるかを決定する個人、組織はすべてそのゾーンのレジストリ である。この"レジストリ"の定義は、DNSの観点に由来する。一部のゾーン では、何をゾーンに加えるかを決定するポリシーは、レジストリ運用者 ではなく上位ゾーンによって決定される。 Registrant(登録者): 個人または組織。彼らの望みに応じてレジストリによってゾーンに名前が 登録される。多くのゾーンでレジストリと登録者は同じエンティティに なるだろうが、TLDの場合、大抵そうはならない。 Registrar(レジストラ): 登録者とレジストリの間で仲介者の役目を務めるサービスプロバイダー。 すべての登録がレジストラを必要とするわけではないが、TLDの場合、 レジストラを登録に関与させるのが一般的である。 EPP: 拡張可能な資源登録プロトコル(EPP)は、一般にレジストリとレジストラ間の 登録情報の通信に使用される。EPPは[RFC5730]で定義されている。 WHOIS: [RFC3912]で規定されているプロトコルで、大抵レジストリデータベースへの 問い合わせに使用される。WHOISデータは、(ゾーン管理者の連絡先といった) 登録データとドメイン名を関連付けるために頻繁に使用される。"WHOIS データ"という用語はしばしばレジストリデータベースの同義語として使用 されるが、レジストリデータベースは異なるプロトコル、特にRDAPによって 提供される場合もある。WHOISプロトコルは、IPアドレスのレジストリデータ でも使用される。 RDAP: 登録データアクセスプロトコル(The Registration Data Access Protocol)の 略称で、[RFC7480]、[RFC7481]、[RFC7482]、[RFC7483]、[RFC7484]、 [RFC7485]で定義される。RDAPプロトコル及びデータフォーマットは、 WHOISの置き換えが意図されている。 DNS operator(DNS運用者): DNSサーバーの稼働の責任を負うエンティティ。ゾーンの権威サーバーの 場合、登録者自らがDNS運用者となることもあるし、レジストラが登録者の 代わりにDNS運用者となる場合もある。あるいは、サードパーティーの DNS運用者を使用することもある。幾つかのゾーンでは、DNS運用者にゾーン 内容の許認可を行う他のエンティティが加わった共同体により、レジストリ 機能が実行される。 Hoffman, et al. Informational [Page 17] RFC 7719 DNS Terminology December 2015 8. DNSSEC全般 ほとんどのDNSSEC用語は、[RFC4033]、[RFC4034]、[RFC4035]、[RFC5155]で 定義されている。ここでは、DNSコミュニティに混乱を招いてきた用語が強調 される。 DNSSEC-aware(DNSSEC対応)とDNSSEC-unaware(DNSSEC非対応): これら二つの用語は幾つかのRFCで使用されているが、正式には定義されて いない。しかし、[RFC4033]のセクション2では、多数のリゾルバーと バリデーターのタイプが定義されている。具体的に、"non-validating security-aware stub resolver(署名を検証しないDNSSEC対応スタブ リゾルバー)"、"non-validating stub resolver(署名を検証しないスタブ リゾルバー)"、"security-aware name server(DNSSEC対応ネームサーバー)"、 "security-aware recursive name server(DNSSEC対応再帰ネームサーバー)"、 "security-aware resolver(DNSSEC対応リゾルバー)"、"security-aware stub resolver(DNSSEC対応スタブリゾルバー)"、"security-oblivious (DNSSEC非対応の)'何でも'"といったものである。("validating resolver (署名を検証するリゾルバー)"という用語はDNS関連文書の数カ所で使用されて いるが、これも定義されていないことに注意せよ)。 Signed zone(署名ゾーン): "ゾーンのRRsetが署名されている、すなわち適切に構成されたDNSKEYレコード、 RRSIG(Resource Record Signature)レコード、NSEC(Next Secure)レコード すべてと、(任意で)DSレコードを含むゾーン"。([RFC4033]のセクション2から 引用)。別のコンテキストにおいて、ゾーンそれ自体は実効的に署名されて いなくても、そのゾーン内にある関連するRRsetはすべて署名されている場合が あることが指摘されている。とは言え、署名されているべきゾーンが未署名の (またはオプトアウトされた)RRsetを何であれ含む場合、それらのRRsetは Bogus(検証失敗:信用禁止)として扱われるので、ゾーン全体は幾通りかの 方法で処理される必要がある。 また、[RFC6840]の発行以来、NSECレコードは署名ゾーンに必須のものでは なくなっており、署名ゾーンは代わりにNSEC3レコードを含んでいるかも しれないことは留意されるべきである。[RFC7129]は、不在証明応答を提供 するためにDNSSECが使用するNSECとNSEC3の仕組みについて、追加の背景 説明とこれまでの経緯を提供している。 Unsigned zone(未署名ゾーン): [RFC4033]のセクション2は、この用語を"署名されていないゾーン"と定義して いる。[RFC4035]のセクション2は、この用語を"本セクションで規定される ルールに従うこれらのレコード[適切に構成されたDNSKEYレコード、RRSIG レコード、NSECレコードすべてと、(任意で)DSレコード]を持たないゾーン"と 定義している。[RFC4035]のセクション5.2の終わりに、ゾーンが未署名と みなされる追加の状況を定義する重要な注記があり、以下のように述べられて いる。"リゾルバーが認証済みのDS RRsetに列挙されたアルゴリズムをどれも サポートしていない場合、そのリゾルバーは子ゾーンへの認証経路を検証 できない。この場合、リゾルバーは子ゾーンを未署名であるかのように処理 すべきである(SHOULD)"。 Hoffman, et al. Informational [Page 18] RFC 7719 DNS Terminology December 2015 NSEC: "NSECレコードにより、DNSSEC対応リゾルバーは、名前またはタイプの どちらかの不在を示すネガティブ応答を他のDNS応答を認証するのと同じ 仕組みで認証できるようになる"。([RFC4033]のセクション3.2から引用)。 要するに、NSECレコードは不在証明を提供する。 "NSECリソースレコードは二つの独立した情報を提示する。一つめはNSEC RRの 所有者名の(ゾーンの正規順序で)次に来る所有者名で、権威を持つデータ または委任点のNS RRsetを持つものである。二つめはNSRC RRの所有者名に 関連づけられるRRタイプの集合である"。(RFC 4034のセクション4から引用)。 NSEC3: NSEC3レコードもNSECレコードのように不在証明を提供するが、NSEC3 レコードはゾーン列挙の効果を軽減し、オプトアウトもサポートする。 NSEC3レコードは[RFC5155]で定義される。 [RFC6840]において、[RFC5155]は"[RFC4033]のセクション10に記載されて いるDNSSEC関連文書の一部であると現在では見なされている"。と説明 されていることに注意せよ。これは、以前に発行されたRFCの幾つかの定義 におけるNSECレコードだけに関する記述は、恐らくNSECとNSEC3の両方に ついて述べていると見なされるべきであることを意味する。 Opt-out(オプトアウト): "オプトアウトフラグは、そのNSEC3 RRが未署名委任をカバーしているか どうかを示す"。([RFC5155]のセクション3.1.2.1から引用)。オプトアウト は、Insecureなゾーンへの委任(訳注: 委任先が未署名なので、親側にNSは あってもDSがない委任)を署名で保護すると高コストになる問題に対処する ものである。オプトアウトを使用する場合、Insecureな委任(及びInsecureな 委任からしか生じないEmpty Non-Terminal)の名前についてはNSEC3レコード や関連するRRSIGレコードが不要となる。オプトアウトNSEC3レコードは、 Insecureな委任の存在や不在を証明できない。([RFC7129]のセクション5.1 を編集)。 Zone enumeration(ゾーン列挙): "成功した問い合わせを元にゾーンの全内容を見破ろうとする行為"。([RFC5155] のセクション1.3から引用)。"ゾーンウォーキング"と呼ばれることもある。 ゾーン列挙は、推測者があり得そうなラベルの巨大な辞書を使用し、それら のラベルに対して連続して問い合わせを送信したり、NSEC3レコードの内容を 辞書とマッチングさせたりするゾーンコンテンツの推測とは異なる。 Key signing key (鍵署名鍵: KSK): "ゾーン頂点のDNSKEY RRsetのみを署名する"DNSSEC鍵([RFC6781]の セクション3.1から引用)。 Hoffman, et al. Informational [Page 19] RFC 7719 DNS Terminology December 2015 Zone signing key (ゾーン署名鍵: ZSK): "ゾーン頂点のDNSKEY RRsetを除くゾーンのRRsetの中で、署名が必要な すべてのRRsetへの署名に使用できるDNSSEC鍵"。([RFC6781]のセクション3.1 から引用)。KSKとZSKの役割は互いに排他的ではないことに注意せよ。 単一の鍵がKSKとZSKの両方の役割を同時に果たすこともできる。また、 頂点のDNSKEY RRsetの署名にZSKが使用される場合もあることに注意せよ。 Combined signing key (統合署名鍵: CSK): "KSKとZSKを分離しない場合、つまり鍵がKSKとZSKの両方の役割を担う場合、 これを単一署名鍵方式(Single Type signing scheme)と呼ぶことにする"。 ([RFC6781]のセクション3.1から引用)。これは"統合署名鍵"またはCSKと 呼ばれることがある。特定の鍵をZSKにするか、KSKにするか、あるいはCSKに するかを決定するのは、プロトコルではなく運用ノウハウである。 Secure Entry Point (セキュアエントリーポイント: SEP): DNSKEYのRDATAに含まれるフラグで、"信頼の連鎖を構築する際にゾーンへの セキュアエントリーポイントとして使用される鍵、言い換えると、親ゾーンの DS RRから参照される(ことになっている)かトラストアンカーとして設定される (ことになっている)鍵を区別するために使用できるもの。従って、KSK として使用される鍵にはSEPフラグが設定されるべきであり、ZSKとして使用 される鍵には設定されるべきではないことが示唆される。一方、KSKとZSK を分離しない(単一署名鍵方式の)場合、すべての鍵にSEPフラグが設定される べきであることが示唆される"。([RFC6781]のセクション3.2.3から引用)。 SEPフラグは単なるヒントであって、任意のDNSKEY RRの妥当性検証の際に、 フラグの存在や不在に基づいてKSKまたはZSKとして不適格という判定に使用 してはならないことに注意せよ。 DNSSEC Policy (DNSSECポリシー: DP): "DNSSECの署名ゾーンに実装されるセキュリティ要件と標準を明記する"声明。 ([RFC6841]のセクション2から引用)。 DNSSEC Practice Statement (DNSSEC運用ステートメント: DPS): "(存在する場合)DNSSECポリシーをサポート、補完する運用実務の開示文書 で、所定のゾーン管理方針がどのように手続きや管理を高水準で実装するか を述べたもの"。([RFC6841]のセクション2から引用)。 9. DNSSECの状態 署名を検証するリゾルバーは、応答が四つの状態、Secure、Insecure、Bogus、 Indeterminateの一つであると判断することができる。これらの状態は [RFC4033]と[RFC4035]で定義されているが、二つの定義は若干異なる。 本文書は二つの定義を調整するための努力はせず、調整される必要があるか どうかについても見解は示さない。 Hoffman, et al. Informational [Page 20] RFC 7719 DNS Terminology December 2015 [RFC4033]のセクション5は以下のように述べている。 署名を検証するリゾルバーは、以下の四つの状態を判定することができる。 Secure(検証成功: 信頼度高) 署名を検証するリゾルバーがトラストアンカーを持ち、信頼の連鎖を 構築しており、応答に含まれる署名をすべて検証可能だった状態。 Insecure(未署名状況検出: 信頼度低) 署名を検証するリゾルバーがトラストアンカーを持ち、信頼の連鎖を 構築しているが、幾つかの委任点でDSレコードの不在が証明されて いる状態。これは、DNSのツリー構造においてDSレコードが存在しないと わかっている下位の空間は、恐らく安全ではないことを意味する。 署名を検証するリゾルバーは、ドメイン空間の一部を安全でない ものとしてマークするローカルポリシーを設定してもよい。 Bogus(検証失敗: 信頼禁止) 署名を検証するリゾルバーがトラストアンカーを持ち、子側のデータが 署名されていることを示す安全な委任を確認しているが、応答の署名検証 には失敗した状態。署名の検証に失敗する理由は幾つか考えられる。 例えば署名の消失、署名の期限切れ、署名で使われているアルゴリズムを サポートしていない、NSEC RRは存在すると主張しているデータが実際には ない等が挙げられる。 Indeterminate(検証対象外: 信頼度低) DNSのツリー構造の一部が安全であることを示すトラストアンカーが全く存在 しない状態。これがデフォルトの運用モードである。 [RFC4035]のセクション4.3は以下のように述べている。 DNSSEC対応リゾルバーは、(あるRRsetが署名検証の対象であるかどうかを 判定するにあたり)以下の四つの場合を識別できなければならない。 Secure(検証成功: 信頼度高) トラストアンカーからそのRRsetに至る、署名されたDNSKEY RRと署名 されたDS RRの連鎖を構築できる。この場合、そのRRsetは署名されて いるはずなので、先に記述した署名検証の対象となる。 Insecure(未署名状況検出：信頼度低) どのトラストアンカーからも、そのRRsetに至る署名されたDNSKEY RRと 署名されたDS RRの連鎖が構築できないことをリゾルバーが認識している。 対象のRRsetが未署名ゾーンに存在したり、未署名ゾーンの下位に存在する 場合にこのような状況が生じ得る。この場合、RRsetは署名されているかも しれないし、未署名かもしれないが、いずれにせよリゾルバーは署名を 検証できない。 Hoffman, et al. Informational [Page 21] RFC 7719 DNS Terminology December 2015 Bogus(検証失敗: 信頼禁止) リゾルバーはそのRRsetに至る信頼の連鎖を構築できるはずだと想定して いたが、何らかの理由で署名検証に失敗したか、関連するDNSSEC RRが 存在を示唆するデータが存在しなかったか、いずれかの理由で信頼の連鎖 が構築できない。このような状況は、攻撃を示唆している場合もあるが、 設定エラーや何らかのデータ破損を示唆する場合もある。 Indeterminate(検証対象外: 信頼度低) リゾルバーが必要なDNSSEC RRを得られなかったため、そのRRsetが本来 署名されているべきものなのかを判断できない。DNSSEC対応リゾルバー が署名ゾーンを管理するDNSSEC対応ネームサーバーにアクセスできない 場合にこのような状況が生じ得る。 10. セキュリティに関する考慮点 本文書における定義は、DNSのセキュリティに関するどの考慮点も変更しない。 11. References 11.1. Normative References [RFC882] Mockapetris, P., "Domain names: Concepts and facilities", RFC 882, DOI 10.17487/RFC0882, November 1983, . [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, . [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, August 1996, . [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, . Hoffman, et al. Informational [Page 22] RFC 7719 DNS Terminology December 2015 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, . [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection and Operation of Secondary DNS Servers", BCP 16, RFC 2182, DOI 10.17487/RFC2182, July 1997, . [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, . [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, . [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, . [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name System", RFC 4592, DOI 10.17487/RFC4592, July 2006, . [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, . [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, . [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, . Hoffman, et al. Informational [Page 23] RFC 7719 DNS Terminology December 2015 [RFC6561] Livingood, J., Mody, N., and M. O'Reirdan, "Recommendations for the Remediation of Bots in ISP Networks", RFC 6561, DOI 10.17487/RFC6561, March 2012, . [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, . [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC Operational Practices, Version 2", RFC 6781, DOI 10.17487/RFC6781, December 2012, . [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and Implementation Notes for DNS Security (DNSSEC)", RFC 6840, DOI 10.17487/RFC6840, February 2013, . [RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A Framework for DNSSEC Policies and DNSSEC Practice Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013, . [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, . [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating DNSSEC Delegation Trust Maintenance", RFC 7344, DOI 10.17487/RFC7344, September 2014, . 11.2. Informative References [DBOUND] IETF, "Domain Boundaries (dbound) Working Group", 2015, . [RFC819] Su, Z. and J. Postel, "The Domain Naming Convention for Internet User Applications", RFC 819, DOI 10.17487/RFC0819, August 1982, . [RFC952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host table specification", RFC 952, DOI 10.17487/RFC0952, October 1985, . Hoffman, et al. Informational [Page 24] RFC 7719 DNS Terminology December 2015 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, DOI 10.17487/RFC1995, August 1996, . [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, DOI 10.17487/RFC3912, September 2004, . [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", RFC 4641, DOI 10.17487/RFC4641, September 2006, . [RFC4697] Larson, M. and P. Barber, "Observed DNS Resolution Misbehavior", BCP 123, RFC 4697, DOI 10.17487/RFC4697, October 2006, . [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006, . [RFC4956] Arends, R., Kosters, M., and D. Blacka, "DNS Security (DNSSEC) Opt-In", RFC 4956, DOI 10.17487/RFC4956, July 2007, . [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, . [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, . [RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, . [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, DOI 10.17487/RFC5892, August 2010, . [RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010, . Hoffman, et al. Informational [Page 25] RFC 7719 DNS Terminology December 2015 [RFC5894] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010, . [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on Encodings for Internationalized Domain Names", RFC 6055, DOI 10.17487/RFC6055, February 2011, . [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, . [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in Internationalization in the IETF", BCP 166, RFC 6365, DOI 10.17487/RFC6365, September 2011, . [RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129, February 2014, . [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the Registration Data Access Protocol (RDAP)", RFC 7480, DOI 10.17487/RFC7480, March 2015, . [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the Registration Data Access Protocol (RDAP)", RFC 7481, DOI 10.17487/RFC7481, March 2015, . [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access Protocol (RDAP) Query Format", RFC 7482, DOI 10.17487/RFC7482, March 2015, . [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the Registration Data Access Protocol (RDAP)", RFC 7483, DOI 10.17487/RFC7483, March 2015, . [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March 2015, . Hoffman, et al. Informational [Page 26] RFC 7719 DNS Terminology December 2015 [RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin, "Inventory and Analysis of WHOIS Registration Objects", RFC 7485, DOI 10.17487/RFC7485, March 2015, . Acknowledgements The authors gratefully acknowledge all of the authors of DNS-related RFCs that proceed this one. Comments from Tony Finch, Stephane Bortzmeyer, Niall O'Reilly, Colm MacCarthaigh, Ray Bellis, John Kristoff, Robert Edmonds, Paul Wouters, Shumon Huque, Paul Ebersman, David Lawrence, Matthijs Mekking, Casey Deccio, Bob Harold, Ed Lewis, John Klensin, David Black, and many others in the DNSOP Working Group have helped shape this document. Authors' Addresses Paul Hoffman ICANN Email: paul.hoffman@icann.org Andrew Sullivan Dyn 150 Dow Street, Tower 2 Manchester, NH 03101 United States Email: asullivan@dyn.com Kazunori Fujiwara Japan Registry Services Co., Ltd. Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda-ku, Tokyo 101-0065 Japan Phone: +81 3 5215 8451 Email: fujiwara@jprs.co.jp Hoffman, et al. Informational [Page 27]