ドメインネームシステム

ドメインネームシステム
通信プロトコル
略語DNS
目的ネットワーク上のリソースを識別する
開発者ポール・モッカペトリス
導入1983年11月 （1983-11）
OSI層アプリケーション層
ポート53
RFC(s)1034、1035​​

ドメインネームシステム（DNS ）は、インターネットやその他のインターネットプロトコル（IP）ネットワーク上のコンピュータ、サービス、その他のリソースに命名システムを提供する、階層型の分散型ネームサービスです。DNSは、関連する各エンティティに割り当てられたドメイン名（識別文字列）に、さまざまな情報を関連付けます。最も重要なのは、容易に記憶できるドメイン名を、基盤となるネットワークプロトコルを用いてコンピュータサービスやデバイスを特定し識別するために必要な数値のIPアドレスに変換することです。[ 1 ]ドメインネームシステムは、1985年以来、インターネットの機能に不可欠な要素となっています。

ドメインネームシステムは、各ドメインに権威ネームサーバーを指定することにより、ドメイン名の割り当てとインターネットリソースへのマッピングの責任を委任します。ネットワーク管理者は、割り当てられた名前空間のサブドメインに対する権限を他のネームサーバーに委任することができます。このメカニズムは、分散型でフォールトトレラントなサービスを提供し、単一の大規模な中央データベースを回避するように設計されています。さらに、DNSは、その中核となるデータベースサービスの技術的な機能を規定しています。DNSは、インターネットプロトコルスイートの一部として、DNSで使用されるデータ構造とデータ通信交換の詳細な仕様であるDNSプロトコルを定義します。

インターネットは、ドメイン名階層とIPアドレス空間という2つの主要な名前空間を維持しています。[ 2 ]ドメインネームシステムは、ドメイン名階層を維持し、それとアドレス空間間の変換サービスを提供します。インターネットネームサーバーと通信プロトコルは、ドメインネームシステムを実装します。DNSネームサーバーは、ドメインのDNSレコードを格納するサーバーであり、データベースへのクエリに応答します。

DNS データベースに保存される最も一般的なタイプのレコードは、権限の開始 ( SOA )、IP アドレス ( AおよびAAAA )、SMTPメール エクスチェンジャ(MX)、ネーム サーバー (NS)、逆 DNS ルックアップのポインター(PTR)、およびドメイン名エイリアス(CNAME) です。DNS は汎用データベースになることを意図していませんが、時間の経過とともに拡張され、DNSSECレコードなどの自動ルックアップ用、または責任者(RP) レコードなどの人間によるクエリ用の他のタイプのデータのレコードを保存できるようになりました。汎用データベースとして、DNS はブロックリストを保存することで迷惑メール(スパム) に対抗するためにも使用されています。DNS データベースは、通常、構造化テキスト ファイル (ゾーン ファイル) に保存されますが、他のデータベース システムが一般的です。

ドメインネームシステムは当初、 IP経由のトランスポートとしてユーザーデータグラムプロトコル（UDP）を使用していました。信頼性、セキュリティ、プライバシーへの懸念から、伝送制御プロトコル（TCP）の使用やその他多くのプロトコルの開発が進みました。

関数

DNS を説明する際によく使われる例えは、人間が理解しやすいコンピュータのホスト名をIP アドレスに変換することで、インターネットの電話帳のような役割を果たしているというものです。例えば、ドメイン名example.com内のホスト名は、 93.184.216.34 ( IPv4 ) と2606:2800:220:1:248:1893:25c8:1946 ( IPv6 )というアドレスに変換されます。DNS は迅速かつ透過的に更新できるため、エンドユーザーに影響を与えることなく、ネットワーク上のサービスの場所を変更できます。エンドユーザーは同じホスト名を使い続けます。ユーザーは、コンピュータが実際にどのようにサービスを見つけているかを意識することなく、意味のある Uniform Resource Locator ( URL ) と電子メールアドレスを使用することで、このメリットを享受できます。 www.example.com

DNSの重要かつ普遍的な機能は、クラウドサービスやコンテンツ配信ネットワークなどの分散型インターネットサービスにおける中心的な役割です。[ 3 ]ユーザーがURLを使用して分散型インターネットサービスにアクセスすると、URLのドメイン名はユーザーに近いサーバーのIPアドレスに変換されます。ここで利用されるDNSの主要な機能は、異なるユーザーが同じドメイン名に対して同時に異なる変換を受け取ることができることです。これは、DNSの従来の電話帳の見方との重要な相違点です。DNSを使用してユーザーに近接サーバーを割り当てるこのプロセスは、インターネット上でより高速で信頼性の高い応答を提供するための鍵であり、ほとんどの主要なインターネットサービスで広く使用されています。[ 4 ]

DNSは、インターネットにおける管理責任の構造を反映しています。[ 5 ]各サブドメインは、管理者に委任された管理上の自治権を持つゾーンです。レジストリによって運営されるゾーンでは、管理情報はレジストリのRDAPおよびWHOISサービスによって補完されることがよくあります。これらのデータは、インターネット上の特定のホストに関する洞察を得たり、責任を追跡したりするために使用できます。[ 6 ]

歴史

ホストの数値アドレスの代わりに、よりシンプルで覚えやすい名前を使用するという慣習は、ARPANET時代に遡ります。スタンフォード研究所（現SRIインターナショナル）は、ホスト名とARPANET上のコンピュータの数値アドレスを対応付けるHOSTS.TXTというテキストファイルを管理していました。 [ 7 ] [ 8 ]エリザベス・ファインラーは、最初のARPANETディレクトリを開発・管理しました。[ 9 ] [ 10 ]割り当て番号リストと呼ばれる数値アドレスの管理は、南カリフォルニア大学情報科学研究所（ISI）のジョン・ポステルによって行われ、彼のチームはSRIと緊密に協力していました。[ 11 ]

アドレスは手動で割り当てられていました。コンピュータとそのホスト名およびアドレスは、営業時間内に電話でフェインラーが指揮するSRIネットワーク情報センター（NIC）に連絡することによってプライマリファイルに追加されました。 [ 12 ]その後、フェインラーはNICのサーバ上にWHOISディレクトリを設定し、リソース、連絡先、エンティティに関する情報を取得しました。 [ 13 ]彼女と彼女のチームはドメインの概念を開発しました。[ 13 ]フェインラーは、ドメインはコンピュータの物理アドレスの場所に基づくべきだと提案しました。[ 14 ]例えば、教育機関のコンピュータはeduというドメインを持ちます。 [ 15 ]彼女と彼女のチームは1972年から1989年までホスト名登録レジストリを管理しました。[ 16 ]

1980年代初頭までに、単一の集中型ホストテーブルの維持は速度と扱いにくさを増し、新興ネットワークでは技術的および人的問題に対処するために自動化された命名システムが必要になりました。ポステルは、ポール・モッカペトリスに対し、5つの競合する解決策の妥協案をまとめる作業を指示しました。モッカペトリスは、南カリフォルニア大学在学中の1983年にドメインネームシステムを開発しました。[ 12 ] [ 17 ]

インターネットエンジニアリングタスクフォースは、 1983年11月にRFC 882とRFC 883で最初の仕様を公開しました。[ 18 ] [ 19 ]これらは1986年1月にRFC 973で更新されました。[ 20 ]

1984年、カリフォルニア大学バークレー校の学生4人、ダグラス・テリー、マーク・ペインター、デビッド・リグル、ソンニアン・ゾウが、バークレー・インターネット・ネーム・ドメイン（BIND）用の最初のUnixネーム・サーバ実装を作成しました。[ 21 ] 1985年、DECのケビン・ダンラップがDNS実装を大幅に改訂しました。その後、マイク・カレルズ、フィル・アルムキスト、ポール・ビクシーがBINDのメンテナンスを引き継ぎました。1994年、リック・アダムス、ポール・ビクシー、カール・マラマッドがBINDの開発とメンテナンスの拠点を提供することを目的としてインターネット・システムズ・コンソーシアム（ ISC）を設立しました。4.9.3以降のBINDバージョンはISCのスポンサーのサポートを受けてISCが開発とメンテナンスを行いました。共同設計者/プログラマーとして、ボブ・ハリーとポール・ヴィクシーは1997年5月にBINDバージョン8の最初の製品版をリリースしました。2000年以降、43人以上のコア開発者がBINDの開発に携わってきました。[ 22 ]

1987年11月、RFC 1034 [ 23 ]とRFC 1035 [ 5 ]が1983年のDNS仕様に取って代わりました。その後も、いくつかの追加的なコメント要請（RFC）において、コアDNSプロトコルの拡張が提案されました。[ 24 ]

構造

ドメイン名空間

ドメイン名空間は木構造のデータ構造から構成されます。木構造の各ノード（葉）には、ラベルと、ドメイン名に関連する情報を保持する0個以上のリソースレコード（RR）が含まれます。ドメイン名自体は、ラベルと、その右側の親ノードの名前をドットで区切って連結したもので構成されます。[ 23 ] : §3.1

ツリーはルートゾーンから始まるゾーンに細分化されます。DNSゾーンは、ゾーンマネージャが選択した数のドメインとサブドメインで構成できます。DNSはクラスによって分割することもでき、個々のクラスは並列な名前空間ツリーの配列と考えることができます。[ 23 ] : §4.2

インターネットクラスの階層型ドメインネームシステム。ゾーンに編成され、各ゾーンはネームサーバーによって管理される。

ゾーンの管理責任は、追加のゾーンを作成することによって分割することができます。新しいゾーンに対する権限は、指定されたネームサーバーに委任されます。親ゾーンは、新しいゾーンに対する権限を失います。[ 23 ] : §4.2

ドメイン名の構文、国際化

ドメイン名の形成規則の決定的な説明は、RFC 1035、RFC 1123、RFC 2181、および RFC 5892 に記載されています。ドメイン名は、技術的にはラベルと呼ばれる 1 つ以上の部分で構成され、通常、連結され、ドットで区切られます (example.com など)。

右端のラベルはトップレベルドメインを伝えます。たとえば、ドメイン名 www.example.com はトップレベルドメインcomに属します。

ドメインの階層は右から左へと下降し、左の各ラベルは右のドメインの下位区分、つまりサブドメインを表します。例えば、「example」というラベルはcomドメインのサブドメインを表し、「www」はexample.comのサブドメインを表します。この下位区分のツリーは最大127階層まで存在します。[ 25 ]

ラベルの長さは6ビットまでしか許可されていないため、ラベルには0～63文字まで含めることができます。長さ0のヌルラベルはルートゾーン用に予約されています。ドメイン名全体のテキスト表現は253文字（末尾のドットを含めると254文字）を超えてはなりません。[ 23 ] DNSの内部バイナリ表現では、この最大長253には255オクテットの記憶域が必要です。これは、多数のラベルのうち最初のラベルの長さと最後のヌルバイトを格納し、さらに255オクテットの記憶域を必要とするためです。[ 5 ] 255の長さは、少なくとも6つのラベル（最後のヌルラベルを含む）でのみ達成されます。[ 5 ]

ドメイン名ラベルにオクテットで表現可能な文字を使用することを禁じる技術的な制限はありませんが、ホスト名には推奨される形式と文字セットが使用されます。ラベルに使用できる文字はASCII文字セットのサブセットであり、文字aからz、AからZ、数字0から9、およびハイフンで構成されます。このルールはLDHルール（文字、数字、ハイフン）として知られています。ドメイン名は大文字と小文字を区別せずに解釈されます。[ 26 ]ラベルはハイフンで始まっても終わってもいけません。[ 27 ]追加のルールとして、トップレベルドメイン名はすべて数字であってはならないと規定されています。[ 27 ]

DNSで許可されているASCII文字セットの制限により、多くの言語の名前や単語をそのネイティブなアルファベットや文字で表現することができませんでした。これを可能にするため、ICANNはIDNA（ Internationalizing Domain Names in Applications ）システムを承認しました。このシステムにより、Webブラウザなどのユーザーアプリケーションは、Punycodeを使用してUnicode文字列を有効なDNS文字セットにマッピングします。2009年、ICANNは国際化ドメイン名の国コードトップレベルドメイン（ccTLD）の導入を承認しました。さらに、既存のトップレベルドメイン名（TLD）の多くのレジストリは、 RFC 5890、RFC 5891、RFC 5892、RFC 5893に準拠したIDNAシステムを採用しています。

ネームサーバー

ドメインネームシステムは、クライアントサーバーモデルを採用した分散データベースシステムによって維持されています。このデータベースのノードはネームサーバーです。各ドメインには、少なくとも1つの権威DNSサーバーがあり、そのドメインと、そのドメインに従属するすべてのドメインのネームサーバーに関する情報を公開します。階層の最上位にはルートネームサーバーがあり、 TLDを検索（解決）する際に問い合わせるサーバーです。

権威ネームサーバー

権威ネーム サーバーは、データのキャッシュのみを保持する別のネーム サーバーへのクエリを通じて取得される回答とは対照的に、ドメイン管理者などの元のソースまたは動的 DNS メソッドによって構成されたデータからの DNS クエリに対する回答のみを提供するネーム サーバーです。

権威ネームサーバーは、プライマリサーバーまたはセカンダリサーバーのいずれかになります。歴史的には、マスター/スレーブとプライマリ/セカンダリという用語は互換的に使用されることがありました[ 28 ]が、現在では後者の形式が使用されています。プライマリサーバーは、すべてのゾーンレコードのオリジナルコピーを保存するサーバーです。セカンダリサーバーは、プライマリサーバーと通信する際にDNSプロトコルの特別な自動更新メカニズムを使用し、プライマリレコードの同一コピーを維持します。

すべてのDNSゾーンには、権威ネームサーバーのセットを割り当てる必要があります。このサーバーセットは、ネームサーバー（NS）レコードとともに親ドメインゾーンに保存されます。

権威サーバーは、応答に「権威回答」（AA）ビットと呼ばれるプロトコルフラグを設定することで、決定的な回答を提供している（権威があるとみなされる）状態を示します。 [ 5 ]このフラグは通常、 digなどのDNS管理クエリツールの出力に目立つように再現され、応答しているネームサーバーが問題のドメイン名の権威であることを示します。 [ 5 ]

ネームサーバーが、権威データを持たないドメイン名の権威サーバーとして指定されると、「不完全な委任」または「不完全な応答」と呼ばれるタイプのエラーが発生します。[ 29 ] [ 30 ]

手術

アドレス解決メカニズム

ドメイン名リゾルバは、右端 (トップレベル) のドメイン ラベルから始まる一連のクエリによって、問題のドメイン名を担当するドメイン ネーム サーバーを決定します。

RFC 1034 で義務付けられている反復アプローチを実装する DNS リゾルバ。この場合、リゾルバは 3 つのネーム サーバーを参照して、完全修飾ドメイン名「www.wikipedia.org」を解決します。

ドメイン名リゾルバを適切に動作させるために、ネットワークホストにはルートネームサーバーの既知のアドレスの初期キャッシュ（ヒント）が設定されます。ヒントは、管理者が信頼できるソースからデータセットを取得することで定期的に更新されます。

リゾルバが処理を高速化するためのキャッシュレコードを持っていない場合、解決プロセスはルートサーバーの1つへのクエリから始まります。通常の動作では、ルートサーバーは直接応答せず、より権威のあるサーバーへの参照で応答します。例えば、「www.wikipedia.org」へのクエリは、orgサーバーに参照されます。リゾルバは参照先のサーバーにクエリを送信し、権威のある回答が得られるまでこのプロセスを繰り返します。図は、完全修飾ドメイン名「www.wikipedia.org」 で指定されたホストにおけるこのプロセスを示しています。

このメカニズムは、インターネット上のすべての解決がルートから始まる必要がある場合、ルートサーバーに大きなトラフィック負荷をかけることになります。実際には、DNSサーバーではキャッシュがルートサーバーの負荷を軽減するために使用されており、その結果、ルートネームサーバーが実際に関与するリクエストは全体のごく一部に過ぎません。

再帰およびキャッシュネームサーバー

理論上は、権威ネームサーバーだけでインターネットの運用は可能です。しかし、権威ネームサーバーのみが稼働している場合、すべてのDNSクエリはドメインネームシステムのルートゾーンへの再帰クエリから開始する必要があり、各ユーザーシステムは再帰処理が可能なリゾルバソフトウェアを実装する必要があります。[ 31 ]

効率性の向上、インターネット上のDNSトラフィックの削減、そしてエンドユーザーアプリケーションのパフォーマンス向上のため、ドメインネームシステムはDNSキャッシュサーバーをサポートしています。DNSキャッシュサーバーは、DNSクエリ結果を、対象となるドメイン名レコードの設定（TTL）で定められた期間保存します。通常、このようなキャッシュDNSサーバーは、DNSルートからクエリ対象ドメインの権威ネームサーバーに至るまで、指定された名前を解決するために必要な再帰アルゴリズムも実装しています。ネームサーバーにこの機能を実装することで、ユーザーアプリケーションの設計と運用の効率が向上します。

ネーム サーバーでの DNS キャッシュと再帰機能の組み合わせは必須ではありません。これらの機能は、特別な目的のためにサーバー内で個別に実装できます。

インターネットサービスプロバイダー（ISP）は通常、顧客に再帰型ネームサーバーとキャッシュ型ネームサーバーを提供しています。さらに、多くの家庭用ネットワークルーターは、ローカルネットワークの効率を向上させるためにDNSキャッシュと再帰型ネームサーバーを実装しています。

DNSリゾルバ

DNSのクライアント側はDNSリゾルバと呼ばれます。リゾルバは、最終的に要求されたリソースの完全な解決（変換）（例えば、ドメイン名からIPアドレスへの変換）につながるクエリの開始と順序付けを担当します。DNSリゾルバは、再帰的、非再帰的、反復的など、さまざまなクエリ方法によって分類されます。解決プロセスでは、これらの方法を組み合わせて使用​​する場合があります。[ 23 ]

非再帰クエリでは、DNSリゾルバはDNSサーバーにクエリを実行し、そのサーバーが権限を持つレコードを提供するか、他のサーバーにクエリを実行せずに部分的な結果を提供します。キャッシュ型DNSリゾルバの場合、ローカルDNSキャッシュへの非再帰クエリによって結果が提供され、上流DNSサーバーからの最初の応答後、一定期間DNSリソースレコードがキャッシュされるため、上流DNSサーバーの負荷が軽減されます。

再帰クエリでは、DNS リゾルバが 1 つの DNS サーバーにクエリを実行し、次にそのサーバーが要求元に代わって他の DNS サーバーにクエリを実行する場合があります。たとえば、家庭用ルータで動作する単純なスタッブリゾルバは通常、ユーザーの ISP が稼働する DNS サーバーに再帰クエリを実行します。再帰クエリとは、DNS サーバーが必要に応じて他のネームサーバーにクエリを実行することでクエリに完全に応答するクエリです。一般的な操作では、クライアントがキャッシュ再帰 DNS サーバーに再帰クエリを発行し、その後、キャッシュ再帰 DNS サーバーは非再帰クエリを発行して応答を決定し、単一の応答をクライアントに返します。リゾルバ、またはリゾルバに代わって再帰的に動作する別の DNS サーバーは、クエリ ヘッダー内のビットを使用して再帰サービスの使用をネゴシエートします。DNS サーバーは再帰クエリをサポートする必要はありません。

反復クエリ手順とは、DNSリゾルバが1つ以上のDNSサーバーのチェーンに対してクエリを実行するプロセスです。各サーバーは、現在のサーバーが要求を完全に解決できるまで、クライアントをチェーン内の次のサーバーに照会します。例えば、www.example.comというドメイン名を解決する場合、グローバルルートサーバー、次に「com」サーバー、そして最後に「example.com」サーバーにクエリを実行します。

循環依存関係とグルーレコード

委任におけるネームサーバーは、IPアドレスではなく名前で識別されます。つまり、名前解決を行うネームサーバーは、参照先のサーバーのIPアドレスを確認するために、別のDNS要求を発行する必要があります。委任で指定された名前が、委任の対象ドメインのサブドメインである場合、循環依存関係が発生します。

この場合、委任を提供するネームサーバーは、委任に記載されている権威ネームサーバーのIPアドレスを1つ以上提供する必要があります。この情報はグルーと呼ばれます。委任元のネームサーバーは、DNS応答の追加セクションにレコードの形式でグルーを提供し、委任を応答の権威セクションに提供します。グルーレコードは、ネームサーバーとIPアドレスの組み合わせです。

例えば、 example.org の権威ネームサーバーが ns1.example.org である場合、www.example.org を解決しようとするコンピュータは、まず ns1.example.org を解決します。ns1 は example.org に含まれているため、まず example.org を解決する必要があり、循環依存関係が生じます。この依存関係を解消するために、トップレベルドメインorg のネームサーバーには、example.org の委任に加えて、グルーレコードが含まれています。グルーレコードは、ns1.example.org の IP アドレスを提供するアドレスレコードです。リゾルバーはこれらの IP アドレスの 1 つ以上を使用して、ドメインの権威サーバーの 1 つにクエリを実行し、DNS クエリを完了します。

レコードのキャッシュ

DNSサーバーのクエリ負荷を軽減する一般的な方法は、名前解決の結果をローカルまたは中間リゾルバホストにキャッシュすることです。各DNSクエリ結果には、情報の有効期限（TTL）が付与されます。これは、情報が破棄または更新されるまでの有効期間を示します。このTTLは権威DNSサーバーの管理者によって決定され、数秒から数日、さらには数週間までの範囲となります。[ 32 ]

この分散キャッシュアーキテクチャの結果、DNS レコードへの変更はネットワーク全体に即座に伝播されず、すべてのキャッシュが TTL の経過後に期限切れになり、更新される必要があります。RFC 1912 では、適切な TTL 値を決定するための基本的なルールが規定されています。

一部のリゾルバはTTL値を上書きする場合があります。これは、プロトコルが最大68年間のキャッシュ、またはキャッシュを全く行わないことをサポートしているためです。ネガティブキャッシュ、つまりレコードが存在しないという事実をキャッシュするかどうかは、ゾーンの権限を持つネームサーバーによって決定されます。これらのネームサーバーは、要求されたタイプのデータが存在しないと報告する際に、SOA（ Start of Authority ）レコードを含める必要があります。SOAレコードの最小フィールドの値とSOA自体のTTLは、ネガティブ応答のTTLを確立するために使用されます。

逆引き

逆DNSルックアップとは、IPアドレスが既知の場合に、DNSにドメイン名を問い合わせることです。1つのIPアドレスに複数のドメイン名が関連付けられる場合があります。DNSは、IPアドレスをドメイン名の形式で、インフラストラクチャトップレベルドメインarpa内のポインタ（PTR）レコードに特別な形式の名前として保存します。IPv4の場合、ドメインはin-addr.arpaです。IPv6の場合、逆ルックアップドメインはip6.arpaです。IPアドレスは、IPv4では逆順オクテット表現、IPv6では逆順ニブル表現で表されます。

逆引き検索を実行する際、DNSクライアントは、他のDNSクエリと同様に、委任チェーンに従ってPTRレコードを名前で照会する前に、アドレスをこれらの形式に変換します。例えば、IPv4アドレス208.80.152.2がWikimediaに割り当てられているとすると、これはDNS名として逆順に2.152.80.208.in-addr.arpaと表されます。DNSリゾルバがポインタ（PTR）要求を受け取ると、ルートサーバーへの照会を開始します。ルートサーバーは、 208.in-addr.arpaゾーンのAmerican Registry for Internet Numbers（ARIN）のサーバーを指します。ARINのサーバーは152.80.208.in-addr.arpaをWikimediaに委任し、リゾルバは2.152.80.208.in-addr.arpaに対する別のクエリをWikimediaに送信します。その結果、権威応答が返されます。

クライアント検索

DNS解決シーケンス

ユーザーは通常、DNSリゾルバと直接通信することはありません。DNS解決は、ウェブブラウザ、電子メールクライアント、その他のインターネットアプリケーションなどのアプリケーション内で透過的に行われます。アプリケーションがドメイン名の参照を必要とするリクエストを行うと、これらのプログラムはローカルオペレーティングシステム内のDNSリゾルバに解決要求を送信し、DNSリゾルバが必要な通信を処理します。

DNSリゾルバは、ほぼ常に最近の検索結果を含むキャッシュ（上記参照）を保持しています。キャッシュが要求への回答を提供できる場合、リゾルバはキャッシュ内の値を要求元のプログラムに返します。キャッシュに回答がない場合、リゾルバは指定された1つ以上のDNSサーバーに要求を送信します。ほとんどのホームユーザーの場合、通常、マシンが接続しているISPがこのDNSサーバーを提供します。そのようなユーザーは、サーバーのアドレスを手動で設定するか、DHCPによる設定を許可しています。しかし、システム管理者が独自のDNSサーバーを使用するようにシステムを設定している場合、DNSリゾルバは組織が別途管理するネームサーバーを参照します。いずれにせよ、このように問い合わせを受けたネームサーバーは、結果が見つかるか見つからないかのどちらかになるまで、上記で概説したプロセスに従います。その後、DNSリゾルバに結果を返します。結果が見つかった場合、リゾルバはその結果を将来使用するためにキャッシュし、要求を開始したソフトウェアに結果を返します。

壊れたリゾルバ

大手ISPの中には、TTLを無視したり、ネームサーバーの1つが応答しないという理由だけでドメイン名が存在しないと表示したりするなど、ルールに違反するようにDNSサーバーを設定しているところもある。[ 33 ]

ウェブブラウザなどの一部のアプリケーションは、ネットワーク経由の重複参照を回避するために内部DNSキャッシュを保持しています。この方法は、DNSキャッシュの履歴が不明瞭になるため、DNSの問題のデバッグを困難にする可能性があります。これらのキャッシュは通常、1分程度と非常に短いキャッシュ時間で動作します。[ 34 ]

Internet Explorerは注目すべき例外です。IE 3.xまでのバージョンでは、DNSレコードがデフォルトで24時間キャッシュされます。Internet Explorer 4.x以降のバージョン（IE 8まで）では、デフォルトのタイムアウト値が30分に短縮されます。この値は、デフォルト設定を変更することで変更できます。[ 35 ]

Google Chrome はDNS サーバーの問題を検出する と、特定のエラー メッセージが表示されます。

その他のアプリケーション

ドメイン ネーム システムには、その他の機能や特徴もいくつか含まれています。

ホスト名とIPアドレスは1対1の関係で一致する必要はありません。複数のホスト名が1つのIPアドレスに対応する場合があり、これは単一のホストから複数のウェブサイトを提供する仮想ホスティングで役立ちます。また、単一のホスト名が複数のIPアドレスに解決されることで、企業内またはグローバルインターネット上の複数のサーバーインスタンスへの フォールトトレランスと負荷分散が容易になります。

DNSは、名前をIPアドレスに変換する以外にも様々な目的に使用されます。例えば、メール転送エージェント（ MTA）は、電子メールを配信するのに最適なメールサーバーを見つけるためにDNSを使用します。MXレコードは、ドメインとメールエクスチェンジャー間のマッピングを提供します。これにより、フォールトトレランスと負荷分散のレイヤーを追加できます。

DNSは、ブロックリストに登録されたメールホストのIPアドレスを効率的に保存および配布するために使用されます。一般的な方法は、対象ホストのIPアドレスを上位レベルのドメイン名のサブドメインに配置し、その名前を肯定または否定を示すレコードに解決することです。

例えば：

  • アドレス203.0.113.5はブロックリストに登録されています。これは5.113.0.203.blocklist.exampleを指しており、これは127.0.0.1に解決されます。
  • アドレス203.0.113.6はブロックリストに登録されておらず、6.113.0.203.blocklist.exampleを指しています。このホスト名は設定されていないか、127.0.0.2に解決されます。

メールサーバーは、blocklist.example にクエリを送信することで、接続してくる特定のホストがブロックリストに登録されているかどうかを確認できます。このようなブロックリストは、有料版と無料版の両方があり、メール管理者やスパム対策ソフトウェアで利用可能です。

コンピュータやネットワークの障害発生時に回復力を確保するため、通常、各ドメインをカバーする複数のDNSサーバーが提供されます。グローバルDNSの最上位レベルには、13のルートネームサーバーグループが存在し、それらの「コピー」がエニーキャストアドレスを介して世界中に分散されています。

ダイナミック DNS (DDNS) は、ISP またはモバイルホット スポット間を移動する場合や、IP アドレスが管理上変更される場合など に、クライアントの IP アドレスを使用して DNS サーバーをオンザフライで更新します。

DNSメッセージ形式

DNSプロトコルは、クエリとレスポンスという2種類のDNSメッセージを使用します。どちらも同じフォーマットです。各メッセージは、ヘッダーと4つのセクション（質問、回答、権限、および追加のスペース）で構成されます。ヘッダーフィールド（フラグ）は、これらの4つのセクションの内容を制御します。[ 23 ]

ヘッダーセクションは、識別、フラグ、質問数、回答数、権限リソースレコード（RR）数、追加RR数というフィールドで構成されます。各フィールドは16ビット長で、指定された順序で出現します。識別フィールドは、応答とクエリを照合するために使用されます。フラグワードの後、ヘッダーは4つの16ビット整数で終わります。これらの整数には、後続の各セクションのレコード数が、同じ順序で格納されています。

DNSヘッダー
オフセットオクテット0 1 2 3
オクテット 少し0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 取引IDQRオペコードAATCRDRAZ広告CDRコード
4 32 質問数回答数
8 64 権限RRの数追加RRの数
トランザクションID: 16ビット
取引ID
フラグ: 16ビット
フラグ フィールドは次のサブフィールドで構成されます。
QR: 1ビット
メッセージがクエリ (0) か応答 (1) かを示します。
オペコード: 4ビット
タイプは、QUERY (標準クエリ、0)、IQUERY (逆クエリ、1)、または STATUS (サーバー ステータス要求、2) になります。
AA: 1ビット
応答内の「権限のある回答」は、DNS サーバーが照会されたホスト名に対して権限を持っているかどうかを示します。
TC: 1ビット
TrunCation は、このメッセージが長すぎるために切り捨てられたことを示します。
RD: 1ビット
再帰が望ましい。クライアントが再帰クエリを意味するかどうかを示します。
RA: 1ビット
応答内の「再帰が利用可能」は、応答する DNS サーバーが再帰をサポートしているかどうかを示します。
Z: 1ビット; (Z) == 0
ゼロ、将来の使用のために予約されています。
AD: 1ビット
応答内の認証データは、応答側の DNS サーバーがデータを検証したかどうかを示します。
CD: 1ビット
クエリで「無効」をチェックすると、応答で検証されていないデータが許容されることを示します。
RCODE: 4ビット
応答コードは、NOERROR（0）、FORMERR（1、フォーマットエラー）、SERVFAIL（2）、NXDOMAIN（3、存在しないドメイン）などです。[ 36 ]
問題数: 16ビット
質問の数。
回答数: 16ビット
回答数。
権限RRの数: 16ビット
機関リソース レコードの数。
追加RRの数: 16ビット
追加リソース レコードの数。

質問セクション

質問セクションは、他のセクションで使用されるリソースレコード形式よりもシンプルな形式です。各質問レコード（セクション内には通常1つだけ存在します）には、以下のフィールドが含まれます。

リソースレコード（RR）フィールド
分野説明長さ（オクテット）
名前要求されたリソースの名前変数
タイプRR のタイプ (A、AAAA、MX、TXT など)2
クラスクラスコード2

ドメイン名は連結された個別のラベルに分割され、各ラベルの前にはそのラベルの長さが付けられます。[ 37 ]

リソースレコード

ドメインネームシステムは、ネットワークリソースの情報要素のデータベースを指定します。情報要素の種類は、DNSレコードの種類のリスト、つまりリソー​​スレコード（RR）に分類され、整理されます。各レコードには、種類（名前と番号）、有効期限（存続時間）、クラス、種類固有のデータが含まれます。同じ種類のリソースレコードは、特別な順序付けのないリソースレコードセット（RRset）として記述されます。DNSリゾルバはクエリ時にセット全体を返しますが、サーバーは負荷分散を実現するためにラウンドロビン方式を実装する場合があります。一方、ドメインネームシステムセキュリティ拡張機能（DNSSEC）は、リソースレコードの完全なセットを正規の順序で処理します。

インターネットプロトコルネットワーク経由で送信される場合、すべてのレコード（回答、権限、および追加セクション）は、RFC 1035で指定された共通フォーマットを使用します。[ 38 ]：§3

リソースレコード（RR）フィールド
分野説明長さ（オクテット）
名前このレコードが関連するノードの名前変数
タイプ数値形式のRRのタイプ（例：MX RRの場合は15）2
クラスクラスコード2
TTLRRの有効期間（秒数）（最大値は2 31 −1、約68年）4
RDLENGTHRDATAフィールドの長さ（オクテット単位で指定）2
RデータRR固有の追加データRDLENGTHに応じて可変

NAME は、ツリー内のノードの完全修飾ドメイン名です。伝送路上では、ラベル圧縮によって名前が短縮される場合があります。この場合、パケット内で先行するドメイン名の末尾が、現在のドメイン名の末尾に置き換えられます。

TYPEはレコードの種類です。データの形式を示し、その用途のヒントとなります。例えば、Aレコードはドメイン名をIPv4アドレスに変換するために使用され、NSレコードはDNSゾーンのルックアップに応答できるネームサーバーをリストし、MXレコードは電子メールアドレスで指定されたドメイン宛のメールを処理するために使用されるメールサーバーを指定します。

RDATAは、アドレスレコードのIPアドレスやMXレコードの優先度とホスト名など、タイプ固有の関連データです。既知のレコードタイプではRDATAフィールドでラベル圧縮を使用できますが、「不明」なレコードタイプでは使用してはなりません（RFC 3597）。

インターネットホスト名、サーバー、またはIPアドレスを含む一般的なDNSレコードの場合、レコードのCLASSはIN（インターネット）に設定されます。さらに、 Chaos（CH）とHesiod（HS）というクラスも存在します。[ 38 ]：11 各クラスは独立した名前空間であり、DNSゾーンの委任が異なる場合があります。

ゾーン ファイルで定義されたリソース レコードに加えて、ドメイン ネーム システムでは、ゾーン転送 (AXFR/IXFR) の実行時やEDNS (OPT)など、他の DNS ノード (ネットワーク上) との通信にのみ使用されるいくつかの要求タイプも定義します。

ワイルドカードレコード

ドメインネームシステムは、アスタリスクラベルで始まる名前を指定するワイルドカード DNS レコードをサポートしています(例: )。[ 23 ] [ 39 ]ワイルドカードドメイン名に属する DNS レコードは、ラベル全体をクエリ名の一致するコンポーネント (指定された子孫を含む) に置き換えることによって、単一の DNS ゾーン内でリソースレコードを生成するためのルールを指定します。 たとえば、次の構成では、DNS ゾーンx.exampleは、サブドメインのサブドメインを含むx.exampleのすべてのサブドメインがメールエクスチェンジャ (MX) axexampleを使用することを指定します。メールエクスチェンジャの IP アドレスを指定するには、 axexampleの AAAA レコードが必要です。 この結果、このドメイン名とそのサブドメインがワイルドカードの一致から除外されるため、サブドメインaxexampleの追加の MX レコードと、そのすべてのサブドメインのワイルドカード化された MX レコードも、DNS ゾーンで定義する必要があります。 **.example

x.example. MX 10 a.x.example. *.x.example. MX 10 a.x.example. axexample. MX 10 a.x.example. *.axexample. MX 10 a.x.example. axexample. AAAA 2001:db8::1

ワイルドカードレコードの役割はRFC 4592で洗練されました。これは、 RFC 1034の元の定義が不完全で、実装者による誤解を招いたためです。[ 39 ]  

プロトコル拡張

オリジナルのDNSプロトコルでは、新機能による拡張のための規定が限られていました。1999年、Paul VixieはRFC 2671（RFC 6891に置き換えられました）で、Extension Mechanisms for DNS (EDNS)と呼ばれる拡張メカニズムを公開しました。これは、未使用時のオーバーヘッドを増加させることなく、オプションのプロトコル要素を導入するものでした。これは、プロトコルの有線伝送にのみ存在し、ゾーンファイルには存在しないOPT疑似リソースレコードによって実現されました。UDPデータグラムにおけるDNSメッセージサイズの増加など、初期の拡張も提案されました（EDNS0）。

動的ゾーン更新

動的DNS更新は、UPDATE DNSオペコードを用いて、権威DNSサーバー上に維持されているゾーンデータベースにリソースレコードを動的に追加または削除します。[ 40 ]この機能は、ネットワーククライアントが起動時またはネットワーク上で利用可能になった際に、DNSに登録するのに役立ちます。起動中のクライアントにはDHCPサーバーから毎回異なるIPアドレスが割り当てられる可能性があるため、このようなクライアントに静的なDNS割り当てを提供することはできません。

トランスポートプロトコル

DNSは1983年の誕生以来、 IP経由のトランスポートにユーザーデータグラムプロトコル（UDP）を使用してきました。その限界は、その後数十年にわたり、信頼性、セキュリティ、プライバシー、その他の基準を満たすための数多くのプロトコル開発の原動力となってきました。

従来型: UDP および TCP ポート 53 経由の DNS (Do53)

UDP は、クエリをリッスンするサーバー用にポート番号 53 を予約しています。[ 5 ]このようなクエリは、クライアントから単一の UDP パケットで送信されるクリア テキストの要求と、サーバーからの単一の UDP パケットで送信されるクリア テキストの応答で構成されます。応答の長さが 512 バイトを超え、クライアントとサーバーの両方がDNS の拡張メカニズム(EDNS) をサポートしている場合は、より大きな UDP パケットを使用できます。[ 41 ] DNS over UDP の使用は、トランスポート層の暗号化、認証、信頼性の高い配信、メッセージ長の欠如などによって制限されます。1989 年に、RFC 1123 は、DNS クエリ、応答、特にゾーン転送用にオプションの伝送制御プロトコル(TCP) トランスポートを指定しました。長い応答を断片化することにより、TCP はより長い応答、信頼性の高い配信、およびクライアントとサーバー間の長時間接続の再利用を可能にします。

DNS over TLS (DoT)

DNS over TLSは、2016年に暗号化DNSのIETF標準として登場し、トランスポート層セキュリティ（TLS）を利用してDNSペイロードだけでなく接続全体を保護します。DoTサーバーはTCPポート853でリッスンします。RFC 7858では、日和見暗号化と認証付き暗号化がサポートされる可能性があると規定されていますが、サーバー認証またはクライアント認証は必須ではありません。  

DNS over HTTPS (DoH)

DNS over HTTPSは、2018年にDNSクエリ転送の競合標準として開発されました。DNSクエリデータをHTTPS経由でトンネリングし、HTTP over TLSを転送します。DoHは、DNSCryptと同様にTCPポート443を使用するため、Webトラフィックと類似しているように見えることから、DNSよりもWebに適した代替手段として推奨されました。ただし、適切なパディングがなければ、実際には簡単に区別できます。[ 42 ]

DNS over QUIC (DoQ)

2022年にインターネット技術特別調査委員会（IETF ）によって公開されたRFC 9250では、 DNS over QUICについて説明されています。DNS over QUICは「DNS over TLS（DoT）と同様のプライバシー特性と、従来のDNS over UDPと同様の遅延特性」を備えています。この方式はDNS over HTTP/3とは異なります。[ 43 ]

Oblivious DoH (ODoH) とその前身である Oblivious DNS (ODNS)

Oblivious DNS（ODNS）は、プリンストン大学とシカゴ大学の研究者によって、暗号化されていないDNSの拡張として発明・実装されました[ 44 ]。これはDoHが標準化され広く導入される前のことでした。その後、AppleとCloudflareは、この技術をDoHの文脈でOblivious DoH（ODoH）として導入しました[ 45 ] 。ODoHは、ODNSで発明されたイングレス/エグレス分離と、DoHのHTTPSトンネリングおよびTLSトランスポート層暗号化を単一のプロトコルに統合しています[ 46 ] 。

Tor経由のDNS

DNSは仮想プライベートネットワーク（VPN）やトンネリングプロトコルを介して実行される場合があります。Oblivious DNSのプライバシー保護は、既存のTorネットワークの入口ノードと出口ノードを利用し、TLSによるトランスポート層暗号化と組み合わせることで実現されます。[ 47 ]

DNS暗号化

2011年にIETF標準フレームワークの外で開発されたDNSCryptプロトコルは、再帰リゾルバの下流側にDNS暗号化を導入しました。クライアントは、DNSで公開されている（サードパーティの証明機関に依存せずに）サーバーの公開鍵を使用してクエリペイロードを暗号化し、DNSSEC署名によって保護される可能性があります。[ 48 ] DNSCryptは、 HTTPSで暗号化されたWebトラフィックと同じTCPポート443、またはUDPポート443を使用します。これにより、クエリの内容に関するプライバシーが確保されるだけでなく、ファイアウォールを突破する能力も大幅に向上しました。2019年には、DNSCryptはさらに拡張され、「匿名化」モードをサポートするようになりました。これは、提案されている「Oblivious DNS」に類似しています。このモードでは、入口ノードが別のサーバーの公開鍵で暗号化されたクエリを受信し、そのサーバーに中継します。そのサーバーは出口ノードとして機能し、再帰解決を実行します。[ 49 ]入口ノードはクエリの内容を知らず、出口ノードはクライアントの身元を知らないため、ユーザー/クエリペアのプライバシーが確保されます。DNSCryptは、 2011年12月にOpenDNSによって初めて本番環境で実装されました。ODoHをさらに統合した無料のオープンソースソフトウェア実装がいくつかあります。[ 50 ] Unix、Apple iOS、Linux、Android、Windowsなど、さまざまなオペレーティングシステムで利用できます。

セキュリティ問題

初期のインターネットは一般の人々が参加できるネットワークではなかったため、DNSソフトウェアや、初期のインターネットに導入されるソフトウェアにおいては、セキュリティ上の懸念は設計上の主要な考慮事項ではありませんでした。しかし、1990年代にインターネットが商業分野に拡大したことで、データの整合性とユーザー認証を保護するためのセキュリティ対策の要件は変化しました。

複数の脆弱性が発見され、悪意のあるユーザーによって悪用されました。その一つがDNSキャッシュポイズニングです。これは、権威あるオリジンサーバーを装ってキャッシュリゾルバーにデータを分散させ、データストアを潜在的に虚偽の情報や長い有効期限（TTL）で汚染するものです。その結果、正当なアプリケーションリクエストが悪意を持って運営されているネットワークホストにリダイレクトされる可能性があります。

DNS応答には従来、暗号署名がないため、多くの攻撃を受ける可能性があります。ドメインネームシステムセキュリティ拡張機能（DNSSEC）は、DNSを改良し、暗号署名された応答をサポートします。[ 51 ] DNSCurveはDNSSECの代替として提案されています。TSIGなどの他の拡張機能は、信頼できるピア間の暗号認証をサポートし、ゾーン転送や動的更新操作の承認によく使用されます。

前方確認逆 DNSなどの手法も、DNS 結果の検証に役立ちます。

DNS は、設定に注意を払わなければ、本来は安全またはプライベートな接続から「漏洩」する可能性があり、また、DNS は無害であると見なされることが多いため、悪意のある人物によってファイアウォールを回避し、データを盗み出すために使用されることもあります。

DNSスプーフィング

一部のドメイン名は、なりすまし効果を得るために利用されることがあります。例えば、paypal.comとpaypa1.comは異なる名前ですが、ユーザーが選択した書体によっては、グラフィカルユーザーインターフェースでそれらを区別できない場合があります。多くのフォントでは、文字「l」と数字「1」は非常によく似ており、場合によっては同一に見えることもあります。この問題はIDN同形異義語攻撃として知られており、国際化ドメイン名をサポートするシステムでは深刻です。ISO 10646の多くの文字コードは、一般的なコンピュータ画面では同一に見える可能性があるためです。この脆弱性は、フィッシングで悪用されることがあります。[ 52 ]

DNSメッセンジャー

DNSMessenger [ 53 ] [ 54 ] [ 55 ] [ 56 ]は、従来のプロトコルに依存せず、DNSを利用してマルウェアと通信・遠隔制御を行うサイバー攻撃手法の一種です。DNSは主にドメイン名解決に利用されており、ネットワークセキュリティツールによる綿密な監視が行われていないことが多いため、DNSMessenger攻撃は巧妙に隠蔽され、攻撃者にとって効果的なチャネルとなっています。

この手法では、DNS TXTレコードを用いて感染システムにコマンドを送信します。マルウェアが被害者のマシンに密かにインストールされると、制御されたドメインにアクセスし、DNSテキストレコードにエンコードされたコマンドを取得します。この形式のマルウェア通信はステルス性が高く、DNSリクエストは通常​​ファイアウォールを通過できます。また、DNSトラフィックは無害と見なされることが多いため、これらの通信は多くのネットワークセキュリティ防御を回避できます。

DNSMessenger攻撃は、従来のネットワークセキュリティ対策の網を潜り抜けながら、データの窃取から追加ペイロードの配信まで、多岐にわたる悪意ある活動を可能にします。こうした手法を理解し、防御することは、強固なサイバーセキュリティを維持するために不可欠です。

プライバシーと追跡の問題

DNSプロトコルは、もともと公開型、階層型、分散型、かつ大量のキャッシュを持つデータベースとして設計されており、機密性に関する制御機能を備えていません。ユーザーからのクエリとネームサーバーの応答は暗号化されずに送信されるため、ネットワークパケットスニッフィング、DNSハイジャック、DNSキャッシュポイズニング、中間者攻撃が可能になります。この欠陥は、サイバー犯罪者やネットワーク事業者によって、マーケティング目的、キャプティブポータルにおけるユーザー認証、そして検閲に悪用されることがよくあります。[ 57 ]

コンテンツ配信ネットワークの利益のために DNS クエリ内のクライアント IP 情報のレベルを上げる提案 (RFC 7871) により、ユーザーのプライバシーがさらに危険にさらされます。

DNS のプライバシー問題に対処するために使用されている主なアプローチは次のとおりです。

ローカルネットワークオペレータによるDNS検査を阻止するソリューションは、企業のネットワークセキュリティポリシーやインターネット検閲を阻害するとして批判されてきた。また、パブリックDNSサーバーは、DNS解決の制御をパブリックリゾルバを運用できる少数の大企業の手に委ねることで、インターネットの中央集権化を助長するとして批判されている。[ 57 ]

Googleは、 Androidのプラットフォーム、Chromeのブラウザ、そして8.8.8.8サービスのDNSリゾルバの主要プロバイダーです。このシナリオは、単一の企業がインターネットの名前空間全体を包括的に管理する立場にあるケースと言えるでしょうか？ Netflixは すでに、アプリが稼働するプラットフォームとは独立した独自のDNS解決メカニズムを使用するアプリをリリースしています。もしFacebookアプリにDoHが組み込まれていたらどうなるでしょうか？ AppleのiOSがDoH解決メカニズムを使用してローカルDNS解決をバイパスし、AppleプラットフォームからのすべてのDNSクエリをAppleが運営するネームリゾルバに誘導していたらどうなるでしょうか？

— DNSプライバシーとIETF

ドメイン名登録

ドメイン名の使用権は、インターネットの名称と番号のシステムの監督を担う、インターネットネームアンドナンバーズ機構（ICANN）やOpenNICなどの組織から認定を受けたドメイン名登録機関によって委任されます。ICANNに加えて、各トップレベルドメイン（TLD）は、レジストリを運営する管理組織によって技術的に維持・管理されています。レジストリという用語はTLDを指すのが最も一般的ですが、レジストリは自身の権限ゾーン内の名前のデータベースを運用する責任を負っています。登録者とは、ドメイン登録を依頼した個人または組織です。[ 24 ] レジストリは、対応するゾーンで名前を割り当てる権限（認定）を持つ各ドメイン名登録機関から登録情報を受け取り、 WHOISプロトコルを使用して情報を公開します。2015年現在、RDAPの使用が検討されています。[ 58 ]

ICANNは、TLD、TLDレジストリ、およびドメイン名レジストラの完全なリストを公開しています。ドメイン名に関連付けられた登録者情報は、WHOISサービスでアクセスできるオンラインデータベースで管理されています。290を超える国別コードトップレベルドメイン（ccTLD）のほとんどについては、ドメインレジストリがWHOIS情報（登録者、ネームサーバー、有効期限など）を管理しています。例えば、ドイツのNICであるDENICは、DEドメインデータを保有しています。2001年頃から、ほとんどのジェネリックトップレベルドメイン（gTLD）レジストリは、いわゆるシックレジストリ方式を採用しています。つまり、WHOISデータをレジストラデータベースではなく中央レジストリに保管する方式です。

COMおよびNETのトップレベルドメインでは、シンレジストリモデルが採用されています。ドメインレジストリ（GoDaddy、BigRock、PDR、VeriSignなど）は、基本的なWHOISデータ（レジストラやネームサーバーなど）を保有しています。一方、組織（ORGを使用する登録者）は、Public Interest Registryのみに登録されます。

一部のドメイン名レジストリ（ネットワーク情報センター（NIC）と呼ばれることが多い）は、WHOISデータセットへのアクセスを提供することに加えて、エンドユーザーへのレジストラとしての機能も果たしています。COM、NET、ORGなどのドメインのトップレベルドメインレジストリは、多数のドメイン名レジストラからなるレジストリ・レジストラモデルを採用しています。[ 59 ]この管理方法では、レジストリはドメイン名データベースとレジストラとの関係のみを管理します。登録者（ドメイン名のユーザー）はレジストラの顧客であり、場合によっては再販業者への下請け契約を通じて顧客となることもあります。

参照

参考文献

  1. ^ Wu, Hao; Dang, Xianglei; Wang, Lidong; He, Longtao (2016). 「分散型ドメインネームシステムキャッシュポイズニング攻撃の検出と識別のための情報融合ベースの手法」 . IET情報セキュリティ. 10 (1): 37– 44. doi : 10.1049/iet-ifs.2014.0386 . ISSN 1751-8717 . S2CID 45091791 .  
  2. ^ J. Postel編 (1981年9月).インターネットプロトコル - DARPAインターネットプログラムプロトコル仕様. IETF . doi : 10.17487/RFC0791 . STD 5. RFC 791. IEN 128, 123, 111, 80, 54, 44, 41, 28, 26.インターネット標準5。RFC 760を  廃止。RFC 1349、2474、6864 により更新。​
  3. ^ J. Dilley、B. Maggs、J. Parikh、H. Prokop、R. Sitaraman、B. Weihl.「Globally Distributed Content Delivery」、IEEE Internet Computing、2002年9月/10月号、pp. 50–58 (PDF)。2015年4月17日時点のオリジナルよりアーカイブ(PDF) 。
  4. ^ Nygren., E.; Sitaraman RK; Sun, J. (2010). 「Akamaiネットワーク：高性能インターネットアプリケーションのためのプラットフォーム」（PDF） . ACM SIGOPS Operating Systems Review . 44 (3): 2– 19. doi : 10.1145/1842733.1842736 . S2CID 207181702. 2010年12月2日時点のオリジナルよりアーカイブ（PDF） . 2012年11月19日閲覧。 
  5. ^ a b c d e f g P. Mockapetris (1987年11月).ドメイン名 - 実装と仕様. ネットワークワーキンググループ. doi : 10.17487/RFC1035 . STD 13. RFC 1035 .インターネット標準13。RFC 882、883、973は  廃止さ れます。RFC 1101、1183、1348、1876、1982、1995、1996、2065、2136、2137、2181、2308、2535、2673、2845、3425、3658、4033、4034、4035、4343、5936、5966、6604、7766、8482、8490、8767により更新されます。​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​
  6. ^チャンピカ ウィジャヤトゥンガ (2015 年 2 月)。「DNS 悪用への対応」(PDF)。アプニック。2015 年 12 月 22 日にオリジナルからアーカイブ(PDF)されました。2016 年12 月 18 日に取得。
  7. ^ J. Klensin (2003年2月).ドメインネームシステム（DNS）の役割. ネットワークワーキンググループ. doi : 10.17487/RFC3467 . RFC 3467 .情報提供。
  8. ^ Liu, Cricket; Albitz, Paul (2006). DNS and BIND (第5版). O'Reilly Media. p. 3. ISBN 978-0-596-10057-5。
  9. ^エヴァンス 2018、112ページ。
  10. ^エヴァンス 2018、113ページ。
  11. ^ IEEE Annals [3B2-9] man2011030074.3d 2011年7月29日 11:54 ページ74
  12. ^ a b「なぜクリスマスでもネットは使えるのか？ポール・モカペトリス - インターネットの殿堂」 internethalloffame.org 2012年7月23日。
  13. ^ a bエヴァンス 2018、119頁。
  14. ^エヴァンス 2018、120ページ。
  15. ^エヴァンス 2018、120～121頁。
  16. ^ 「エリザベス・ファインラー」。インターネットの殿堂。2018年9月14日時点のオリジナルよりアーカイブ。2018年11月25日閲覧。
  17. ^ 「Paul Mockapetris | インターネットの殿堂」 . internethalloffame.org . 2020年2月12日閲覧。
  18. ^ Andrei Robachevsky (2013年11月26日). 「DNS、30周年おめでとう！」 .インターネット協会. 2015年12月18日閲覧。
  19. ^エリザベス・ファインラー、IEEE Annals、3B2-9 man2011030074.3d 2011年7月29日 11:54 ページ74
  20. ^ P. Mockapetris (1986年2月).ドメインシステムの変更と考察. ネットワークワーキンググループ. doi : 10.17487/RFC0973 . RFC 973 .廃止。RFC 1034 および1035により 廃止。RFC 882 および883を更新。
  21. ^ Terry, Douglas B.; et al. (1984年6月12日～15日). 「Berkeley Internet Name Domain Server」 . 1984年ソルトレイクシティ夏季会議: 議事録. USENIX Association Software Tools Users Group. pp.  23～ 31.
  22. ^ Internet Systems Consortium. 「BINDの歴史」 . BINDの歴史. 2019年6月30日時点のオリジナルよりアーカイブ。 2022年4月4日閲覧。
  23. ^ a b c d e f g h P. Mockapetris (1987年11月).ドメイン名 - 概念と機能. ネットワークワーキンググループ. doi : 10.17487/RFC1034 . STD 13. RFC 1034 .インターネット標準13。RFC 882、883、973は  廃止。RFC 1101、1183、1348、1876、1982、2065、2181、2308、2535、4033、4034、4035、4343、4592、5936、8020、8482、8767 により更新。​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​
  24. ^ a b P. Hoffman; A. Sullivan; K. Fujiwara (2015年12月). DNS用語集.インターネット技術タスクフォース. doi : 10.17487/RFC7719 . ISSN 2070-1721 . RFC 7719 . 廃止。RFC 8499  により廃止されました。
  25. ^リンゼイ、デイビッド（2007年）『国際ドメイン名法：ICANNとUDRP』ブルームズベリー出版、p.8、ISBN 978-1-84113-584-7。
  26. ^ D. Eastlake, 3rd (2006年1月).ドメインネームシステム（DNS）の大文字と小文字の区別に関する明確化. ネットワークワーキンググループ. doi : 10.17487/RFC4343 . RFC 4343 .提案 された標準。RFC 5890 により更新。RFC 1034、1035、2181 を更新。
  27. ^ a b J. Klensin (2004年2月).名前のチェックと変換のためのアプリケーションテクニック. ネットワークワーキンググループ. doi : 10.17487/RFC3696 . RFC 3696 .情報提供。
  28. ^藤原一典、アンドリュー・サリバン、ポール・ホフマン (2024). 「DNS用語集」 . tools.ietf.org . doi : 10.17487/RFC9499 . 2024年7月1日閲覧。
  29. ^ Nemeth, Evi; Snyder, Garth; Hein, Trent R. (2006-10-30). Linux管理ハンドブック. Addison-Wesley Professional. ISBN 978-0-13-700275-7。
  30. ^ビシャンデ、テガウェンデ F.;しー、王麿（2017-10-09）。発展途上国のための電子インフラストラクチャと電子サービス: 第 8 回国際会議、AFRICOMM 2016、ワガドゥグー、ブルキナファソ、2016 年 12 月 6 ～ 7 日、議事録。スプリンガー。ISBN 978-3-319-66742-3。
  31. ^ 「DNSゾーン」 . IONOS Digitalguide . 2022年1月27日. 2022年3月31日閲覧。
  32. ^ 「DNS伝播とは何か？」 IONOS Digitalguide . 2022年4月22日閲覧。
  33. ^ 「プロバイダーはDNS TTLを無視しているのか？」 Slashdot 、 2005年。 2012年4月7日閲覧。
  34. ^ Ben Anderson (2011年9月7日). 「Ben Anderson: なぜWebブラウザのDNSキャッシュは悪影響なのか」 . 2014年10月20日閲覧。
  35. ^ 「Internet ExplorerがDNSホストエントリのキャッシュを使用する仕組み」 Microsoft Corporation 2004年 2010年7月25日閲覧。{{cite web}}: CS1 maint: url-status (リンク)
  36. ^ 「ドメインネームシステム（DNS）パラメータ」 IANA DNS RCODE 2019年6月14日閲覧。
  37. ^ James F. Kurose、Keith W. Ross著『コンピュータネットワーキング：トップダウンアプローチ』第6版、エセックス、イギリス：Pearson Educ. Limited、2012年
  38. ^ a b D. Eastlake 3rd (2013年4月).ドメインネームシステム (DNS) に関するIANAの考慮事項.インターネット技術タスクフォース. doi : 10.17487/RFC6895 . ISSN 2070-1721 . BCP 42. RFC 6895 . 現在のベストプラクティス42。RFC 6195を  廃止。RFC 2845、2930、1183、3597 を更新。​
  39. ^ a b E. Lewis (2006年7月).ドメインネームシステムにおけるワイルドカードの役割. ネットワークワーキンググループ. doi : 10.17487/RFC4592 . RFC 4592 .提案された標準。RFC 2672 および1034を 更新します。
  40. ^ S. Thomson; Y. Rekhter ; J. Bound (1997年4月). P. Vixie (編).ドメインネームシステムの動的更新 (DNS UPDATE) . IETFネットワークワーキンググループ. doi : 10.17487/RFC2136 . RFC 2136 .提案された標準。RFC 1035 を 更新。RFC 3007、4033、4034、4035 により更新。
  41. ^ RFC 2671、 DNSの拡張メカニズム（EDNS0）、P. Vixie（1999年8月） 
  42. ^ Csikor, Levente; Divakaran, Dinil Mon (2021年2月). 「DNS over HTTPSのプライバシー：夢へのレクイエム？」(PDF) . シンガポール国立大学. DoHトラフィックと暗号化されたWebトラフィックを区別できるかどうかを調査する。この目的のため、HTTPSトラフィックをWebまたはDoHに分類する機械学習モデルを訓練する。このDoH識別モデルを用いることで、権威主義的なISPはDoHパケットの約97.4%を正しく識別できる一方で、Webパケットの誤分類は10,000個中1個のみであることを示す。
  43. ^ Huitema, Christian; Dickinson, Sara; Mankin, Allison (2022年5月). DNS over Dedicated QUIC Connections . Internet Engineering Task Force. doi : 10.17487/RFC9250 . RFC 9250 .
  44. ^ Schmitt, Paul; Edmundson, Anne; Feamster, Nick (2019). 「Oblivious DNS: DNSクエリの実践的なプライバシー」(PDF) . Privacy Enhancing Technologies . 2019 (2): 228– 244. arXiv : 1806.00276 . doi : 10.2478/popets-2019-0028 . S2CID 44126163. 2022年1月21日時点のオリジナルよりアーカイブ(PDF) . 
  45. ^ 「CloudflareとAppleがOblivious DNSを導入」 2020年12月9日. 2022年7月27日閲覧。
  46. ^ Pauly, Tommy (2021年9月2日). 「Oblivious DNS Over HTTPS」 IETF.
  47. ^マフェット、アレック（2021年2月）。「ポート53番は不要？ 一体誰だ？」Tor経由のDNS over HTTPSの1年（PDF）。ネットワークおよび分散システムセキュリティシンポジウム。2021年3月21日時点のオリジナルからアーカイブ（PDF） 。DNS over HTTPS（DoH）は多くのリスクを回避しますが、全てではありません。また、そのトランスポートプロトコル（HTTPS）は、例えば「Cookie」によるプライバシーの懸念を引き起こします。Torネットワークは、TCP回線に追跡、監視、ブロッキングからの自由を提供するために存在します。そこで、Tor、DoH、そしてリクエストフィンガープリンティングを軽減するための「Don't Do That, Then」（DDTT）の原則と組み合わせた、Tor経由のDNS over HTTPS（DoHoT）について説明します。
  48. ^ Ulevitch, David (2011年12月6日). 「DNSCrypt – Critical, fundamental, and about time」 . Cisco Umbrella . 2020年7月1日時点のオリジナルよりアーカイブ。
  49. ^ 「匿名化DNSCrypt仕様」 . GitHub . DNSCrypt. 2019年10月25日時点のオリジナルよりアーカイブ。
  50. ^ 「Oblivious DoH · DNSCrypt/dnscrypt-proxy Wiki」 . GitHub . DNSCryptプロジェクト. 2022年7月28日閲覧。
  51. ^ Herzberg, Amir; Shulman, Haya (2014-01-01). 「ネットワークプロトコルへのセキュリティのレトロフィット：DNSSECの事例」. IEEE Internet Computing . 18 (1): 66– 71. Bibcode : 2014IIC....18a..66H . doi : 10.1109/MIC.2014.14 . ISSN 1089-7801 . S2CID 12230888 .  
  52. ^ APWG. 「グローバルフィッシング調査：2010年上半期のドメイン名の利用状況と傾向」 2010年10月15日 apwg.org 2012年10月3日アーカイブ（ Wayback Machine）
  53. ^ 「DNSMessenger（マルウェアファミリー）」malpedia.caad.fkie.fraunhofer.de . 2024年12月11日閲覧。
  54. ^ Khandelwal, Swati (2017年3月6日). 「新たなファイルレスマルウェア、DNSクエリを利用してPowerShellコマンドを受信」 . The Hacker News . 2024年12月11日閲覧。
  55. ^ Brumaghin, Edmund (2017年3月2日). 「Covert Channels and Poor Decisions: The Tale of DNSMessenger」 . Cisco Talos Blog . 2024年12月11日閲覧。
  56. ^ Bombal, David (2023年5月26日). 「DNSがまたやってきた😢 このマルウェアハックをご存知でしたか？ 」 2024年12月11日閲覧– YouTubeより。
  57. ^ a b Huston, Geoff (2019年7月). 「DNSプライバシーとIETF」(PDF) . The Internet Protocol Journal . 2019年9月30日時点のオリジナルよりアーカイブ(PDF) .
  58. ^ 「gTLDレジストリおよびレジストラ向け登録データアクセスプロトコル（RDAP）運用プロファイル」ICANN 2015年12月3日。2015年12月22日時点のオリジナルよりアーカイブ。 2015年12月18日閲覧。
  59. ^ 「レジストラを探す」 VeriSign, Inc. 2015年12月18日閲覧。

出典

さらに読む

標準化トラック

  • RFC  1034 –「ドメイン名 - 概念と機能」 、インターネット標準 13。
  • RFC  1035 –「ドメイン名 - 実装と仕様」 、インターネット標準 13。
  • RFC  1123 –「インターネット ホストの要件 - アプリケーションとサポート」 、インターネット標準 3。
  • RFC  1995 –「DNS における増分ゾーン転送」 、提案標準。
  • RFC  1996 –「ゾーン変更の迅速な通知のメカニズム (DNS NOTIFY)」 、提案標準。
  • RFC  2136 –「ドメイン ネーム システムの動的更新 (DNS UPDATE)」 、提案標準。
  • RFC  2181 –「DNS 仕様の明確化」 、提案標準。
  • RFC  2308 –「DNS クエリのネガティブ キャッシュ (DNS NCACHE)」 、提案標準。
  • RFC  3225 –「DNSSEC のリゾルバサポートの指定」 、提案標準。
  • RFC  3226 –「DNSSEC および IPv6 A6 対応サーバー/リゾルバーのメッセージ サイズ要件」 、提案標準。
  • RFC  3596 –「IP バージョン 6 をサポートするための DNS 拡張」 、インターネット標準 88。
  • RFC  3597 –「不明な DNS リソース レコード (RR) タイプの処理」 、提案標準。
  • RFC  4343 –「ドメイン ネーム システム (DNS) の大文字と小文字の区別の明確化」 、提案標準。
  • RFC  4592 –「ドメイン ネーム システムにおけるワイルドカードの役割」 、提案標準。
  • RFC  5001 –「DNS ネーム サーバー識別子 (NSID) オプション」 、提案標準。
  • RFC  5011 –「DNS セキュリティ (DNSSEC) トラスト アンカーの自動更新」 、インターネット標準 74。
  • RFC  5452 –「偽造された回答に対する DNS の耐性を高めるための対策」 、提案された標準。
  • RFC  5890 –「アプリケーション用国際化ドメイン名 (IDNA): 定義とドキュメント フレームワーク」 、提案標準。
  • RFC  5891 –「アプリケーションにおける国際化ドメイン名 (IDNA): プロトコル」 、提案標準。
  • RFC  5892 –「アプリケーション用の Unicode コード ポイントと国際化ドメイン名 (IDNA)」 、提案標準。
  • RFC  5893 –「アプリケーション用国際化ドメイン名の右から左へのスクリプト (IDNA)」 、提案標準。
  • RFC  6672 –「DNS での DNAME リダイレクト」 、提案標準。
  • RFC  6891 –「DNSの拡張メカニズム（EDNS(0)）」 、インターネット標準75。
  • RFC  7766 –「TCP 経由の DNS トランスポート - 実装要件」 、提案標準。
  • RFC  8490 –「DNS ステートフル操作」 、提案標準。
  • RFC  8945 –「DNS の秘密キートランザクション認証 (TSIG)」 、インターネット標準 93。
  • RFC  9103 –「TLS 経由の DNS ゾーン転送」 、提案標準。
  • RFC  9156 –「プライバシーを向上させるための DNS クエリ名の最小化」 、提案された標準。

提案されたセキュリティ標準

  • RFC  4033 –「DNS セキュリティの概要と要件」 、提案標準。
  • RFC  4034 –「DNS セキュリティ拡張のリソース レコード」 、提案標準。
  • RFC  4035 –「DNS セキュリティ拡張のプロトコル変更」 、提案標準。
  • RFC  4470 –「NSEC レコードの最小限のカバーと DNSSEC オンライン署名」 、提案標準。
  • RFC  4509 –「DNSSEC 委任署名者 (DS) リソース レコード (RR) での SHA-256 の使用」 、提案標準。
  • RFC  5155 –「DNS セキュリティ (DNSSEC) ハッシュ認証による存在拒否」 、提案標準。
  • RFC  5702 –「DNSSEC の DNSKEY および RRSIG リソース レコードでの RSA による SHA-2 アルゴリズムの使用」 、提案標準。
  • RFC  5910 –「拡張プロビジョニング プロトコル (EPP) のドメイン ネーム システム (DNS) セキュリティ拡張マッピング」 、提案標準。
  • RFC  5933 – 「DNSSECにおけるDNSKEYおよびRRSIGリソースレコードにおけるGOST署名アルゴリズムの使用」 、歴史的。 2024年にRFC  9558によって歴史的ステータスに変更。RFC 6944によって更新。（情報RFC の項を参照）
  • RFC  7830 –「EDNS(0) パディング オプション」 、提案標準。
  • RFC  7858 –「DNS over Transport Layer Security (TLS) の仕様」 、提案標準。
  • RFC  8310 –「DNS over TLS および DNS over DTLS の使用プロファイル」 、提案標準。
  • RFC  8484 –「HTTPS 経由の DNS クエリ (DoH)」 、提案標準。

実験的なRFC

  • RFC  1183 –「新しい DNS RR 定義」 、実験的。

現在のベストプラクティス

  • RFC  2182 –「セカンダリ DNS サーバーの選択と操作」 、現在のベスト プラクティス 16。
  • RFC  2317 –「クラスレス IN-ADDR.ARPA 委任」 、現在のベスト プラクティス 20。
  • RFC  5625 –「DNS プロキシ実装ガイドライン」 、現在のベストプラクティス 152。
  • RFC  6895 –「ドメイン ネーム システム (DNS) IANA に関する考慮事項」 、現在のベスト プラクティス 42。
  • RFC  7720 –「DNS ルート ネーム サービス プロトコルおよび展開要件」 、現在のベスト プラクティス 40。
  • RFC  9499 –「DNS 用語」 、現在のベストプラクティス 219。

情報RFC

これらのRFCは本質的には助言的なものですが、標準やBCPを定義していないにもかかわらず、有用な情報を提供する可能性があります。[ 1 ]

  • RFC  1178 –「コンピュータの名前の選択」 、情報、参考情報 5。
  • RFC  1591 –「ドメイン ネーム システムの構造と委任」 、情報。
  • RFC  1912 –「一般的な DNS 操作および構成エラー」 、情報。
  • RFC  2100 –「ホストの命名」 、情報。
  • RFC  3696 –「名前の確認と変換のアプリケーション技術」情報。
  • RFC  3833 –「ドメイン ネーム システム (DNS) の脅威分析」 、情報。
  • RFC  4892 –「RIPv2 暗号化認証」 、情報。
  • RFC  5894 –「アプリケーション用国際化ドメイン名 (IDNA): 背景、説明、および根拠」 、情報。
  • RFC  5895 –「アプリケーションにおける国際化ドメイン名の文字のマッピング (IDNA) 2008」 、情報。
  • RFC  8806 –「リゾルバに対してローカルなルート サーバーの実行」情報。
  • RFC  9076 –「DNS プライバシーに関する考慮事項」 、情報。
  • RFC  9558 –「DNSSEC の DNSKEY および RRSIG リソース レコードでの GOST 2012 署名アルゴリズムの使用」情報。

未知

これらの RFC の公式ステータスは「不明」ですが、古いため、そのように明確にラベル付けされていません。

  • RFC  920 – 「ドメイン要件」 、ステータス不明。 – 指定されたオリジナルのトップレベルドメイン
  • RFC  1032 –「ドメイン管理者ガイド」 、ステータスは不明です。
  • RFC  1033 –「ドメイン管理者操作ガイド」 、ステータス不明。
  • RFC  1101 –「ネットワーク名およびその他のタイプの DNS エンコーディング」 、ステータスは不明です。
Wikiversityにはドメインネームシステムに関する学習リソースがあります
  1. ^ C. Huitema ; J. Postel ; S. Crocker (1995年4月). 「すべてのRFCが標準であるとは限らない」. ネットワークワーキンググループ. doi : 10.17487/RFC1796 . RFC 1796 .情報提供。
「 https://en.wikipedia.org/w/index.php?title=Domain_Name_System&oldid=1337166788#Circular_dependencies_and_glue_records」より取得