Internet Engineering Task Force (IETF) P. Hoffman RFC: 8499 ICANN BCP: 219 A. Sullivan 廃止(Obsolete): 7719 更新: 2308 K. Fujiwara 分類:現状の最良の方法(Best Current Practice) JPRS ISSN: 2070-1721 2019年1月 DNSの用語 要旨 ドメイン名システム(DNS)は、文字通り何十もの異なるRFCで定義されて いる。DNSプロトコルの実装者と開発者、及びDNSシステムの運用者に 使用される用語は、DNSが最初に定義されて以来数十年の間に時々変化 してきた。本文書は、DNSで使用されている多数の用語の定義を単一の 文書で与えるものである。 本文書はRFC 7719を廃止し、RFC 2308を更新する。 Status of This Memo This memo documents an Internet Best Current Practice. 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). Further information on BCPs is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8499. Hoffman, et al. Best Current Practice [Page 1] RFC 8499 DNS Terminology January 2019 Copyright Notice Copyright (c) 2019 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 (https://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. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. 名前 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. DNS応答コード . . . . . . . . . . . . . . . . . . . . . . . . 10 4. DNSトランザクション . . . . . . . . . . . . . . . . . . . . . 11 5. リソースレコード . . . . . . . . . . . . . . . . . . . . . . 14 6. DNSサーバー及びDNSクライアント. . . . . . . . . . . . . . . 16 7. ゾーン . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. ワイルドカード . . . . . . . . . . . . . . . . . . . . . . . 27 9. 登録モデル . . . . . . . . . . . . . . . . . . . . . . . . . 28 10. DNSSEC全般 . . . . . . . . . . . . . . . . . . . . . . . . . 30 11. DNSSECの状態 . . . . . . . . . . . . . . . . . . . . . . . . 34 12. セキュリティに関する考慮点 . . . . . . . . . . . . . . . . . 36 13. IANAに関する考慮点 . . . . . . . . . . . . . . . . . . . . . 36 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 14.1. Normative References . . . . . . . . . . . . . . . . . . 36 14.2. Informative References . . . . . . . . . . . . . . . . . 39 Appendix A. Definitions Updated by This Document . . . . . . . . 44 Appendix B. Definitions First Defined in This Document . . . . . 44 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 Hoffman, et al. Best Current Practice [Page 2] RFC 8499 DNS Terminology January 2019 1. はじめに ドメイン名システム(DNS)は、シンプルな問い合わせ-応答プロトコルで、 そのメッセージフォーマットは問い合わせ、応答の両方向で同じである。 (セクション2で"パブリックDNS"の定義を与える。人々が"DNS"と言う場合 に意味するものは、大抵この用語である)。プロトコルとメッセージ フォーマットは、[RFC1034]と[RFC1035]で定義されている。これらのRFC が幾つかの用語を定義し、後の文書で更に他の用語が定義された。また、 [RFC1034]と[RFC1035]に由来する用語の幾つかは、現在、1987年の頃とは 幾分異なる意味を持つようになっている。 本文書は、DNS関連の用語を幅広くまとめ、話題ごとに緩やかに編成した ものである。以前に発行されたRFCの中で厳密に定義されているものもあれ ば、緩やかにしか定義されていないものもある。以前に発行されたどのRFC でも全く定義されていない用語も存在する。 他の組織がDNS関連の用語を独自に定義していることもある。例えば、 WHATWGは、において"ドメイン(domain)" を定義している。また、RSSAC(Root Server System Advisory Committee: ルートサーバーシステム諮問委員会)は良い語彙集[RSSAC026]を持っている。 本文書に列挙される定義の大部分は、プロトコル開発者と運用者の両方を 含むDNSコミュニティで合意された定義である。幾つかの定義は以前に発行 されたRFCのものとは異なっており、その場合、その違いが注記されて いる。本文書では、合意された定義がRFCのものと同じである場合、その RFCが引用される。合意された定義がRFCのものから多少変化している場合、 そのRFCについて言及はするが、新しい独立した定義が与えられる。本文書 が更新した定義の一覧については付録Aを参照せよ。 本文書の作成中に、幾つかのDNS関連の用語は、複数のDNSの専門家らに よって全く異なって解釈されていると判明したことには特に留意すべき である。更に、以前に発行されたDNS RFCで定義された幾つかの用語の 場合、現在一般に合意された定義は存在するものの、それはオリジナル の定義とは異なっている。以上を踏まえて、本文書は[RFC7719]を大幅に 改訂したものである。 "DNS"に関する一貫した単一の定義は存在しないことに注意せよ。その定義 は、以下に挙げる項目、すなわちインターネット上にあるオブジェクトに 対して一般的に使用される命名の仕組み、それらのオブジェクトの名前や 特定の性質を表現する分散型データベース、そのデータベースに対して 分散型の保守や弾力性、緩やかな一貫性などを提供するアーキテクチャー、 及び(後ほど述べるように)このアーキテクチャーを実装するシンプルな 問い合わせ-応答プロトコルといったものを幾つか組み合わせたものだと考え られる。これらの異なる定義に対処する方法として、セクション2で "グローバルDNS"と"プライベートDNS"が定義される。 Hoffman, et al. Best Current Practice [Page 3] RFC 8499 DNS Terminology January 2019 DNSの用語における大文字表記は、RFCやさまざまなDNSの専門家達の間でも しばしば食い違いが起きている。本文書で使用されている大文字表記は、 現状の実践では最も有力なものだが、他の大文字表記の様式が誤っている とか時代遅れであるといったことを示唆する意図はない。幾つかの用語 では、複数の異なるRFCから引用をしたため、同じ用語に対して異なる様式 の大文字表記が使用されている。 読者は、本文書の用語が話題別にグループ化されていることに留意すべき である。DNSをまだ熟知していない者は、本文書を先頭から順に読み進めて も、DNSを一から学ぶことはできないだろう。むしろ、かいつまんで読む ことが、幾つかの定義を理解するための十分なコンテキストを得る唯一の 方法である。本文書には、本文書を読んでDNSを学ぼうとする読者にとって 役立つと思われる索引が付けられている。 2. 名前 Naming system(命名システム): 命名システムは、名前とデータを関連付ける。命名システムは、個々の 命名システムの区別に役立つ多くの重要な様相を持っている。共通して 見られる幾つかの様相には以下のものが含まれる。 ・ 名前の構成 ・ 名前のフォーマット ・ 名前の管理 ・ 名前に関連付け可能なデータタイプ ・ 名前のメタデータのタイプ ・ 名前からデータを取得するプロトコル ・ 名前を解決するコンテキスト ここに挙げた一覧は、時間の経過とともに人々が命名システムに関して 認識するようになった様相の小さなサブセットであり、命名システムの 比較に使用できる適切な様相の集合についてIETFは未だ合意に達して いないことに注意せよ。例えば、他の様相として"名前に含まれるデータ を更新するプロトコル"、"名前のプライバシー"、"名前に関連付けられた データのプライバシー"等を含められるかもしれないが、これらは先に 一覧として示したものほどには明確に定義されていない。先に列挙した ものは、DNSに似た命名システムとDNSを説明する際に役立つことから 選択された。 Hoffman, et al. Best Current Practice [Page 4] RFC 8499 DNS Terminology January 2019 Domain name(ドメイン名): 一つ以上のラベルに順序を付けて並べたもの これはDNS RFC([RFC1034]及び[RFC1035])に依存しない定義であり、 DNS以外のシステムにも適用されることに注意せよ。[RFC1034]は、グラフ 理論のツリーとノードを使用して"ドメイン名空間"を定義しており、その 定義はここに示す定義と実質的に同じである。有向非巡回グラフのどの パスであっても、ルートからの距離が大きいものから小さくなっていく 順に並べたノードのラベルで構成されるドメイン名によって表現できる。 (これは、本文書を含むDNSの世界では標準的な規則である)。最後の ラベルがグラフのルートを特定するドメイン名は完全修飾されている。 完全修飾ドメイン名に厳密に一致するプレフィックスで構成された他の ドメイン名は、最初に省略されたノードに対して相対的なものである。 また、IETFの別の文書やIETF以外の文書でも、多種多様な形で"ドメイン 名"という用語を使用してきていることに注意せよ。以前の文書では、 "[RFC1035]の構文とマッチする名前"を意味するために"ドメイン名"を 使用するのが一般的だったが、恐らくは、"かつ、グローバルDNSで 現在名前解決可能であるか今後名前解決可能になるもの"か、または "ただし、表現フォーマットを使用しているだけのもの"という付加的 なルールが想定されている。 Label(ラベル): ドメイン名の一部を構成する、0個以上のオクテットに順序をつけて 並べたもの。グラフ理論を使用すると、ラベルとは、あり得るドメイン 名すべてのグラフの一部に含まれる一つのノードを特定するものという 定義となる。 Global DNS(グローバルDNS): "命名システム"の項に手短に列挙されている様相を使用すると、グローバル DNSは以下のように定義することができる。ここに示すルールの大部分は [RFC1034]と[RFC1035]由来のものだが、"グローバルDNS"という用語は これまで定義されていない。 名前の構成: グローバルDNS内にある名前は、一つ以上のラベルを持つ。 各ラベルの長さは、0オクテット以上63オクテット以下である。完全修飾 ドメイン名において、順序に従う最後のラベルは0オクテット長である。 これは長さ0のオクテットが許容される唯一のラベルであり、"ルート" または"ルートラベル"と呼ばれる。グローバルDNSのドメイン名は、 ワイヤーフォーマットで最大255オクテットの全長を持つが、ルートは この全長計算で1オクテットを消費する。(マルチキャストDNS[RFC6762] は、RFC 1035及び255オクテットに含まれるものは何かに関する異なる 解釈に基づいて、255バイトに加えて終端のゼロを収めるバイトまでを 許容する)。 Hoffman, et al. Best Current Practice [Page 5] RFC 8499 DNS Terminology January 2019 名前のフォーマット: グローバルDNS内にある名前はドメイン名である。 フォーマットは3種類ある。ワイヤーフォーマット、表現フォーマット、 一般表示フォーマットである。 グローバルDNS内にある名前の基本的なワイヤーフォーマットは、 ルートからの距離が大きいものから小さくなっていく順にラベルを 並べ、最後をルートラベルにしたものである。各ラベルの前には、 その長さを示すオクテットが配置される。[RFC1035]は、この フォーマットを変更する圧縮方式も定義している。 グローバルDNS内にある名前の表現フォーマットは、ルートからの 距離が大きいものから小さくなっていく順にASCIIでエンコード されたラベルを並べ、各ラベルの間に"."文字を配置したものである。 表現フォーマットでは、完全修飾ドメイン名は、ルートラベル及び ルートラベルを区切るドットを含む。例えば、表現フォーマット では、ルート以外の二つのラベルを持つ完全修飾ドメイン名は、常に "example.tld."と提示される。"example.tld"ではない。[RFC1035] は、ASCIIでは表示されないオクテットを提示する方法を定義して いる。 一般表示フォーマットは、アプリケーション及びフリーテキスト で使用される。これは表現フォーマットと同じものだが、ルート ラベルの提示とその前への"."の配置は任意であり、めったに実施 されない。例えば、一般表示フォーマットでは、ルート以外の二つの ラベルを持つ完全修飾ドメイン名は、通常"example.tld"と提示され る。"example.tld."ではない。一般表示フォーマットの名前は、 通常、文字体系の表記方向に従い、ルートからの距離が大きいもの から小さくなっていく順にラベルが表記される。(従って、英語 とC言語のどちらにおいても、ルートまたはトップレベルドメイン (TLD)ラベルは並べられる順序的に最右端になる。しかし、アラビア語 の場合、ローカルな慣習によっては最左端になる場合がある)。 名前の管理: 管理は委任によって指定される(セクション7の"委任"の 定義を参照せよ)。グローバルDNSのルートゾーンの管理ポリシーは、 名前運用コミュニティがICANN(Internet Corporation of Assigned Names and Numbers)で開催する会合を経て決定される。名前運用コミュニティ は、グローバルDNSルートゾーンのIANA機能運用者(IANA Functions Operator)を選定する。本文書執筆時点の運用者は、Public Technical Identifiers(PTI)である。(IANA機能を運用するPTIに関する更なる情報 についてはを参照せよ)。ルートゾーンを 提供するネームサーバーは、独立したルート運用者によって提供される。 グローバルDNSの他のゾーンは、独自の管理ポリシーを持つ。 Hoffman, et al. Best Current Practice [Page 6] RFC 8499 DNS Terminology January 2019 名前に関連付け可能なデータタイプ: 名前は、その名前に関連付け られた0個以上のリソースレコードを保持することができる。それぞれ 独自のデータ構造を持つ数多くのリソースレコードタイプが存在して おり、それらは異なる多数のRFC及びIANAレジストリ [IANA_Resource_Registry]で定義されている。 名前のメタデータのタイプ: DNSで公開されているどのような名前も、 リソースレコードの集合として現れる(セクション5の"RRset"の定義を 参照せよ)。一部の名前は、自身ではDNS内で関連付けられたデータを 持たないが、それでもなおDNSに"現れる"。それらの名前は、関連付け られたデータを持つ、より長い名前の一部を構成するからである (セクション7の"空の非終端ドメイン名"の定義を参照せよ)。 名前からデータを取得するプロトコル: [RFC1035]で記述される プロトコル。 名前を解決するコンテキスト: PTIによって配信されるグローバルDNSの ルートゾーン。 Private DNS(プライベートDNS): [RFC1035]に記述されるプロトコルを使用するが、グローバルDNSルート ゾーンに依存しない名前、またはインターネットでは一般的に利用 できないが、[RFC1035]に記述されるプロトコルを使用する名前。 システムは、グローバルDNSと一つ以上のプライベートDNSシステムの 両方を使用することができる。例として"セクション6の"Split DNS (スプリットDNS)"を参照せよ。 DNS内に現れず、DNSプロトコルを使用して検索されることが全く意図 されていないドメイン名は、たとえそれらがドメイン名であったとしても、 グローバルDNSの一部でもプライベートDNSの一部でもないことに注意 せよ。 Multicast DNS (mDNS)(マルチキャストDNS): "マルチキャストDNS(mDNS)は、従来のいかなるユニキャストDNSサーバー もローカルリンク上に存在しない場合に、DNSに似た処理を実行する機能 を提供する。更に、マルチキャストDNSは、DNS名前空間の一部を指定し、 ローカルな使途に開放している。この領域の使用にあたって年間使用料 を支払う必要はなく、また委任の関係を構築したり、それらの名前に 対して回答するよう従来のDNSサーバーを設定したりする必要もない" ([RFC6762]の要旨から引用)。互換性のあるワイヤーフォーマットを使用 しているとはいえ、厳密に言えば、mDNSはDNSとは異なるプロトコル である。また、先の引用で"DNS名前空間の一部"となっている箇所は、 "ドメイン名空間の一部"と言う方がより明確だろう。mDNSの名前がDNS で検索されることは意図されていない。 Hoffman, et al. Best Current Practice [Page 7] RFC 8499 DNS Terminology January 2019 Locally served DNS zone(ローカルに提供されるDNSゾーン): ローカルに提供されるDNSゾーンは、プライベートDNSの特別な事例で ある。名前は、ローカルなコンテキストの中でDNSプロトコルを使用して 解決される。[RFC6303]は、ローカルに提供されるゾーンとなっている IN-ADDR.APRAのサブドメインを定義している。ローカルに提供される ゾーンを介して名前を解決すると、結果があいまいになることがある。 例えば、ローカルに提供されるDNSゾーンのコンテキストが異なると、 同じ名前を解決した結果は異なるかもしれない。ローカルに提供される DNSゾーンのコンテキストは、例えば[RFC6303]や[RFC7793]に列挙され ているような明示的なものでもよいし、ローカルなDNS管理組織によって 定義され、名前解決クライアントには知らされない暗黙的なものでもよい。 Fully qualified domain name (FQDN)(完全修飾ドメイン名): 多くの場合、この用語は、上で概説した"ノードのドメイン名"と同じ ことを伝える明瞭な方法に過ぎない。しかし、この用語はあいまい である。厳密に言えば、完全修飾ドメイン名には、長さゼロのルート ラベルを含む全ラベルが含まれる。そのような名前は、 "www.example.net."(終端ドットの存在に注意)のようになるだろう。 しかし、あらゆる名前は結局のところ共通のルートを共有するため、 名前はしばしばルートに対して相対的に("www.example.net"のように) 書かれ、これも依然として"完全修飾"と呼ばれている。この用語は、 [RFC819]で初めて登場した。本文書では、名前は大抵の場合ルートに 対して相対的に記述される。 "完全修飾ドメイン名"という用語の必要性は、部分的に修飾された ドメイン名の存在に起因する。これは、順番に並べられたラベルのうち 最後から一つ以上のラベルが省略されたものである。(例えば、"example.net" に対して相対的なドメイン名"www"は、"www.example.net"を特定する)。 そのような相対的な名前は、コンテキストによってのみ理解される。 Host name(ホスト名): この用語及び同義の"hostname(ホスト名)"は広く使用されているが、 [RFC1034]、[RFC1035]、[RFC1123]、[RFC2181]のどの文書でも定義され ていない。[RFC952]で概説されているように、DNSはもともとホスト テーブル環境への普及が進められていたので、この"ホスト名"という 用語は、ホストテーブルに関連してなされた定義を非公式に踏襲した 可能性がある。時間と共に、この定義は変化したように見える。 "host name"は、多くの場合、[RFC1034]のセクション3.5記載のルール、 または"推奨される名前の構文"と呼ばれることもあるルールに従う ドメイン名を意図している(その構文では、各ラベルに含まれるあらゆる 文字は英字、数字、ハイフンのいずれかになる)。ドメイン名に含まれる どのラベルも任意のオクテット値を保持できることに注意せよ。これに 対し、"hostname"は、そこに含まれる各ラベルが"推奨される名前の構文" 記載のルールに加えて、ラベルはASCII数字で開始できるという改訂に 従うドメイン名であると一般に考えられている(この改訂は[RFC1123]の セクション2.1に由来する)。 また、この用語は、"printer.admin.example.com"の"printer"のように、 FQDNの最初のラベルだけを参照するものとして使用されることもある。 Hoffman, et al. Best Current Practice [Page 8] RFC 8499 DNS Terminology December 2018 (オペレーティングシステムの設定でこのような使用法が正式に認定 されている場合もある)。更に、機器を参照するどのような名前でも この用語を使用して記述することがあるが、その名前は"推奨される 名前の構文"に従わないラベルを含んでいる可能性がある。 Top-Level Domain (TLD)(トップレベルドメイン): トップレベルドメインは、"com"や"jp"等のように、ルートの一つ下の レイヤーに位置するゾーンである。DNSの観点からは、TLDだからと いって特別なことは何もない。その大部分は、委任が主たる内容の (delegation-centric)ゾーンでもある。(この用語はセクション7で定義 される)。また運用に関する重要なポリシーの課題が存在する。TLDは、 多くの場合、国別トップレベルドメイン(Country Code Top-Level Domain: ccTLD)、分野別トップレベルドメイン(Generic Top-Level Domain: gTLD)、その他のサブグループに分類される。この分類は ポリシーの問題であり、本文書の対象範囲外である。 Internationalized Domain Name (IDN)(国際化ドメイン名): Internationalized Domain Names for Applications (IDNA)(アプリ ケーションにおけるドメイン名の国際化)プロトコルは、DNS内にある 非ASCII文字のドメイン名をアプリケーションで取り扱うための標準的 な仕組みである。本文書執筆時点における標準は、通常"IDNA2008"と 呼ばれるもので、[RFC5890]、[RFC5891]、[RFC5892]、[RFC5893]、[RFC 5894]で定義されている。これらの文書は、"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"のサブドメインである。比較はラベル全体に対して 行われることに注意せよ。つまり、"ooo.example.com"は "oo.example.com"のサブドメインではない。 Alias(別名): CNAMEリソースレコードの所有者、またはDNAMEリソースレコードの 所有者のサブドメイン(DNAMEレコードは[RFC6672]で定義されている)。 "Canonical name(正式名)"も参照せよ。 Canonical name(正式名): CNAMEリソースレコードは、"その所有者名が別名であると特定し、RRの RDATA部で対応する正式名を指定する"([RFC1034]のセクション3.6.2 から引用)。"canonical"という語は、数学の"canonical form(正準形)" の概念に関連している。 Hoffman, et al. Best Current Practice [Page 9] RFC 8499 DNS Terminology January 2019 CNAME: "慣習的に、CNAMEレコードの[所有者]を'CNAME'と称してきた。これは 残念なことである。'CNAME'は'canonical name(正式名)'の略称であり、 CNAMEレコードの[所有者]はほぼ間違いなく正式名ではないからである" ([RFC2181]のセクション10.1.1から引用。引用文に含まれる"ラベル" は"所有者"に変更されている)。 3. DNS応答コード [RFC1035]で定義されている応答コードの幾つかは、独自の短縮名を得て いる。すべてのRCODEは[IANA_Resource_Registry]に列挙されている。そこ では大文字と小文字を混在して使用しているが、ほとんどの文書は大文字 しか使用していない。[RFC1035]で定義された値に対する一般的な名前の 幾つかが本セクションに記述される。また、本セクションは、付加的な RCODEと一般的な定義も含む。すべてのRCODEの一覧はIANAレジストリにある。 NOERROR: このRCODEは、"エラー無し"という記述で[RFC1035]のセクション 4.1.1の中に初出している。 FORMERR: このRCODEは、"フォーマットエラー - ネームサーバーは問い合わせ を解釈できなかった"という記述で[RFC1035]のセクション4.1.1の中に 初出している。 SERVFAIL: このRCODEは、"サーバー障害 - ネームサーバーは、サーバー 側の問題でこの問い合わせを処理できなかった"という記述で[RFC1035]の セクション4.1.1の中に初出している。 NXDOMAIN: このRCODEは、"名前エラー [...] このコードは、問い合わせ で参照されたドメイン名が存在しないことを意味する"という記述で [RFC1035]のセクション4.1.1の中に初出している。[RFC2308]は、 Name Error(名前エラー)の同義語としてNXDOMAINを規定した。 NOTIMP: このRCODEは、"未実装 - ネームサーバーはリクエストされた 種別の問い合わせをサポートしていない"という記述で[RFC1035]の セクション4.1.1の中に初出している。 REFUSED: このRCODEは、"問い合わせ拒否 - ネームサーバーは、ポリシーに よる理由で指定された処理の実行を拒否する。例えば、ネームサーバー は特定のリクエスト発行者には情報を提供したくないと望むかもしれない。 あるいはネームサーバーは特定のデータに関する特定の処理(例えばゾーン 転送)を実行したくないと望むかもしれない"という記述で[RFC1035]の セクション4.1.1の中に初出している。 NODATA: "指定されたクラスの名前としては正当だが、指定されたタイプ のレコードが存在しないことを示す疑似RCODE。NODATA応答は、回答から の推論を必要とする"([RFC2308]のセクション1から引用)。"NODATAは、 RCODEがNOERRORに設定されており、かつ回答部に関連する情報を何も 持たないことで提示される。 Hoffman, et al. Best Current Practice [Page 10] RFC 8499 DNS Terminology December 2018 権威部はSOAレコードを含む。SOAレコードが無ければNSレコードは存在 しない"([RFC2308]のセクション2.2から引用)。参照はNDATA応答と似た フォーマットを持つことに注意せよ。[RFC2308]は両者を区別する方法 を解説している。 "NXRRSET"という用語は、時折NODATAの同義語として使用される。しかし、 NXRRSETが[RFC2136]で定義された固有のエラーコードであることを踏ま えれば、これは誤りである。 Negative response(ネガティブ応答): 特定のRRsetが存在しないことを示す応答。あるいはRCODEによってネーム サーバーが回答できないことを示す応答。[RFC2308]のセクション2及び セクション7で、ネガティブ応答の種類について詳細に記述している。 4. DNSトランザクション DNSメッセージのヘッダーは、メッセージの先頭12オクテットである。 [RFC1035]のセクション4.1.1からセクション4.1.3までの間にある図に 含まれる多くのフィールドとフラグは、それぞれの図に記載されている 個々の名前で参照される。例えば、応答コードは"RCODE"、レコードの データは"RDATA"と呼ばれる。また、権威を持つ回答を示すビットは しばしば"AAフラグ"または"AAビット"と呼ばれる。 Class(クラス): クラスは、"プロトコルファミリーまたはプロトコルのインスタンスを 特定する"([RFC1034]のセクション3.6から引用)。"DNSは、全データを クラスだけではなくタイプにもタグ付けするので、アドレスタイプの データごとに異なるフォーマットを並列に使用することができる"([RFC 1034]のセクション2.2から引用)。実際には、ほぼすべての問い合わせの クラスは"IN"(Internet)である。"CH"(Chaosクラス)に対する問い合わせ も若干あるが、それらは異なるアドレスタイプの情報のためというより は、サーバー自身に関する情報のためのものである。 QNAME: 最も一般的に使用される大まかな定義は、QNAMEとは問い合わせに含まれる 問い合わせ部のフィールドだというものである。"標準問い合わせは、目的の ドメイン名(QNAME)、問い合わせタイプ(QTYPE)、問い合わせクラス(QCLASS) を指定し、マッチするRRの情報を要求する"([RFC1034]のセクション3.7.1 より引用)。厳密に言えば、この定義は[RFC1035]のセクション4.1.2に 由来しており、そこでは問い合わせ部に関連してQNAMEが定義されている。 この定義は一貫して適用されているように見える。セクション6.4の 逆問い合わせの議論において、"問い合わせRRの所有者名とそのTTL"を参照 しているが、その理由は、逆問い合わせは回答部に問い合わせ対象を投入し、 問い合わせ部は空のままにするからである。(なお、逆問い合わせは [RFC3425]で廃止見込みとなっているため、関連する定義は本文書には 現れない)。 Hoffman, et al. Best Current Practice [Page 11] RFC 8499 DNS Terminology January 2019 しかし、[RFC2308]は、問い合わせではなく回答(または一連の回答)に QNAMEを組み入れる形で代替的な定義を行っている。具体的に、QNAMEを 次のように定義している。"...回答の問い合わせ部で指定された名前。 あるいはCNAMEまたはCNAMEの連鎖を解決しようとしている場合、最後の CNAMEのデータフィールドで指定される名前。ここで、最後のCNAMEとは、 他のCNAMEに解決されない値を含むものを指す"。この定義は、CNAMEの 置換が動作する方法とCNAMEの定義により、ある種の内部ロジックを 持っている。ネームサーバーが、問い合わせにマッチするRRsetは発見 できなかったが、CNAMEレコードを持つ同じクラスの同じ名前であれば 発見できた場合、そのネームサーバーは、"CNAMEレコードを応答に含め、 CNAMEレコードのデータフィールドで指定されたドメイン名に対して 問い合わせを再開する"([RFC1034]のセクション3.6.2から引用)。 この事は[RFC1034]のセクション4.3.2で概説される解決アルゴリズム で明確にされている。そこでは、(ノードのデータが)CNAME RRの場合 は、"QNAMEをCNAME RRに含まれる正式名に変更した後で、ステップ1に 戻る"と述べている。CNAMEレコードの所有者名は、RDATAの中にある ものが正式名だと明示的に宣言しているので、新しい名前(つまりCNAME RRのRDATAに含まれていた名前)もまたQNAMEだと見なすという考え方 もある。 しかし、これはある種の混乱を生じさせる。なぜなら、CNAME処理の結果 生成される問い合わせへの応答には、問い合わせ部にエコーされる第1のQNAME (オリジナルの問い合わせに含まれていた名前)に加えて、最後のCNAMEの データフィールドで指定された第2のQNAMEも含まれるからである。この 混乱は名前解決の反復/再帰モードに起因する。これらのモードの場合、 最終的に返される回答は、オリジナルの問い合わせに含まれていたQNAMEと 同じ所有者名でなくてもよい。 この潜在的な混乱に対処するため、以下の三つの意味を区別することが 有用である。 ・ QNAME(オリジナル): オリジナルの問い合わせの問い合わせ部に含まれて 送信された名前。QRビットが1に設定されている場合、この名前は 常に(最終的な)応答の問い合わせ部にエコーされる。 ・ QNAME(実効的): 実際に名前解決がなされる名前。これは、オリジナル の問い合わせで問い合わされた名前か、CNAMEの連鎖となる応答で受信 された名前かのどちらかになる。 ・ QNAME(最終): 最終的に名前解決された名前。これは、実際に問い合わ された名前か、CNAMEの連鎖における最後の名前かのどちらかになる。 ここで留意すべきは、[RFC2308]の定義は[RFC1034]で示された概念とは 異なるものに対する定義なので、[RFC2308]は、その異なる概念に対して 異なる名前を使用した方が良かったということである。今日の一般的な 使用では、QNAMEはほとんどの場合"QNAME(オリジナル)"として上で定義 されているものを意味する。 Hoffman, et al. Best Current Practice [Page 12] RFC 8499 DNS Terminology December 2018 Referrals(参照): サーバーが回答に関して(完全な)権威を持たないことを通知し、問い合わせ たリゾルバーに問い合わせを送信すべき別の場所を提供する応答のタイプ。 参照は部分的なものになる場合もある。 参照は、サーバーが問い合わせに回答はするが再帰サービスを実行して いない場合に生じる。参照は、[RFC1034]のセクション4.3.2に記載され たアルゴリズムのステップ3(b)に現れる。 参照応答には二つのタイプがある。一つめは下方参照("委任応答"と記述 されることもある)で、この場合、サーバーはQNAMEの一部に対して権威 を持っている。権威部のRRsetのRDATAは、参照先のゾーンカットで指定 されるネームサーバーを含む。通常のDNSの動作では、委任の下方にある 名前を見つけるためにこの種の応答が必要とされる。単に"参照"という 語を使用する場合、この種の参照を意味し、多くの人々は、DNSの正当 な参照はこれだけだと信じている。 二つめは上方参照("ルート参照"と記述されることもある)で、この場合、 サーバーはQNAMEのどの部分についても権威を持たない。これが発生する 場合、権威部の参照先ゾーンは通常ルートゾーン(".")となる。通常の DNSの動作では、名前解決やあらゆる問い合わせへの正しい回答に際して、 この種の応答は必要とされない。どのようなサーバーも、上方参照を 送信するという要件はない。一部の人々は、上方参照を設定誤りやエラー の徴候とみなしている。上方参照は、常に何らかの修飾語("上方"や "ルート"など)を必要とし、単なる"参照"という語だけで上方参照と 特定されることは絶対にない。 参照しか持たない応答の場合、回答部は空になる。権威部には、参照先 ゾーンのNS RRsetが含まれる。付加情報部にアドレスを提供するRRを 含んでもよい。AAビットは設定されない。 問い合わせが別名(alias)とマッチする状況において、サーバーがその別名 の対象となる名前には権威を持たないが、別名の対象となる名前の上位 に位置する名前には権威を持つ場合、解決アルゴリズムは、別名に対する 権威を持つ回答と参照の両方を含む応答を生成する。そのような部分的 回答と参照の両方を含む応答は、回答部にデータを保持する。また、 参照先ゾーンのNS RRsetが権威部に含まれる。付加情報部にアドレスを 提供するRRを含んでもよい。AAビットは設定される。回答部の最初の 名前がQNAMEにマッチし、サーバーは回答に対して権威を持つからである ([RFC1035]のセクション4.1.1を参照せよ)。 Hoffman, et al. Best Current Practice [Page 13] RFC 8499 DNS Terminology December 2018 5. リソースレコード RR: リソースレコード(Resource Record)の頭字語([RFC1034]のセクション 3.6を参照せよ)。 RRset: "ラベル、クラス、タイプのすべてが同一だが、異なるデータを持つ" リソースレコードの集合([RFC2181]のセクション5に依拠)。一部の 文書では"RRSet"とつづられていることもある。明確化しておくと、 本定義における"同一のラベル"とは"同一の所有者名"を意味する。 加えて、[RFC2181]は"RRSetに属するすべてのRRのTTLは同じでなければ ならない"と述べている。 RRSIGリソースレコードはこの定義とマッチしないことに注意せよ。 [RFC4035]は次のように述べている。 一つのRRsetが複数のRRSIG RRを持ってもよい(MAY)。RRSIG RRは署名 対象のRRsetと強く結びついているため、他のDNS RRタイプと異なり RRsetを形成しないことに注意せよ。特に、同じ所有者名を持つ複数 のRRSIG RRのTTL値は、[RFC2181]が規定する規則に従わない。 Master file(マスターファイル): "マスターファイルは、テキスト形式のRRを含むテキストファイルで ある。キャッシュの内容を列挙するためにマスターファイルを使用する こともできるが、ゾーンの内容はRRの一覧という形式で表現できること から、ほとんどの場合、マスターファイルはゾーンを定義するために 使用される"([RFC1035]のセクション5から引用)。マスターファイルは "ゾーンファイル"と呼ばれることもある。 Presentation format(表現フォーマット): マスターファイルで使用されるテキストフォーマット。このフォーマット は[RFC1034]や[RFC1035]で見られるものだが、それらの文書では正式 に定義されていない。"表現フォーマット"という用語は、[RFC4034]の 中で初めて現れる。 EDNS: [RFC6891]で定義されているDNS拡張の仕組み。バージョン番号を示す ために、"EDNS0"または"EDNS(0)"と呼ばれることもある。EDNSにより、 DNSクライアント及びDNSサーバーは、オリジナルの512オクテット の制限よりも大きいメッセージサイズの指定、応答コード空間の拡張 に加えて、DNS問い合わせの処理に影響を与える追加オプションの配送 などができるようになる。 OPT: 特定のトランザクションにおける問い合わせ、回答の連なりに関する制御 情報を保持するためにだけ使用される疑似RR("メタRR"と呼ばれること もある)([RFC6891]のセクション6.1.1を意訳した定義)。EDNSに使用 される。 Hoffman, et al. Best Current Practice [Page 14] RFC 8499 DNS Terminology January 2019 Owner(所有者): "RRが見つかるドメイン名"([RFC1034]のセクション3.6から引用)。大抵 の場合"owner name(所有者名)"という用語の中に現れる。 SOA field names(SOAフィールド名): DNS文書では、本文書で提示される定義も含めて、しばしばSOAリソース レコードのRDATAのフィールドをフィールド名で参照する。"SOA"は、 "権威を持つゾーンの開始点"を表す。これらのフィールドは、[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から引用)。また、同文書のセクション4.1.3は次のように述べて いる。"破棄されるべき状況になるまでそのリソースレコードをキャッシュ してよい期間を(秒単位で)指定するもの"。個々のリソースレコードに 対して定義されるものではあるが、RRset内の全リソースレコードのTTL は同一であることが求められる([RFC2181]のセクション5.2)。 TTLが最大有効期間である理由は、キャッシュ運用者が、特定の値を 越えるTTL値を許可しないというポリシーがある場合などに、運用目的で 有効期間を短縮するという判断をするかもしれないからである。一部の サーバーは、たとえRFC 1035の勧告に反することになろうとも、一部の RRsetのTTLを(権威を持つデータが極端に短いTTLを持つ場合などに)無視 することが知られている。RRsetは、TTL期間の満了前にキャッシュから 消去される可能性がある。この時点で、関連付けられたRRsetが存在 しなくなるため、TTLの値は不明になる。 また、ゾーンの"デフォルトTTL"という概念もあり、サーバーソフトウェア の設定パラメーターになっていることがある。大抵の場合、サーバー全体 のデフォルト値や、ゾーンファイル内で$TTLディレクティブを使用して 設定されるゾーンのデフォルト値によって表現される。$TTLディレクティブ は、[RFC2308]によってマスターファイルフォーマットに追加された。 Hoffman, et al. Best Current Practice [Page 15] RFC 8499 DNS Terminology January 2019 Class independent(クラス非依存): すべてのDNSクラスで構文と意味が同じリソースレコードタイプ。クラス 非依存でないリソースレコードタイプとは、レコードのDNSクラスに 応じて異なる意味を持つものか、一部のクラスでは意味が定義されて いないものである。ほとんどのリソースレコードタイプは、クラス1 (IN、Internet)では定義がなされているが、その多くは他のクラスでは 定義がなされていない。 Address records(アドレスレコード): タイプがAまたはAAAAのレコード。[RFC2181]は、これらを非公式に "(A、AAAAなど)"と定義している。将来、新しいタイプのアドレス レコードが定義されるかもしれないことに注意せよ。 6. DNSサーバー及びDNSクライアント 本セクションは、DNSクライアントまたはDNSサーバー、あるいは両者として 動作するシステムで使用される用語を定義する。過去に発行されたRFCでは、 DNSサーバーは、"ネームサーバー(name servers、nameserver)"や単に "サーバー"と呼ばれていることもある。DNSサーバーの公式な定義は存在 しないが、RFCは一般に、問い合わせを待機し、[RFC1035]及びその後継 文書で定義されるDNSプロトコルを使用して応答を送信するインターネット サーバーを想定している。 "DNSサーバー"及び"ネームサーバー"という用語は、提供されるサービス を理解するためにコンテキストが求められることに留意することが重要 である。権威サーバーと再帰リゾルバーは、(同じソフトウェアパッケージ の一部であるかもしれないとはいえ)それぞれ異なる役割を果たしていても、 どちらもしばしば"DNSサーバー"及び"ネームサーバー"と呼ばれる。 パブリックDNSルートサーバーシステムに固有の用語については、[RSSAC026] を参照せよ。同文書は、"ルートサーバー"、"ルートサーバー運用者"のような 用語に加えて、パブリックDNSのルートゾーンが提供される方法に固有の用語 を定義している。 Resolver(リゾルバー): "クライアントのリクエストに応えてネームサーバーから情報を引き 出す"プログラム([RFC1034]のセクション2.4から引用)。リゾルバーは、 名前、タイプ、クラスを指定して問い合わせを実行し、応答を受け取る。 この論理的機能は"resolution(名前解決)"と呼ばれる。実際のところ、 この用語は、通常、特定タイプのリゾルバー数種類(うち幾つかは後ほど 定義される)を総称的に参照するので、この用語の使用法の理解は、 コンテキストの理解にかかっている。 関連する用語として"resolve(名前解決する)"があるが、この用語は [RFC1034]や[RFC1035]で公式には定義されていない。この用語に帰属 する定義は、"ドメイン名、クラス、タイプで構成された問い合わせを 行い、ある種の応答を受信すること"になるだろう。同様に "resolution(名前解決結果)"に帰属する定義は、"resolving(名前解決 処理)から受信した応答"になるだろう。 Hoffman, et al. Best Current Practice [Page 16] RFC 8499 DNS Terminology January 2019 Stub resolver(スタブリゾルバー): 名前解決すべてを自身では実行できないリゾルバー。スタブリゾルバー は、実際の名前解決機能を引き受けるにあたり、一般に再帰リゾルバー に依存する。[RFC1034]のセクション5.3.1において、スタブリゾルバー の議論はされているものの完全な定義はされていない。これらは [RFC1123]のセクション6.1.3.1で完全に定義されている。 Iterative mode(反復モード): DNS問い合わせを受信し、別のサーバーへの参照を応答するサーバーの名前 解決モード。[RFC1034]のセクション2.3は、これを"サーバーがクライ アントに別のサーバーを参照させ、クライアントに問い合わせを続行させる" と記述している。反復モードで動作するリゾルバーは、"iterative resolver(反復リゾルバー)"と呼ばれることがある。本セクションの後 に出てくる"iterative resoluton(反復的名前解決)"も参照せよ。 Recursive mode(再帰モード): DNS問い合わせを受信し、ローカルキャッシュから問い合わせに応答するか、 オリジナルの問い合わせに対する最終的な回答を得るために他のサーバー に問い合わせを送信するかのどちらかを行うサーバーの名前解決モード。 [RFC1034]のセクション2.3は、これを"最初のサーバーがクライアント に替わって他のサーバーへの問い合わせを続行する"と記述している。 また、[RFC1034]のセクション4.3.1は、"[再帰]モードの場合、ネーム サーバーはリゾルバーの役割を果たし、エラーか回答かのどちらかを 返す。参照は絶対に返さない"と述べている。また、同じセクションでは 次のようにも述べている。 再帰サービスを提供する用意のあるサーバーにRDが設定された問い合わせ が到着した時点で再帰モードが起動する。クライアントは、応答にRAと RDの両方が設定されているかを検査することで、再帰モードが使用され たかどうかを検証できる。 再帰モードで動作するサーバーは、(問い合わせに応答する)ネームサーバー 機能と(名前解決機能を実行する)リゾルバー機能を持つものと考えられる。 このモードで動作するシステムは、通常"再帰サーバー"と呼ばれるが、 "再帰リゾルバー"と呼ばれることもある。実際問題として、問い合わせ を送信する先のサーバーが再帰的に動作するかを前もって知ることは できないので、両方の用語は互いに置き換え可能なものとして使用されて いると見なすことができる。 Recursive resolver(再帰リゾルバー): 再帰モードで動作するリゾルバー。一般に、再帰リゾルバーは受信した 回答をキャッシュすると期待されるが(その場合はフルサービスリゾルバー になる)、一部の再帰サーバーはキャッシュしないかもしれない。 [RFC4697]は、再帰リゾルバーと反復リゾルバーを区別しようと試みた。 Hoffman, et al. Best Current Practice [Page 17] RFC 8499 DNS Terminology January 2019 Recursive query(再帰的問い合わせ): ヘッダーの再帰要求(RD)ビットが1に設定された問い合わせ([RFC1035]の セクション4.1.1参照)。再帰サービスが利用可能な状況で問い合わせのRD ビットによってそれが要求された場合、サーバーは問い合わせに回答する ために自身のリゾルバーを使用する([RFC1034]のセクション4.3.2参照)。 Non-recursive query(非再帰的問い合わせ): ヘッダーの再帰要求(RD)ビットが0に設定された問い合わせ。サーバーは、 非再帰的問い合わせへの回答にあたり、ローカルな情報しか使用できない。 応答には、エラー、回答、回答に"より近い"幾つかの他のサーバーへの 参照のどれかが含まれる([RFC1034]のセクション4.3.1参照)。 Iterative resolution(反復的名前解決): ネームサーバーは、他のサーバーにしか回答できない問い合わせを提示 されることがある。この問題に対処する二つの一般的なアプローチは、 最初のサーバーがクライアントに替わって他のサーバーへの問い合わせを 続行する"recursive(再帰)"と、サーバーがクライアントに別のサーバー を参照させ、クライアントに問い合わせを続行させる"iterative(反復)" である([RFC1034]のセクション2.3参照)。 反復的名前解決では、クライアントは非再帰的問い合わせを繰り返し作成 し、参照、別名のどちらかあるいは両方に追従する。反復的名前解決の アルゴリズムは、[RFC1034]のセクション5.3.3に記述されている。 Full resolver(フルリゾルバー): この用語は[RFC1035]で使用されているが、定義はされていない。RFC 1123は"フルサービスリゾルバー"を定義しているが、これが[RFC1035] の"フルリゾルバー"の意図したものと同じかどうかは定かでない。 この用語は、どのRFCでも適切に定義されていない。 Full-service resolver(フルサービスリゾルバー): [RFC1123]のセクション6.1.3.1は、この用語をキャッシュを使用し再帰 モードで動作する(ことに加えて他の要件も満たす)リゾルバーを意味 するものと定義している。 Priming(プライミング): "一部またはすべてのルートサーバーのIPアドレスだとされているものの 一部またはすべてを列挙した設定情報から、ルートサーバーの一覧を発見 する行為"([RFC8109]のセクション2から引用)。再帰モードで動作する には、リゾルバーはルートサーバーのアドレスを少なくとも一つ知って いる必要がある。プライミングは、ほとんどの場合ルートゾーンの権威 サーバー一覧を含む設定情報から実行される。 Root hints(ルートヒント): "DNS再帰リゾルバーを管理する運用者は、通常、'ルートヒントファイル' を設定する必要がある。このファイルは、ルートゾーンの権威ネーム サーバーの名前とIPアドレスを含むため、ソフトウェアはDNS名前解決 処理を起動できるようになる。多くのソフトウェアで、この一覧はソフト ウェアに組み込まれるようになってきている"([IANA RootFiles]から引用)。 このファイルは、しばしばプライミングで使用される。 Hoffman, et al. Best Current Practice [Page 18] RFC 8499 DNS Terminology January 2019 Negative caching(ネガティブキャッシュ): "何かが存在しない、回答が提供できないあるいは回答されないといった 情報の保存場所"([RFC2308]のセクション1から引用)。 Authoritative server(権威サーバー): "自身が保持する情報からDNSゾーンの内容を把握するため、そのゾーン に関する問い合わせに対して、他のサーバーに問い合わせをする必要なく 回答可能なサーバー"([RFC2182]のセクション2から引用)。権威サーバー は、ゾーンのNS("ネームサーバー")レコードで名前が示される。これは、 DNS問い合わせに対し、応答のヘッダーに含まれるAAフラグを1に設定して ゾーンに関する情報を回答するように設定されているシステムである。 一つ以上のDNSゾーンに対して権威を持つサーバーとも言える。権威 サーバーは、権威をそのサーバーに委任した親ゾーンが無くても問い合わせ に応答できることに注意せよ。権威サーバーは、"参照"も提供する。 通常、これはその権威サーバーから委任された子ゾーンである。 これらの参照は、AAビットを0に設定し、権威部と(必要に応じて) 付加情報部に参照データを保存して返される。 Authoritative-only server(専用権威サーバー): 権威を持つデータのみを提供し、再帰を伴うリクエストを無視するネーム サーバー。"通常の場合、自分ではどのような問い合わせも生成しない。 代わりに、自身が提供するゾーンの情報を検索する反復リゾルバーから の非再帰的問い合わせに対して回答する"([RFC4697]のセクション2.4から 引用)。ここで、"再帰を伴うリクエストを無視する"とは、"再帰を要求 するリクエストに対して再帰検索が実行されなかったことを示す応答を 返す"ことを意味する。 Zone transfer(ゾーン転送): クライアントがゾーンのコピーをリクエストし、権威サーバーが必要と される情報を送信するという動作(ゾーンの説明はセクション7を参照 せよ)。ゾーン転送のやり方には二つの標準的な方式がある。一つはゾーン すべてをコピーするAXFR方式("Authoritative Transfer(権威を持つゾーン 転送)")([RFC5936]に記載)で、もう一つは変更されたゾーンの一部だけを コピーするIXFR方式("Incremental Transfer(差分ゾーン転送)")([RFC 1995]に記載)である。多くのシステムは、DNSプロトコルの範囲外に ある非標準のゾーン転送方式を使用している。 Slave server(スレーブサーバー): "Secondary server(セカンダリサーバー)"を参照せよ。 Secondary server(セカンダリサーバー): "ゾーン転送を使用してゾーンを取得する権威サーバー"([RFC1996]の セクション2.1から引用)。セカンダリサーバーは[RFC1034]でも議論され ている。[RFC2182]は、セカンダリサーバーについてより詳細に記述して いる。[RFC1996]のような以前に発行されたDNS RFCでは、これを"slave (スレーブ)"と呼んでいたが、現在の一般的な用語法では"secondary (セカンダリ)"と呼ぶように変わっている。 Master server(マスターサーバー): "Primary server(プライマリサーバー)"を参照せよ。 Hoffman, et al. Best Current Practice [Page 19] RFC 8499 DNS Terminology January 2019 Primary server(プライマリサーバー): "一つ以上の[セカンダリ]サーバーに対してゾーン転送の転送源となる ように設定されたあらゆる権威サーバー"([RFC1996]のセクション2.1 から引用)。あるいは、[RFC2136]はより具体的に"一つ以上の[セカンダリ] サーバーに対してAXFRまたはIXFRのデータ転送源として設定された権威 サーバー"と述べている。プライマリサーバーは[RFC1034]でも議論され ている。[RFC1996]のような以前に発行されたDNS RFCでは、これを "master(マスター)"と呼んでいたが、現在の一般的な用語法では "primary(プライマリ)"と呼ぶように変わっている。 Primary master(プライマリマスター): "プライマリマスターは、ゾーンのSOA MNAMEフィールドに加えて、任意 でNS RRによって名前が示される"([RFC1996]のセクション2.1から引用)。 [RFC2136]は、"プライマリマスター"を"AXFR/IXFRの依存グラフのルート にあるマスターサーバー。プライマリマスターは、ゾーンのSOA MNAME フィールドに加えて、任意でNS RRによって名前が示される。定義により、 一つのゾーンについて一つのプライマリマスターしか存在できない"と定義 している。 プライマリマスターというアイディアは、[RFC1996]と[RFC2136]でしか 使用されていない。"プライマリマスター"という用語の現代的な解釈は、 ゾーンに対して権威を持ち、かつ(マスターファイルのような)設定情報 やUPDATE(更新)トランザクションに基づいてゾーンの更新を行うサーバー である。 Stealth server(ステルスサーバー): これは"ゾーンのNS RRに列挙されていないことを除けばスレーブサーバー のようなもの"である([RFC1996]のセクション2.1から引用)。 Hidden master(非公開マスター): ゾーン転送のプライマリサーバーとなるステルスサーバー。"この方式 を採用する場合、更新を行うマスターネームサーバーはNS RRsetに列挙 されないので、インターネット上の一般的なホストは利用できない" ([RFC6781]のセクション3.4.3から引用)。以前に発行された[RFC4641] は、非公開マスターの名前は"SOA RRのMNAMEフィールドに現れる"と 述べたが、一部の設定においては、その名前はパブリックDNSの中には 一切現れない。非公開マスターは、自身が提供するゾーンのセカンダリ サーバーになることもできる。 Forwarding(転送): あるサーバーがDNS問い合わせを名前解決するため、その問い合わせのRD ビットを1に設定して別のサーバーに送信する処理。転送はDNSリゾルバー の機能であり、問い合わせの無分別な中継とは異なる。 [RFC5625]は転送に関する特定の定義を与えないが、転送を行うシステム がサポートする必要のある機能を詳細に記述している。転送を行う システムは"DNSプロキシー"と呼ばれることもあるが、その用語は これまでにまだ定義されていない([RFC5625]でも)。 Hoffman, et al. Best Current Practice [Page 20] RFC 8499 DNS Terminology January 2019 Forwarder(フォワーダー): [RFC2308]のセクション1は、フォワーダーを"問い合わせの名前解決の際に 権威ネームサーバーの連鎖を直接たどる代わりに使用されるネームサーバー" と記述している。[RFC2308]は更に、"通常の場合、フォワーダーは インターネットへのアクセスがより良好であるか、多数のリゾルバーで 共有可能なより大きなキャッシュを保持しているかのどちらかである" とも述べている。この定義は、フォワーダーは通常、権威サーバーにしか 問い合わせしないと示唆しているように見える。しかし、現在の使用法では、 フォワーダーはしばしばスタブリゾルバーと再帰サーバーの間に配置される。 [RFC2308]は、フォワーダーが反復しか行わないリゾルバーなのか、フル サービスリゾルバーであってもよいのか等について何も述べていない。 Policy-implementing resolver(ポリシー実装リゾルバー): 再帰モードで動作するリゾルバーで、マルウェアサイトや好ましくない コンテンツへのアクセスを抑止するといったポリシー基準に基づき、返す 回答の一部を変更するもの。一般にスタブリゾルバーは、上流のリゾルバー がそのようなポリシーを実装しているかどうかや、実装している場合に 何が変更されるかに関する正確なポリシーは何もわからない。スタブ リゾルバーのユーザーが自分達のポリシーを実装するという明示的意図の もとにポリシー実装リゾルバーを選択して使用する場合もあるが、スタブ リゾルバーのユーザーに何も通知されないままポリシーが押し付けられる 場合もある。 Open resolver(オープンリゾルバー): (ほぼ)すべてのあらゆるスタブリゾルバーからの問い合わせを受理して処理 するフルサービスリゾルバー。"public resolver(パブリックリゾルバー)" と呼ばれることもある。しかし、"パブリックリゾルバー"という用語は、 オープンになるように意図的に設定されたオープンリゾルバーを指す ものとしてより頻繁に使用されるが、オープンリゾルバーの圧倒的多数 は、恐らくは誤ってオープンに設定されてしまったものである。 オープンリゾルバーについては、[RFC5358]で議論されている。 Split DNS(スプリットDNS): "split DNS(スプリットDNS)"及び"split-horizon DNS(スプリット ホライゾンDNS)"という用語は、公式な定義のないままDNSコミュニティ で長い間使用されてきている。一般にこれらの用語は、特定のドメイン の権威を持つDNSサーバーが、問い合わせの送信元に応じてそのドメインに 関する回答の一部またはすべてを異なる内容で提供する状況を参照する。 その効果は、概念的にはグローバルに一意なドメイン名であっても、 ネットワークユーザーごとに異なる意味を持つようになることである。 これは後に記述する"view(ビュー)"設定の結果である可能性がある。 [RFC2775]のセクション3.8は関連する定義を与えているが、一般的に 有用と言うには具体的過ぎる。 View(ビュー): "スプリットDNS"のように、DNSサーバーが問い合わせの属性に応じて異なる 応答を提供できるようにする設定。通常の場合、ビューは問い合わせの送信元 IPアドレスに応じて差別化されるが、宛先IPアドレスや問い合わせのタイプ (AXFRなど)、再帰的問い合わせかなどに基づく差別化も可能である。 Hoffman, et al. Best Current Practice [Page 21] RFC 8499 DNS Terminology December 2018 ビューは、大抵の場合、保護されたネットワークの"内側"からの問い合わせ に対し、そのネットワークの"外側"からの問い合わせよりも多くの名前や 異なるアドレスを提供するために使用される。ビューはDNSの標準化された 要素ではないが、サーバーソフトウェアに広く実装されている。 Passive DNS(パッシブDNS): ネームサーバーからのDNS応答を保存することにより、DNSデータを収集 する仕組み。これらのシステムの一部は、応答に関連するDNS問い合わせも 収集することから、若干のプライバシーの懸念が生じる。パッシブDNS データベースを使用することで、ある時点で存在していた値はどれか、 ある名前が初めて登録されたのはいつかといったDNSゾーンに関する歴史 的な質問に答えられるようになる。パッシブDNSデータベースは、例えば "特定の値のAレコードを持つ名前すべてを見つけよ"のように、名前と タイプ以外の検索キーで保存されたレコードを検索することもできる。 Anycast(エニーキャスト): "特定のサービスアドレスを複数の異なる自律的な場所で利用可能に しておき、送信されたデータグラムが複数の利用可能な場所の一つに 経路制御(route)されるようにする実践的行為"([RFC4786]のセクション2 から引用)。エニーキャストと、その用途に固有の他の用語に関する 詳細については、[RFC4786]を参照せよ。 Instance(インスタンス): "エニーキャスト経路制御を使用して、2台以上のサーバーが同じIP アドレスを保持できるようにしている場合、それらのサーバー群の個々 の1台は、一般に'インスタンス'と呼ばれる"。そして、次のように続け られる。"ルートサーバーのようなサーバーのインスタンスは、しばしば 'エニーキャストインスタンス'と呼ばれる"([RSSAC026]より引用)。 Privacy-enabling DNS server(プライバシー機能有効なDNSサーバー): "DNS over TLS[RFC7858]を実装しているDNSサーバー。任意でDNS over DTLS[RFC8094]を実装していてもよい"([RFC8310]のセクション2から 引用)。他のタイプのDNSサーバー、例えばDNS over HTTPS[RFC8484] を稼働させているサーバーもプライバシー機能有効と見なせるかも しれない。 7. ゾーン 本セクションは、ゾーンの提供またはゾーンの検索について議論する際に 使用される用語を定義する。 Zone(ゾーン): "権威を持つ情報はZONE(ゾーン)と呼ばれる単位に編成される。これら のゾーンは、ゾーン内のデータに冗長化サービスを提供する複数のネーム サーバーへと自動的に配付されるようにすることができる"([RFC1034] のセクション2.4から引用)。 Child(子): "Parent(親)からのドメインの委任情報を保持するレコードが提示する エンティティ"([RFC7344]のセクション1.1から引用)。 Hoffman, et al. Best Current Practice [Page 22] RFC 8499 DNS Terminology January 2019 Parent(親): "Child(子)が登録されるドメイン"([RFC7344]のセクション1.1から引用)。 以前は、[RFC882]で"親ネームサーバー"が定義されており、その定義は "ドメイン名空間内で新しいドメインを保持することになる場所に対する 権威を持つネームサーバー"となっていた。([RFC0882]は[RFC1024]及び [RFC1035]によって廃止されたことに注意せよ)。[RFC819]にも親と子の 関係に関する若干の記述がある。 Origin(起点): この用語には、以下に示すように、二つの異なる使用法がある。 (a) "ゾーンの先頭(ゾーンを親から分離するカットの直下)に現れる ドメイン名...ゾーン名はゾーンの起点のドメイン名と同じである" ([RFC2181]のセクション6から引用)。最近では、この意味で参照 される"起点"と"頂点"(この後に定義)は、しばしば互いに置き換え 可能なものとして使用される。 (b) ゾーンファイル内に任意の相対ドメイン名が現れるドメイン名。 一般に、マスターファイルフォーマットの一部として、[RFC1035] のセクション5.1で定義された制御エントリー、"$ORIGIN"の コンテキストの中で見られる。例えば、$ORIGINが"example.org." に設定されている場合、マスターファイル内にある"www"に関する 行は、実際には"www.example.org."に関するエントリーとなる。 Apex(頂点): ツリー内において、SOAの所有者及び対応する権威を持つNS RRsetが ある場所。"ゾーン頂点"と呼ばれることもある。[RFC4033]は、これを "ゾーンカットの子側の名前"と定義している。"頂点"はツリー構造の データ論的記述、"起点"はゾーンファイルに同じ概念が実装された際の 名前と考えると有用だろう。しかし、それらの用語を使用する際に、違い が常に維持されるわけではなく、この定義と微妙に矛盾する使用法を 見出すこともあるかもしれない。[RFC1034]は、"頂点"の同義語として "ゾーンのトップノード"という用語を使用しているが、この用語は広く 使用されていない。最近では、"起点"(上述)の一つ目の意味と"頂点" は、しばしば互いに置き換え可能なものとして使用されている。 Zone cut(ゾーンカット): 二つのゾーンの間を区切る場所。そこでは、片方のゾーンの起点がもう 片方のゾーンの子となる。 "ゾーンは'ゾーンカット'で区切られる。各ゾーンカットは'子'ゾーン (カットの下側)と'親'ゾーン(カットの上側)を分離する"。([RFC2181]の セクション6から引用。これはおよそ明示的とは言えない定義である ことに注意せよ)。[RFC1034]のセクション4.2は、"ゾーンカット"の 代わりに"カット"を使用している。 Hoffman, et al. Best Current Practice [Page 23] RFC 8499 DNS Terminology January 2019 Delegation(委任): 任意のドメインの頂点の下方にある名前空間内に独立したゾーンを作成 するための処理。委任は、子の起点に関するNS RRsetが親ゾーンに追加 された時点で生じる。その性質上、委任はゾーンカットで発生する。 この用語は一般に名詞でもあり、委任という行為によって生成される 新しいゾーンを指す。 Authoritative data(権威を持つデータ): "ゾーンのトップノードから、リーフノードまたはゾーン最下部を区切る カットの上側ノードに到るまでの全ノードに所属するRRすべて"([RFC1034] のセクション4.2.1から引用)。この定義に従うと、ゾーン内に現れるNS レコードは、たとえ同一のNS RRがゾーンカット下方にあるため本当は 権威を持たないかもしれないものがあったとしても、あらゆるものが 誤って含まれてしまう可能性があることに注意せよ。これは、権威を 持つデータという概念のあいまいさを露呈させるものである。親側の NSレコードは、それ自体権威を持つデータではないにしても、権威を 以て委任を提示するからである。 [RFC4033]のセクション2は"権威を持つRRset"を定義している。これは 権威を持つデータに関連するが、より正確な定義がなされている。 Lame delegation(レイムデレゲーション): "ネームサーバーが(NSレコードを介して)ゾーンのネームサービスを提供 する責任を委任されているにもかかわらず、そのゾーンのネームサービス を実行していない場合(その理由は、大抵の場合、ゾーンのプライマリ またはセカンダリとして設定されていないためである)、レイム デレゲーションが存在するという"([RFC1912]のセクション2.8から引用)。 別の定義には次のものもある。レイムデレゲーションは、"あるドメイン のNSレコードにネームサーバーが列挙されているが、実際にはその ドメインのサーバーではない場合に発生する。結果として、問い合わせは、 問い合わされたドメインに関して何も知らない(少なくとも期待どおりの ものではない)誤ったサーバーに送信される。更に、これらのホストは (存在しているとして、だが!)、ネームサーバーを稼働させていないこと さえある"([RFC1713]のセクション2.3から引用)。 Glue records(グルーレコード): "...[ゾーンの]権威を持つデータの一部ではなく、[サブゾーンに]属する [ネーム]サーバーのアドレスRRを提供する[リソースレコード]。これら のRRは、ネームサーバーの名前がカットの'下位'にある場合にのみ必要 で、参照応答の一部としてのみ使用される"。グルーがないと、"ネーム サーバーのアドレスを知るためには、その知りたいアドレスを使用して サーバーにコンタクトしなければならない、とNS RRが通知してくる ような状況が生じ得る"([RFC1034]のセクション4.2.1から引用)。 後になされた定義では、グルーは、"ゾーンファイル内に存在するが、厳密 にはそのゾーンの一部ではないあらゆるレコードで構成される。具体的 に、委任されたサブゾーンのネームサーバー(NS)レコードや、そのNS レコードに付随するアドレスレコード(A、AAAAなど)、その他ゾーンに 現れるかもしれないがゾーンには属さないあらゆるデータなどが含まれる" ([RFC2181]のセクション5.4.1から引用)。 Hoffman, et al. Best Current Practice [Page 24] RFC 8499 DNS Terminology January 2019 今日、グルーはこのより広い定義を念頭に置いて使用されることもある が、[RFC2181]の定義部分周辺のコンテキストは、グルーという用語の 使用範囲は同文書の中だけであり、それ以外の場所は必ずしも意図 されていなかったことを示唆している。 Bailiwick(管轄区域): "in-bailiwick(管轄区域内にある=内部名)"は、ネームサーバーの名前 が、そのネームサーバーへの委任を含むゾーンの起点のサブドメインに なっているか、(まれに)同じ名前になっているかのどちらかであること を示す修飾語である。内部名のネームサーバーは、親ゾーンにグルー レコードを保持する場合がある(上記の"グルーレコード"の最初の定義 を使用)。("bailiwick(管轄区域)"という用語は、執行官または警察官 が管轄権を持つ区域、地域を意味する)。 "内部名"のネームサーバー名は、更に"in-domain(インドメイン)"の 名前と"sibling domain(シブリングドメイン)"のの名前の2種類に 分けられる。 ・ インドメイン: ネームサーバーの名前が、NSリソースレコードの 所有者名の下位に位置するか(まれだが)同じであるかのどちらかで あることを表現する修飾語。インドメインのネームサーバーはグルー レコードを持つ必要があり、持たない場合には名前解決に失敗する。 例えば、"child.example.com"への委任は、"インドメイン"のネーム サーバー名"ns.child.example.com"を持つかもしれない。 ・ シブリングドメイン: ネームサーバーの名前が、ゾーンの起点の下位 に位置するか(まれだが)同じであるかのどちらかであり、かつそれは NSリソースレコードの所有者名とは異なり、その下位に位置するもの でもないことを表現する。シブリングドメインに関するグルーレコード は許容されるが必須ではない。例えば、"example.com"ゾーンにおける "child.example.com"への委任は、"シブリング"のネームサーバー名 "ns.another.example.com"を持つかもしれない。 "out-of-bailiwick(管轄区域外にある=外部名)"は、"内部名"の反意語 である。具体的に、ネームサーバーの名前がゾーンの起点の下位には位置 せず、またゾーンの起点と同じでもないことを表現する修飾語である。 外部名のネームサーバーに関するグルーレコードは無益である。以下の 表は、委任タイプの例を示すものである。 委任 | 親 | ネームサーバー名 | タイプ -----------+------+------------------+----------------------------- com | . |a.gtld-servers.net|内部名 / シブリングドメイン net | . |a.gtld-servers.net|内部名 / インドメイン example.org| org |ns.example.org |内部名 / インドメイン example.org| org |ns.ietf.org |内部名 / シブリングドメイン example.org| org |ns.example.com |外部名 example.jp | jp |ns.example.jp |内部名 / インドメイン example.jp | jp |ns.example.ne.jp |内部名 / シブリングドメイン example.jp | jp |ns.example.com |外部名 Hoffman, et al. Best Current Practice [Page 25] RFC 8499 DNS Terminology January 2019 Root zone(ルートゾーン): DNSベースのツリーのゾーンで、頂点が長さゼロのラベルであるもの。 "DNSルート"と呼ばれることもある。 Empty non-terminals (ENT)(空の非終端ドメイン名): "自身はリソースレコードを持たないが、そのサブドメインがリソース レコードを持つドメイン名"([RFC4592]のセクション2.2.2から引用)。 典型的な例をSRVレコードで示す。"_sip._tcp.example.com"という名前 において、"_tcp.example.com"はRRsetを持っていない可能性があるが、 "_sip._tcp.example.com"は(少なくとも)SRV RRsetを持つ。 Delegation-centric zone(委任が主たる内容のゾーン): 大部分が子ゾーンへの委任で構成されるゾーン。この用語は、子ゾーン への委任を幾つか持つが、同時にそのゾーン自身と子ゾーンのどちらか あるいは両方に関する大量のデータリソースレコードを持つゾーンと対照 をなして使用される。この用語は[RFC4956]と[RFC5155]で使用されている が、どちらの文書でも定義されていない。 Occluded name(遮蔽された名前): "動的更新によって委任点を追加すると、すべての下位ドメインの名前が 中途半端な状態(limbo)、すなわちゾーンの一部ではあるが検索処理から は見えないという状態になる。DNAMEリソースレコードの追加も同じ影響 がある。そのような下位の名前は'occluded(遮蔽されている)'という" ([RFC5936]のセクション3.5から引用)。 Fast flux DNS(短時間で応答が変化するDNS): これは、"DNSで[見つかった]ドメイン名が複数のIPアドレスに対応する 複数のAレコードを保持しており、かつそのAレコードのどれもが非常に 短いTTL値を関連付けられている場合に発生する。これは、そのドメイン 名が短い期間内にさまざまなIPアドレスに解決されることを意味する"([RFC 6561]のセクション1.1.5から引用。誤字訂正済)。正当な使用法に加えて、 これを使用したマルウェアの配送も可能である。なぜなら、アドレスが 極めて速く変化するため、すべてのホストを突き止めるのは困難になるから である。この技法はAAAAレコードでも機能するが、本文書執筆時点に おいて、そのような使用法はインターネット上でほとんど観測されて いないことに留意すべきである。 Reverse DNS, reverse lookup(逆引きDNS、逆引き検索): "アドレスを名前にマッピングする処理は、一般に'逆引き検索'として 知られており、IN-ADDR.ARPAゾーン及びIP6.ARPAゾーンは'逆引きDNS' をサポートするためのものであると言われている"([RFC5855]の セクション1から引用)。 Forward lookup(正引き検索): "ホスト名からアドレスへの変換"([RFC3493]のセクション6から引用)。 arpa: アドレス及び経路制御(routing)のパラメーターエリアドメイン: "'arpa' ドメインは、当初DNSの初期展開の一環として確立されたものである。 Hoffman, et al. Best Current Practice [Page 26] RFC 8499 DNS Terminology January 2019 その目的は、ARPANETで一般的であったホストテーブルからの変換手段の 提供、及びIPv4への逆方向のマッピングを行うドメインの起点の提供 であった。2000年に、この略語は、以前のネットワーク名との混同が低減 されることを願って、"Address and Routing Parameter Area"を縮めた ものであると再指定された([RFC3172]のセクション2から引用)。.arpaは "基盤ドメイン"、つまり"インターネットの運用基盤をサポートする役割" のドメインである([RFC3172]のセクション2から引用)。この名前の歴史 に関するさらなる情報については[RFC3172]を参照せよ。 Service name(サービス名): "サービス名は、サービス名及びトランスポートプロトコルポート番号 レジストリにおける一意な検索キーである。サービスに関するこの一意な シンボリック名は、DNS SRVレコードなど他の目的でも使用される場合が ある"([RFC6335]のセクション5から引用)。 8. ワイルドカード Wildcard(ワイルドカード): [RFC1034]は"ワイルドカード"を定義したが、それは実装者を混乱させる 結果となるようなものだった。より明確な定義を含むワイルドカードに 関する広範な議論については[RFC4592]を参照せよ。ラベル"*"で始まる 所有者名を持つRRには特別な処理が行われる。"そのようなRRは'ワイルド カード'と呼ばれる。ワイルドカードRRは、RRを合成する指示であると 考えられる"([RFC1034]のセクション4.3.3から引用)。 Asterisk label(アスタリスクラベル): "第1オクテットは通常のラベルタイプで1オクテット長のラベルである ことを示しており、第2オクテットは'*'文字のASCII表現になっている [RFC20]。この値と等しいラベルを表現する名前が'アスタリスクラベル' である"([RFC4592]のセクション2.1.1から引用)。 Wildcard domain name(ワイルドカードドメイン名): "'ワイルドカードドメイン名'は、先頭の(最左端または最下位)ラベル がアスタリスクラベルであるもの、具体的に、バイナリーフォーマット で0000 0001 0010 1010(2進)=0x01 0x2a(16進)となっているものと 定義する"([RFC4592]のセクション2.1.1から引用)。このラベルの第2 オクテットは、"*"文字のASCII表現になっている。 Closest encloser(最近接名): "ある名前の実在する先祖(訳注: 親、親の親等)の中で最も長いもの" ([RFC5155]のセクション1.3から引用)。それ以前の定義は、"実在する ドメイン名のゾーンの木構造内にあるノードで、問い合わせ名にラベル が(ルートラベルから下方に向けて連続して)最もマッチするもの。ここ で、マッチとは'ラベルが一致'し、かつラベルの順序が同じであること を意味する"([RFC4592]のセクション3.3.1から引用)。 Closest provable encloser(証明可能な最近接名): "名前の先祖の中で最も長く、存在証明が可能なもの。これが最近接名 と異なるのはOpt-Outゾーンの中だけであることに注意せよ"([RFC5155] のセクション1.3から引用)。 Hoffman, et al. Best Current Practice [Page 27] RFC 8499 DNS Terminology January 2019 "opt-out"についての詳細は本文書のセクション10を参照せよ。 Next closer name(次近接名): "ある名前の証明可能な最近接名より1ラベル長い名前"([RFC5155]の セクション1.3から引用)。 Source of Synthesis(合成源): "合成源は、問い合わせ処理のコンテキストにおいて、最近接名の直下に ワイルドカードドメイン名が存在する場合に、そのワイルドカード ドメイン名を指すと定義される。ここで、'直下に'とは、合成源が <アスタリスクラベル>.<最近接名>の形式の名前を持つことを意味する ([RFC4592]のセクション3.3.1から引用)。 9. 登録モデル Registry(レジストリ): ゾーンに名前を登録できるようにするゾーンの管理作業。この用語は、 しばしば(TLDのような)委任が主たる内容の大規模ゾーンで登録作業を 行う組織だけを参照するために使用される。しかし正式には、どの データをゾーンに加えるかを決定する主体は、すべてそのゾーンの レジストリである。この"レジストリ"の定義は、DNSの観点に由来する。 一部のゾーンでは、ゾーンに加えられるものは何かを決定するポリシー は、レジストリ運用者ではなく上位ゾーンによって決定される。 Registrant(登録者): 個人または組織。レジストリは彼らを代行してゾーンに名前を登録する。 多くのゾーンでレジストリと登録者は同じエンティティになるだろうが、 TLDの場合、大抵そうはならない。 Registrar(レジストラ): 登録者とレジストリの間で仲介者の役目を務めるサービス提供者。 すべての登録がレジストラを必要とするわけではないが、TLDの場合、 レジストラを登録に関与させるのが一般的である。 EPP: 拡張可能な資源登録プロトコル(EPP)。一般にレジストリとレジストラ 間の登録情報の通信に使用される。EPPは[RFC5730]で定義されている。 WHOIS: [RFC3912]で規定されているプロトコル。大抵レジストリデータベース への問い合わせに使用される。WHOISデータは、(ゾーン管理者の連絡先と いった)登録データとドメイン名を関連付けるために頻繁に使用される。 "WHOISデータ"という用語はしばしばレジストリデータベースの同義語 として使用されるが、レジストリデータベースは異なるプロトコル、 特にRDAPによって提供される場合もある。WHOISプロトコルは、IP アドレスのレジストリデータでも使用される。 Hoffman, et al. Best Current Practice [Page 28] RFC 8499 DNS Terminology January 2019 RDAP: 登録データアクセスプロトコル(The Registration Data Access Protocol) の略称で、[RFC7480]、[RFC7481]、[RFC7482]、[RFC7483]、[RFC7484]、 [RFC7485]で定義される。RDAPプロトコル及びデータフォーマットは、 WHOISの置き換えが意図されている。 DNS operator(DNS運用者): DNSサーバー稼働の責任を負うエンティティ。ゾーンの権威サーバーの 場合、登録者自らがDNS運用者となることもあるし、レジストラが登録者 の代わりにDNS運用者となる場合もある。あるいは、サードパーティーの DNS運用者を使用することもある。幾つかのゾーンでは、DNS運用者に ゾーン内容の許認可を行う他のエンティティが加わった共同体により、 レジストリ機能が実行される。 Public suffix: "パブリックレジストリに管理されるドメイン"([RFC6265]のセクション 5.3から引用)。この用語の一般的な定義は、サードパーティーが下位に サブドメインを登録できるドメイン名で、HTTPクッキー(詳細は[RFC 6265]に記述)が設定されるべきでないものである。ドメイン名の中には、 それがpublic suffixであるかを示す情報は存在せず、外部的な手段で しか判定できない。実際、あるドメインとそのサブドメインのどちら もがpublic suffixという状況もあり得る。 ドメイン名がもともと保持する特性の中に、それがpublix suffixかを 示す情報はない。public suffixを識別するリソースの一つは、Mozilla によって維持されているPublic Suffixリスト(PSL) (http://publicsuffix.org/)である。 例えば、本文書の発行時点では、"com.au"ドメインはpublix suffixと してPSLに列挙されている。(この例は将来変更される可能性があること に注意せよ)。 "public suffix"という用語は、多くの理由からDNSコミュニティにおいて 議論の的になっており、将来大幅に変更されるかもしれないことに注意 せよ。あるドメインをpublic suffixと呼ぶことが困難な例の一つとして、 2014年の"uk"TLDの事例のように、ゾーンの登録ポリシーの変更といった 理由で、指定対象が時間と共に変化することが挙げられる。 Subordinate(下位)及びSuperordinate(上位): これらの用語は、[RFC5731]において登録モデルでの使用のために導入 されたが、定義はされていない。代わりに、それらは例の中で与えられ ている。"例えば、ドメイン名'example.com'はホスト名'ns1.example. com'に対して上位の関係にある...。例えば、ホストns1.example1.com はドメインexample1.comの下位ホストだが、ドメインexample2.comの 下位ホストではない"([RFC5731]のセクション1.1から引用)。これらの 用語は、一方が他方のサブドメインである二つのドメインの関係を厳密 に参照する方法である。 Hoffman, et al. Best Current Practice [Page 29] RFC 8499 DNS Terminology January 2019 10. 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 関連文書の数カ所で使用されていながらも、RFCによる定義がないもの だが、本文書の中で後ほど定義されることに注意せよ)。 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の仕組みについて、追加 の背景説明とこれまでの経緯を提供している。NSECとNSEC3は後ほど記述 される。 Unsigned zone(未署名ゾーン): [RFC4033]のセクション2は、この用語を"署名されていないゾーン"と定義 している。[RFC4035]のセクション2は、この用語を"本セクションで規定 されるルールに従うこれらのレコード[適切に構成されたDNSKEYレコード、 RRSIGレコード、NSECレコードすべてと、(任意で)DSレコード]を持たない ゾーン..."と定義している。[RFC4035]のセクション5.2の終わりに、 ゾーンが未署名とみなされる追加の状況を定義する重要な注記があり、 次のように述べられている。"リゾルバーが認証済みのDS RRsetに列挙 されたアルゴリズムをどれもサポートしない場合、そのリゾルバーは 子ゾーンへの認証経路を検証できない。この場合、リゾルバーは子ゾーン を未署名であるかのように処理すべきである(SHOULD)"。 Hoffman, et al. Best Current Practice [Page 30] RFC 8499 DNS Terminology January 2019 NSEC: "NSECレコードにより、DNSSEC対応リゾルバーは、名前またはタイプの どちらかの不在を示すネガティブ応答を他のDNS応答を認証するのと同じ 仕組みで認証できるようになる"([RFC4033]のセクション3.2から引用)。 要するに、NSECレコードは不在証明を提供する。 "NSECリソースレコードは二つの独立した情報を提示する。一つめは、権威 を持つデータまたは委任点のNS RRsetを持つ(ゾーンの正規順序で)次の 所有者名である。二つめは、NSEC RRの所有者名に関連づけられるRRタイプ の集合である"(RFC 4034のセクション4から引用)。 NSEC3: NSEC3レコードもNSECレコードのように不在証明を提供するが、NSEC3 レコードはゾーン列挙の効果を抑制し、オプトアウトもサポートする。 NSEC3リソースレコードは、関連するNSEC3PARAMリソースレコードを必要 とする。NSEC3リソースレコード及びNSEC3PARAMリソースレコードは、 [RFC5155]で定義される。 [RFC6840]において、[RFC5155]は"[RFC4033]のセクション10に記載されて いるDNSSEC関連文書の一部であると現在では見なされている"と述べられ ていることに注意せよ。これは、以前に発行されたRFCの幾つかの定義に おけるNSECレコードだけに関する記述は、恐らくNSECとNSEC3の両方に ついて述べていると見なされるべきであることを意味する。 Opt-out(オプトアウト): "オプトアウトフラグは、そのNSEC3 RRが未署名委任をカバーしているか どうかを示す"([RFC5155]のセクション3.1.2.1から引用)。オプトアウト は、安全でない(insecure)ゾーンへの委任を署名で保護すると高コストに なる問題に対処するものである。オプトアウトを使用すると、安全でない 委任(及び安全でない委任からしか生じない空の非終端)の名前について はNSEC3レコードや関連するRRSIGレコードが不要となる。オプトアウト NSEC3レコードは、安全でない委任の存在や不在を証明できない ([RFC7129]のセクション5.1を編集)。 Insecure delegation(安全でない委任): "委任(NS RRset)を含むがDS RRsetがないことから、未署名なサブゾーン への委任を意味する署名された名前"([RFC4956]のセクション2から引用)。 Zone enumeration(ゾーン列挙): "連続した問い合わせを介してゾーンの全内容を見破ろうとする行為" ([RFC5155]のセクション1.3から引用)。"ゾーンウォーキング"と呼ばれる こともある。ゾーン列挙は、推測者があり得そうなラベルの巨大な辞書 を使用し、それらのラベルに対して連続して問い合わせを送信したり、 NSEC3レコードの内容を辞書とマッチングさせたりするゾーンコンテンツ の推測とは異なる。 Hoffman, et al. Best Current Practice [Page 31] RFC 8499 DNS Terminology January 2019 Validation(検証): 検証という用語は、DNSSECのコンテキストでは、以下の一つを参照する。 ・ DNSSEC署名の有効性を検査すること。 ・ DNS応答が不在証明を含む場合などに、その有効性を検査すること。 ・ トラストアンカーからDNS応答または応答に含まれる個々のDNS RRset まで認証の連鎖を構築すること。 初めの二つの定義は、個々のDNSSEC構成要素の有効性だけを考慮する。 例えば、RRSIGの有効性やNSECの証明の有効性といったものである。 これに対し、三つめの定義は、DNSSECの認証の連鎖に関与するすべての構成 要素を考慮する。従って、([RFC4035]のセクション5に記述される ように)"少なくとも一つ、認証されたDNSKEYまたはDS RRを設定情報と して必要とする"。 [RFC4033]のセクション2では、"署名を検証するスタブリゾルバーは... 署名検証を実行"し、トラストアンカーを"署名されたDNS応答に到る認証 の連鎖を構築する起点として"使用すると述べている。従って、上の 一つめ及び三つめの定義を使用している。RRSIGリソースレコードを検証 する手順は、[RFC4035]のセクション5.3に記述されている。 [RFC5155]は、ハッシュ化された不在証明というコンテキストで、文書 全体を通して応答の検証について言及しており、そこでは上の二つめの 定義を使用している。 "authentication(認証)"という用語は、"validation(検証)"の三つめの 定義の意味と互いに置き換え可能なものとして使用される。[RFC4033] のセクション2では、トラストアンカーからDNSデータまでつながる連鎖 を"authentication chain(認証の連鎖)"と記述している。"応答の回答 部及び権威部に含まれるすべてのRRsetが信頼できる[と見なされる]" ならば、その応答は信頼できると見なされる([RFC4035]から引用)。 セキュリティ状態が"Secure"なDNSデータまたはDNS応答は、信頼できる または検証済みであると見なされる([RFC4035]のセクション4.3、[RFC 4033]のセクション5)。"DNSの認証鍵やデータを認証するかどうかは、 どちらもローカルポリシーの問題である。ローカルポリシーは、 [DNSSEC]プロトコル拡張の効果を更に拡大する場合もあり無効にする 場合もある..."([RFC4033]のセクション3.1から引用)。 "verification(検証)"という用語が使用される場合、大抵は "validation(検証)"の同義語である。 Hoffman, et al. Best Current Practice [Page 32] RFC 8499 DNS Terminology January 2019 Validating resolver(署名を検証するリゾルバー): 名前解決のコンテキストに応じて(上記の)検証の定義のうち少なくとも 一つを適用する、DNSSEC対応再帰ネームサーバー、DNSSEC対応リゾルバー、 DNSSEC対応スタブリゾルバーのいずれか。一般的な用語"リゾルバー"が 時折あいまいで、コンテキストの中で評価される必要がある(セクション 6参照)のと同じ理由で、"署名を検証するリゾルバー"もコンテキストに 左右される用語である。 Key signing key (KSK)(鍵署名鍵): "ゾーン頂点のDNSKEY RRsetのみを署名する"DNSSEC鍵([RFC6781]の セクション3.1から引用)。 Zone signing key (ZSK)(ゾーン署名鍵): "ゾーン頂点のDNSKEY RRsetを除くゾーンのRRsetの中で、署名が必要な すべてのRRsetへの署名に使用できるDNSSEC鍵"([RFC6781]のセクション3.1 から引用)。頂点の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と して不適格であるという判定には使用できないことに注意せよ。 SEPのオリジナルの定義は[RFC3757]でなされた。その定義は、SEPは鍵 であり、鍵に含まれるビットではないと明記している。[RFC3757]の要旨 は次のように述べている。"DS(Delegation Signer)リソースレコード (RR)により、セキュアエントリーポイント(SEP)として機能する公開鍵 の概念が導入された。親と公開鍵をやりとりする際に、SEP鍵をDNSKEY (Domain Name System KEY)リソースレコードセット内の他の公開鍵と 区別する必要がある。DNSKEYがSEPとして使用されることを示すため に、DNSKEY RR内のフラグビットが定義される"。 Hoffman, et al. Best Current Practice [Page 33] RFC 8499 DNS Terminology January 2019 鍵としてのSEPの定義は[RFC4034]によって廃止となり、[RFC6781]に 由来する定義は[RFC4034]と整合している。 Trust anchor(トラストアンカー): "設定として与えられるDNSKEY RRまたはDNSKEY RRのハッシュを持つDS RR。署名を検証するDNSSEC対応リゾルバーは、署名されたDNS応答に到る 認証の連鎖を構築する際に、この公開鍵またはハッシュを起点として 使用する。一般に、署名を検証するリゾルバーは、DNSプロトコル以外 の安全なあるいは信頼できる手段でトラストアンカーの初期値を入手 しなければならない"([RFC4033]のセクション2から引用)。 DNSSEC Policy (DP)(DNSSECポリシー): "DNSSECの署名ゾーンに実装されるセキュリティ要件と標準を明記する" 声明([RFC6841]のセクション2から引用)。 DNSSEC Practice Statement (DPS)(DNSSEC運用ステートメント): "(存在する場合)DNSSECポリシーをサポート、補完する運用実務の開示 文書。所定のゾーン管理方針がどのように手続きや管理を高水準で実装 するかを述べたもの"([RFC6841]のセクション2から引用)。 Hardware security module (HSM)(ハードウェアセキュリティモジュール): 秘密鍵を一切暴露させずに署名用の鍵を作成してメッセージに署名する ために使用される専用ハードウェア。DNSSECでは、HSMは、KSKとZSKの 秘密鍵を保持し、一定周期でRRSIGレコードに保持される署名を作成する ために使用される。 Signing software(署名ソフトウェア): DNSSECをサポートする権威サーバーは、大抵の場合、ゾーン内のDNSSEC 署名の生成と維持を容易にするソフトウェアを含んでいる。一方で、 権威サーバーそれ自体が署名をサポートしているかどうかにかかわらず、 ゾーンに署名するために使用可能なスタンドアローンなソフトウェアも 存在する。署名ソフトウェアが署名処理の一環として特定のHSMをサポート することもある。 11. DNSSECの状態 署名を検証するリゾルバーは、応答が四つの状態、Secure、Insecure、 Bogus、Indeterminateの一つであると判断することができる。これらの状態 は[RFC4033]と[RFC4035]で定義されているが、これら二つの文書の定義は 若干異なる。本文書は二つの定義を調整するための努力はせず、調整される 必要があるかどうかについても見解は示さない。 Hoffman, et al. Best Current Practice [Page 34] RFC 8499 DNS Terminology January 2019 [RFC4033]のセクション5は以下のように述べている。 署名を検証するリゾルバーは、以下の四つの状態を判定することが できる。 Secure: 署名を検証するリゾルバーがトラストアンカーを持ち、信頼の連鎖 を構築しており、応答に含まれる署名をすべて検証可能な状態。 Insecure: 署名を検証するリゾルバーがトラストアンカーを持ち、信頼の連鎖 を構築しているが、幾つかの委任点でDSレコードの不在が証明されて いる状態。これは、DNSツリーにおいて、DS不在の分岐節下位の空間 は安全ではないと判明していることを示している。署名を検証する リゾルバーは、ドメイン空間の一部を安全でないとマークする ローカルポリシーを設定してもよい。 Bogus: 署名を検証するリゾルバーがトラストアンカーを持ち、子側のデータ が署名されていることを示す安全な委任を確認しているが、応答の 署名検証には失敗した状態。署名検証に失敗する理由は幾つか考え られる。例えば署名の消失、署名の期限切れ、署名で使われている アルゴリズムをサポートしていない、NSEC RRは存在すると主張して いるデータが実際にはない等が挙げられる。 Indeterminate: DNSツリーの特定の一部が安全であることを示すトラストアンカー が全く存在しない状態。これがデフォルトの運用モードである。 [RFC4035]のセクション4.3は以下のように述べている。 DNSSEC対応リゾルバーは、(あるRRsetが署名検証の対象であるかどうかを 判定するにあたり)以下の四つの場合を識別できなければならない。 Secure: トラストアンカーを起点として、署名されたDNSKEY RRと対応する DS RRの連鎖を構築可能なRRset。この場合、そのRRsetは署名されて いるはずなので、先に記述した署名検証の対象となる。 Insecure: どのトラストアンカーを起点としても、署名されたDNSKEY RRと対応 するDS RRの連鎖が構築できないことをリゾルバーが認識している RRset。対象のRRsetが未署名ゾーンに存在したり、未署名ゾーンの 下位に存在する場合にこのような状況が生じ得る。この場合、RRset は署名されているかもしれないし、未署名かもしれないが、いずれに せよリゾルバーは署名を検証できない。 Hoffman, et al. Best Current Practice [Page 35] RFC 8499 DNS Terminology January 2019 Bogus: リゾルバーは信頼の連鎖を構築できるはずだと信じていたが、何らか の理由で署名検証に失敗したか、関連するDNSSEC RRが存在するはず だと主張するデータが存在しなかったか、いずれかの理由により、 信頼の連鎖が構築できないRRset。このような状況は、攻撃を示唆 している場合もあるが、設定エラーや何らかのデータ破損を示唆する 場合もある。 Indeterminate: リゾルバーが必要なDNSSEC RRを得られないため、署名されている べきものなのかどうかが判断できないRRset。DNSSEC対応リゾルバー が署名ゾーンを管理するDNSSEC対応ネームサーバーにアクセス できない場合にこのような状況が生じ得る。 12. セキュリティに関する考慮点 本文書の定義は、DNSのセキュリティに関するどの考慮点も変更しない。 13. IANAに関する考慮点 本文書はIANAの作業を何も要求しない。 14. References 14.1. Normative References [IANA_RootFiles] IANA, "Root Files", . [RFC0882] 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, . [RFC1912] Barr, D., "Common DNS Operational and Configuration Errors", RFC 1912, DOI 10.17487/RFC1912, February 1996, . Hoffman, et al. Best Current Practice [Page 36] RFC 8499 DNS Terminology January 2019 [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, . [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, . Hoffman, et al. Best Current Practice [Page 37] RFC 8499 DNS Terminology January 2019 [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive Nameservers in Reflector Attacks", BCP 140, RFC 5358, DOI 10.17487/RFC5358, October 2008, . [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, . [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, DOI 10.17487/RFC5731, August 2009, . [RFC5855] Abley, J. and T. Manderson, "Nameservers for IPv4 and IPv6 Reverse Zones", BCP 155, RFC 5855, DOI 10.17487/RFC5855, May 2010, . [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, . [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, . [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, . Hoffman, et al. Best Current Practice [Page 38] RFC 8499 DNS Terminology January 2019 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating DNSSEC Delegation Trust Maintenance", RFC 7344, DOI 10.17487/RFC7344, September 2014, . [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2015, . [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles for DNS over TLS and DNS over DTLS", RFC 8310, DOI 10.17487/RFC8310, March 2018, . 14.2. Informative References [IANA_Resource_Registry] IANA, "Resource Record (RR) TYPEs", . [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, . [RFC1713] Romao, A., "Tools for DNS debugging", FYI 27, RFC 1713, DOI 10.17487/RFC1713, November 1994, . [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, DOI 10.17487/RFC1995, August 1996, . [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, DOI 10.17487/RFC2775, February 2000, . [RFC3172] Huston, G., Ed., "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, September 2001, . Hoffman, et al. Best Current Practice [Page 39] RFC 8499 DNS Terminology January 2019 [RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425, DOI 10.17487/RFC3425, November 2002, . [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, DOI 10.17487/RFC3493, February 2003, . [RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", RFC 3757, DOI 10.17487/RFC3757, April 2004, . [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, . Hoffman, et al. Best Current Practice [Page 40] RFC 8499 DNS Terminology January 2019 [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, . [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, . [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC 6303, DOI 10.17487/RFC6303, July 2011, . [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, . [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in Internationalization in the IETF", BCP 166, RFC 6365, DOI 10.17487/RFC6365, September 2011, . [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, . [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, . Hoffman, et al. Best Current Practice [Page 41] RFC 8499 DNS Terminology January 2019 [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, . [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, . [RFC7793] Andrews, M., "Adding 100.64.0.0/10 Prefixes to the IPv4 Locally-Served DNS Zones Registry", BCP 163, RFC 7793, DOI 10.17487/RFC7793, May 2016, . [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, . [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram Transport Layer Security (DTLS)", RFC 8094, DOI 10.17487/RFC8094, February 2017, . Hoffman, et al. Best Current Practice [Page 42] RFC 8499 DNS Terminology January 2019 [RFC8109] Koch, P., Larson, M., and P. Hoffman, "Initializing a DNS Resolver with Priming Queries", BCP 209, RFC 8109, DOI 10.17487/RFC8109, March 2017, . [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, . [RSSAC026] Root Server System Advisory Committee (RSSAC), "RSSAC Lexicon", 2017, . Hoffman, et al. Best Current Practice [Page 43] RFC 8499 DNS Terminology January 2019 Appendix A. Definitions Updated by This Document The following definitions from RFCs are updated by this document: o Forwarder in [RFC2308] o QNAME in [RFC2308] o Secure Entry Point (SEP) in [RFC3757]; note, however, that this RFC is already obsolete (see [RFC4033], [RFC4034], [RFC4035]). Appendix B. Definitions First Defined in This Document The following definitions are first defined in this document: o "Alias" in Section 2 o "Apex" in Section 7 o "arpa" in Section 7 o "Bailiwick" in Section 7 o "Class independent" in Section 5 o "Delegation-centric zone" in Section 7 o "Delegation" in Section 7 o "DNS operator" in Section 9 o "DNSSEC-aware" in Section 10 o "DNSSEC-unaware" in Section 10 o "Forwarding" in Section 6 o "Full resolver" in Section 6 o "Fully-qualified domain name" in Section 2 o "Global DNS" in Section 2 o "Hardware Security Module (HSM)" in Section 10 o "Host name" in Section 2 o "IDN" in Section 2 Hoffman, et al. Best Current Practice [Page 44] RFC 8499 DNS Terminology January 2019 o "In-bailiwick" in Section 7 o "Iterative resolution" in Section 6 o "Label" in Section 2 o "Locally served DNS zone" in Section 2 o "Naming system" in Section 2 o "Negative response" in Section 3 o "Non-recursive query" in Section 6 o "Open resolver" in Section 6 o "Out-of-bailiwick" in Section 7 o "Passive DNS" in Section 6 o "Policy-implementing resolver" in Section 6 o "Presentation format" in Section 5 o "Priming" in Section 6 o "Private DNS" in Section 2 o "Recursive resolver" in Section 6 o "Referrals" in Section 4 o "Registrant" in Section 9 o "Registrar" in Section 9 o "Registry" in Section 9 o "Root zone" in Section 7 o "Secure Entry Point (SEP)" in Section 10 o "Signing software" in Section 10 o "Split DNS" in Section 6 o "Stub resolver" in Section 6 Hoffman, et al. Best Current Practice [Page 45] RFC 8499 DNS Terminology January 2019 o "Subordinate" in Section 8 o "Superordinate" in Section 8 o "TLD" in Section 2 o "Validating resolver" in Section 10 o "Validation" in Section 10 o "View" in Section 6 o "Zone transfer" in Section 6 Index A Address records 16 Alias 9 Anycast 22 Apex 23 Asterisk label 27 Authoritative data 24 Authoritative server 19 Authoritative-only server 19 arpa: Address and Routing Parameter Area Domain 26 C CNAME 10 Canonical name 9 Child 22 Class 11 Class independent 16 Closest encloser 27 Closest provable encloser 27 Combined signing key (CSK) 33 D DNS operator 29 DNSSEC Policy (DP) 34 DNSSEC Practice Statement (DPS) 34 DNSSEC-aware and DNSSEC-unaware 30 Delegation 24 Delegation-centric zone 26 Domain name 5 Hoffman, et al. Best Current Practice [Page 46] RFC 8499 DNS Terminology January 2019 E EDNS 14 EPP 28 Empty non-terminals (ENT) 26 F FORMERR 10 Fast flux DNS 26 Forward lookup 26 Forwarder 21 Forwarding 20 Full resolver 18 Full-service resolver 18 Fully-qualified domain name (FQDN) 8 G Global DNS 5 Glue records 24 H Hardware security module (HSM) 34 Hidden master 20 Host name 8 I IDN 9 In-bailiwick 25 Insecure delegation 31 Instance 22 Internationalized Domain Name 9 Iterative mode 17 Iterative resolution 18 K Key signing key (KSK) 33 L Label 5 Lame delegation 24 Locally served DNS zone 8 M Master file 14 Master server 19 Multicast DNS 7 mDNS 7 Hoffman, et al. Best Current Practice [Page 47] RFC 8499 DNS Terminology January 2019 N NODATA 10 NOERROR 10 NOTIMP 10 NS 19 NSEC 31 NSEC3 31 NXDOMAIN 10 Naming system 4 Negative caching 19 Negative response 11 Next closer name 28 Non-recursive query 18 O OPT 14 Occluded name 26 Open resolver 21 Opt-out 31 Origin 23 Out-of-bailiwick 25 Owner 15 P Parent 23 Passive DNS 22 Policy-implementing resolver 21 Presentation format 14 Primary master 20 Primary server 20 Priming 18 Privacy-enabling DNS server 22 Private DNS 7 Public suffix 29 Q QNAME 11 R RDAP 29 REFUSED 10 RR 14 RRset 14 Recursive mode 17 Recursive query 18 Recursive resolver 17 Referrals 13 Registrant 28 Hoffman, et al. Best Current Practice [Page 48] RFC 8499 DNS Terminology January 2019 Registrar 28 Registry 28 Resolver 16 Reverse DNS, reverse lookup 26 Root hints 18 Root zone 26 S SERVFAIL 10 SOA 14 SOA field names 14 Secondary server 19 Secure Entry Point (SEP) 33 Service name 27 Signed zone 30 Signing software 34 Slave server 19 Source of Synthesis 28 Split DNS 21 Split-horizon DNS 21 Stealth server 20 Stub resolver 17 Subdomain 9 Subordinate 29 Superordinate 29 T TLD 9 TTL 15 Trust anchor 34 U Unsigned zone 30 V Validating resolver 33 Validation 32 View 21 W WHOIS 28 Wildcard 27 Wildcard domain name 27 Hoffman, et al. Best Current Practice [Page 49] RFC 8499 DNS Terminology January 2019 Z Zone 22 Zone cut 23 Zone enumeration 31 Zone signing key (ZSK) 33 Zone transfer 19 Acknowledgements The following is the Acknowledgements section of RFC 7719. 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 helped shape RFC 7719. Most of the major changes between RFC 7719 and this document came from active discussion on the DNSOP WG. Specific people who contributed material to this document include: Bob Harold, Dick Franks, Evan Hunt, John Dickinson, Mark Andrews, Martin Hoffmann, Paul Vixie, Peter Koch, Duane Wessels, Allison Mankin, Giovane Moura, Roni Even, Dan Romascanu, and Vladmir Cunat. Authors' Addresses Paul Hoffman ICANN Email: paul.hoffman@icann.org Andrew Sullivan Email: ajs@anvilwalrusden.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. Best Current Practice [Page 50]