Loading article…
ドメインネームシステム（DNS）は、インターネットまたはその他のインターネットプロトコル（IP）ネットワーク上のコンピュータ、サービス、およびその他のリソースに名前付けシステムを提供する階層型分散型ネームサービスです。DNSは、関連する各エンティティに割り当てられたドメイン名（識別文字列）にさまざまな情報を関連付けます。最も重要なのは、覚えやすいドメイン名を、基盤となるネットワークプロトコルを使用してコンピュータサービスやデバイスを特定および識別するために必要な数値IPアドレスに変換することです。[ 1 ]ドメインネームシステムは、1985年以来、インターネットの機能の不可欠なコンポーネントとなっています。
ドメインネームシステム (DNS) は、各ドメインに権威ネームサーバーを指定することで、ドメイン名の割り当てとそれらの名前をインターネット リソースにマッピングする責任を委任します。ネットワーク管理者は、割り当てられたネームスペースのサブドメインに対する権限を他のネームサーバーに委任することができます。このメカニズムは分散型で耐障害性のあるサービスを提供し、単一の大規模な中央データベースを回避するように設計されています。さらに、DNS はその中核となるデータベースサービスの技術的機能を規定します。DNS は、インターネット プロトコル スイートの一部として、DNS で使用されるデータ構造とデータ通信交換の詳細な仕様である DNS プロトコルを定義します。[ 2 ] [ 1 ]
インターネットは、ドメイン名階層とIPアドレス空間という2 つの主要な名前空間を維持しています。[ 3 ]ドメイン ネーム システム (DNS) は、ドメイン名階層を維持し、ドメイン名階層とアドレス空間間の変換サービスを提供します。インターネット ネーム サーバーと通信プロトコルがドメイン ネーム システム (DNS) を実装しています。DNS ネームサーバーは、ドメインの DNS レコードを保存するサーバーであり、データベースに対するクエリに応答します。
DNSデータベースに格納される最も一般的なレコードの種類は、権限開始レコード（SOA）、IPアドレス（AレコードとAAAAレコード）、SMTPメール交換局（MXレコード）、ネームサーバー（NSレコード）、逆引きDNSルックアップ用ポインタ（PTRレコード）、ドメイン名エイリアス（CNAMEレコード）です。DNSは汎用データベースとして設計されたものではありませんが、時間の経過とともに、DNSSECレコードなどの自動ルックアップ用、または責任者（RP）レコードなどの人間によるクエリ用の他の種類のデータを格納するように拡張されてきました。汎用データベースとして、DNSはブロックリストを格納することで迷惑メール（スパム）対策にも使用されています。DNSデータベースは通常、構造化されたテキストファイルであるゾーンファイルに格納されますが、他のデータベースシステムも一般的です。
ドメインネームシステム（DNS）は当初、 IP上での通信手段としてユーザーデータグラムプロトコル（UDP）を使用していた。しかし、信頼性、セキュリティ、プライバシーに関する懸念から、伝送制御プロトコル（TCP）をはじめとする数多くのプロトコルが開発されるに至った。
DNSを説明する際によく用いられる例えは、人間が理解しやすいコンピュータのホスト名をIPアドレスに変換することで、インターネットの電話帳のような役割を果たすというものです。例えば、ドメイン名example.com内のホスト名は、 IPv4では93.184.216.34 、IPv6では2606:2800:220:1:248:1893:25c8:1946というアドレスに変換されます。DNSは迅速かつ透過的に更新できるため、エンドユーザーは同じホスト名を使い続けることができ、ネットワーク上のサービスの場所が変更されても影響はありません。ユーザーは、コンピュータが実際にどのようにサービスを特定しているかを意識することなく、意味のあるURL （Uniform Resource Locator ）や電子メールアドレスを使用することで、この利点を享受できます。www.example.com
DNS の重要かつ普遍的な機能の一つは、クラウド サービスやコンテンツ デリバリー ネットワークなどの分散型インターネット サービスにおける中心的な役割です。[ 4 ]ユーザーが URL を使用して分散型インターネット サービスにアクセスすると、URLのドメイン名が、ユーザーに近いサーバーの IP アドレスに変換されます。ここで利用される DNS の重要な機能は、異なるユーザーが同じドメイン名に対して同時に異なる変換を受け取ることができる点であり、これは DNS の従来の電話帳的な見方からの重要な相違点です。DNS を使用してユーザーに近接サーバーを割り当てるこのプロセスは、インターネット上でより高速で信頼性の高い応答を提供する上で重要であり、ほとんどの主要なインターネット サービスで広く使用されています。[ 5 ]
DNSはインターネット上の管理責任の構造を反映しています。[ 6 ]各サブドメインは、管理者に委任された管理上の自律性の領域です。レジストリによって運営されている領域の場合、管理情報は多くの場合、レジストリのRDAPおよびWHOISサービスによって補完されます。このデータは、インターネット上の特定のホストに関する洞察を得たり、その責任を追跡したりするために使用できます。[ 7 ]
ホストの数値アドレスの代わりに、よりシンプルで覚えやすい名前を使用するようになったのは、ARPANET の時代に遡ります。スタンフォード研究所 (現在のSRI International )は、ARPANET 上のコンピュータの数値アドレスにホスト名をマッピングするHOSTS.TXTというテキスト ファイルを管理していました。 [ 8 ] [ 9 ]エリザベス・ファインラーは、最初の ARPANET ディレクトリを開発し、管理しました。[ 10 ] [ 11 ]割り当て番号リストと呼ばれる数値アドレスの管理は、南カリフォルニア大学の情報科学研究所(ISI) のジョン・ポステルが担当し、彼のチームは SRI と密接に協力していました。[ 12 ]
アドレスは手動で割り当てられました。ホスト名とアドレスを含むコンピュータは、営業時間中に電話でファインラーが指揮するSRIネットワーク情報センター（NIC）に連絡することにより、プライマリファイルに追加されました。 [ 13 ]その後、ファインラーはリソース、連絡先、エンティティに関する情報を取得するために、NICのサーバー上にWHOISディレクトリを設定しました。 [ 14 ]彼女と彼女のチームはドメインの概念を開発しました。[ 14 ]ファインラーは、ドメインはコンピュータの物理的なアドレスの場所に基づいているべきだと提案しました。[ 15 ]例えば、教育機関のコンピュータにはeduドメインが付けられます。 [ 16 ]彼女と彼女のチームは、1972年から1989年までホスト命名レジストリを管理しました。[ 17 ]
1980年代初頭までに、単一の中央ホストテーブルを維持することは遅く扱いにくくなり、出現したネットワークは技術的および人的問題に対処するために自動命名システムを必要とした。ポステルは、競合する5つの解決策の提案の間で妥協点を見出す作業をポール・モカペトリスに指示した。モカペトリスは代わりに、南カリフォルニア大学に在籍していた1983年にドメインネームシステム（DNS）を作成した。[ 13 ] [ 18 ]
インターネット技術タスクフォースは、 1983年11月にRFC 882とRFC 883で最初の仕様を公開しました。[ 19 ] [ 20 ]これらは1986年1月にRFC 973で更新されました。[ 21 ]
1984 年、カリフォルニア大学バークレー校の学生 4 人、Douglas Terry、Mark Painter、David Riggle、Songnian Zhou が、Berkeley Internet Name Domain の最初のUnixネーム サーバー実装 (一般にBINDと呼ばれる) を作成しました。[ 22 ] 1985 年、DECの Kevin Dunlap がDNS 実装を大幅に改訂しました。その後、 Mike Karels、Phil Almquist、Paul VixieがBIND のメンテナンスを引き継ぎました。インターネット システム コンソーシアム (ISC)は、BIND の開発とメンテナンスの拠点を提供するために、1994 年にRick Adams、Paul Vixie、Carl Malamudによって設立されました。BIND バージョン 4.9.3 以降は、ISC のスポンサーのサポートを受けて、ISC によって開発およびメンテナンスされました。共同アーキテクト/プログラマーとして、ボブ・ハレーとポール・ヴィクシーは、1997年5月にBINDバージョン8の最初の製品版をリリースしました。2000年以降、43人以上の異なるコア開発者がBINDの開発に携わってきました。[ 23 ]
1987年11月、RFC 1034 [ 24 ]とRFC 1035 [ 6 ]が1983年のDNS仕様に取って代わりました。いくつかの追加のRequest for Commentsでは、コアDNSプロトコルの拡張が提案されています。[ 25 ]
ドメイン名空間はツリーデータ構造で構成されています。ツリー内の各ノード（葉）にはラベルと、ドメイン名に関連付けられた情報を保持する0個以上のリソースレコード（RR）があります。ドメイン名自体は、ラベルと、右側の親ノードの名前をドットで区切って連結したものです。[ 24 ]： §3.1
ツリーはルートゾーンから始まるゾーンに分割されます。DNSゾーンは、ゾーンマネージャが選択した数のドメインとサブドメインで構成できます。DNSはクラスごとに分割することもでき、個々のクラスは並列名前空間ツリーの配列と考えることができます。[ 24 ]： §4.2
ゾーンの管理責任は、追加のゾーンを作成することによって分割することができます。新しいゾーンに対する権限は、指定されたネームサーバーに委任されたと言われます。親ゾーンは、新しいゾーンに対して権限を失います。[ 24 ]： §4.2
ドメイン名の構成規則に関する決定的な記述は、RFC 1035、RFC 1123、RFC 2181、およびRFC 5892に記載されています。ドメイン名は、技術的にはラベルと呼ばれる1つ以上の部分で構成され、慣習的に連結され、ドットで区切られます。例: example.com。
一番右のラベルはトップレベルドメインを表します。たとえば、ドメイン名 www.example.com はトップレベルドメインcomに属します。
ドメインの階層は右から左に下降します。左側の各ラベルは、右側のドメインのサブディビジョン、つまりサブドメインを指定します。たとえば、ラベルexample はcomドメインのサブドメインを指定し、wwwは example.com のサブドメインです。このサブディビジョンのツリーは最大 127 レベルまであります。[ 26 ]
ラベルには、長さが 6 ビットしか使用できないため、0 ～ 63 文字を含めることができます。長さが 0 のヌル ラベルはルート ゾーン用に予約されています。完全なドメイン名は、テキスト表現では 253 文字 (末尾のドットを含めると 254 文字) を超えることはできません。[ 24 ] DNS の内部バイナリ表現では、この最大長 253 には 255 オクテットのストレージが必要です。これは、多数のラベルの最初の長さも格納し、最後のヌル バイトを追加するためです。[ 6 ] 255 の長さは、少なくとも 6 個のラベル (最後のヌル ラベルを含む) でのみ達成されます。[ 6 ]
ドメイン名ラベルにオクテットで表現できる文字を使用することを妨げる技術的な制限はありませんが、ホスト名には推奨される形式と文字セットが使用されます。ラベルに使用できる文字はASCII文字セットのサブセットで、文字a～z、A～Z、数字0～9、およびハイフンで構成されます。このルールはLDHルール（文字、数字、ハイフン）として知られています。ドメイン名は大文字と小文字を区別せずに解釈されます。[ 27 ]ラベルはハイフンで開始または終了することはできません。[ 28 ]さらに、トップレベルドメイン名はすべて数字であってはならないというルールがあります。[ 28 ]
DNSで許可されているASCII文字セットが限られていたため、多くの言語の名前や単語をその言語のネイティブのアルファベットや文字で表現することができませんでした。これを可能にするため、ICANNは、WebブラウザなどのユーザーアプリケーションがPunycodeを使用してUnicode文字列を有効なDNS文字セットにマッピングする、国際化ドメイン名アプリケーション（IDNA）システムを承認しました。2009年、ICANNは国際化ドメイン名国別コードトップレベルドメイン（ccTLD）の導入を承認しました。さらに、既存のトップレベルドメイン名（TLD）の多くのレジストリが、RFC 5890、RFC 5891、RFC 5892、RFC 5893に準拠したIDNAシステムを採用しています。
DNS名前空間のさまざまな部分の責任を異なるネームサーバーに割り当てるメカニズムは委任と呼ばれます。トップレベルドメインの下にあるすべてのパブリックネットワークドメインは、親ドメインに委任された（または子）ドメインのネームサーバーのDNS名を指すNSレコードを持つことで委任されます。これらのネームサーバーが委任されたドメインにある場合、親ドメインには子ドメインのネームサーバーのIPアドレスを含むグルーレコードも含まれていなければなりません。[ 29 ]
ドメインネームシステム（DNS）は、クライアント/サーバーモデルを使用する分散データベースシステムによって管理されています。このデータベースのノードはネームサーバーです。各ドメインには、そのドメインおよびそれに従属するドメインのネームサーバーに関する情報を公開する権威DNSサーバーが少なくとも1つ存在します。階層の最上位はルートネームサーバーによって提供され、 TLDを検索（解決）する際にクエリを実行するサーバーです。
権威ネームサーバーとは、ドメイン管理者や動的DNS方式など、元のソースによって設定されたデータに基づいてDNSクエリへの応答のみを提供するネームサーバーのことです。これに対し、データのキャッシュのみを保持する別のネームサーバーへのクエリによって得られる応答は、権威ネームサーバーとは異なります。
権威ネームサーバーは、プライマリサーバーまたはセカンダリサーバーのいずれかになります。歴史的には、マスター/スレーブとプライマリ/セカンダリという用語は互換的に使用されることがありましたが[ 30 ]、現在の慣習では後者の形式が使用されます。プライマリサーバーは、すべてのゾーンレコードのオリジナルコピーを保存するサーバーです。セカンダリサーバーは、プライマリと通信するDNSプロトコルの特別な自動更新メカニズムを使用して、プライマリレコードの同一のコピーを維持します。
すべてのDNSゾーンには、権威ネームサーバーのセットを割り当てる必要があります。このサーバーセットは、ネームサーバー（NS）レコードとともに親ドメインゾーンに格納されます。
権威サーバーは、応答に「権威応答」( AA )ビットと呼ばれるプロトコルフラグを設定することで、権威があるとみなされる確定的な回答を提供するステータスを示します。 [ 6 ]このフラグは通常、 digなどの DNS 管理クエリツールの出力に目立つように表示され、応答するネームサーバーが問題のドメイン名の権威であることを示します。 [ 6 ]
ネームサーバーが、権威データを持たないドメイン名の権威サーバーとして指定されると、「不完全な委任」または「不完全な応答」と呼ばれる種類のエラーが発生します。[ 31 ] [ 32 ]
ドメイン名解決器は、最も右側の（トップレベル）ドメインラベルから始まる一連のクエリによって、問題のドメイン名を担当するドメインネームサーバーを特定します。
ドメイン名解決器を適切に動作させるために、ネットワークホストには、ルートネームサーバーの既知のアドレスの初期キャッシュ（ヒント）が設定されます。ヒントは、管理者が信頼できる情報源からデータセットを取得することで定期的に更新されます。
リゾルバが処理を高速化するためのキャッシュレコードを持たないと仮定すると、解決プロセスはルートサーバーのいずれかへのクエリから始まります。通常の動作では、ルートサーバーは直接応答せず、より権威のあるサーバーへの参照で応答します。たとえば、「www.wikipedia.org」へのクエリは組織サーバーに参照されます。リゾルバは参照されたサーバーにクエリを実行し、権威のある応答を受け取るまでこのプロセスを繰り返します。この図は、完全修飾ドメイン名「www.wikipedia.org」で指定されたホストに対するこのプロセスを示しています。
インターネット上のすべての名前解決がルートサーバーから開始する必要がある場合、この仕組みではルートサーバーに大きなトラフィック負荷がかかります。実際には、 DNSサーバーではキャッシュを使用してルートサーバーの負荷を軽減しており、その結果、ルートネームサーバーが関与するリクエストは全体のごく一部に過ぎません。
理論上、権威ネームサーバーはインターネットの運用に十分である。しかし、権威ネームサーバーのみが稼働している場合、すべてのDNSクエリはドメインネームシステムのルートゾーンでの再帰クエリから開始する必要があり、各ユーザーシステムは再帰操作が可能なリゾルバソフトウェアを実装する必要がある。[ 33 ]
効率性を向上させ、インターネット上の DNS トラフィックを削減し、エンドユーザー アプリケーションのパフォーマンスを高めるために、ドメイン ネーム システム (DNS) は、DNS クエリの結果を該当ドメイン名レコードの設定 (有効期限) で指定された期間保存する DNS キャッシュ サーバーをサポートしています。通常、このようなキャッシュ DNS サーバーは、DNS ルートからクエリ対象ドメインの権威ネーム サーバーまで、指定された名前を解決するために必要な再帰アルゴリズムも実装しています。この機能がネーム サーバーに実装されることで、ユーザー アプリケーションは設計と運用において効率性を向上させることができます。
ネームサーバーにおけるDNSキャッシュと再帰機能の組み合わせは必須ではなく、これらの機能は特殊な目的のサーバーで個別に実装することも可能です。
インターネットサービスプロバイダ（ISP）は通常、顧客向けに再帰型およびキャッシュ型のネームサーバーを提供しています。さらに、多くの家庭用ネットワークルーターは、ローカルネットワークの効率を向上させるために、DNSキャッシュと再帰処理を実装しています。
DNSのクライアント側はDNSリゾルバと呼ばれます。リゾルバは、最終的に検索対象のリソースの完全な解決（変換）につながるクエリを開始および順序付ける役割を担います。たとえば、ドメイン名をIPアドレスに変換するなどです。DNSリゾルバは、再帰的、非再帰的、反復的など、さまざまなクエリ方法によって分類されます。解決プロセスでは、これらの方法の組み合わせを使用する場合があります。[ 24 ]
非再帰クエリでは、DNSリゾルバはDNSサーバーにクエリを実行し、そのサーバーが権威を持つレコードを提供するか、他のサーバーにクエリを実行せずに部分的な結果を提供します。キャッシュDNSリゾルバの場合、ローカルDNSキャッシュへの非再帰クエリによって結果が得られ、上位DNSサーバーからの最初の応答後、一定期間DNSリソースレコードをキャッシュすることで、上位DNSサーバーへの負荷が軽減されます。
再帰クエリでは、DNSリゾルバは単一のDNSサーバーにクエリを送信し、その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 つ以上を使用して、ドメインの権威サーバーのいずれかに問い合わせを行い、DNS クエリを完了します。
DNSサーバーへのクエリ負荷を軽減する一般的なアプローチは、名前解決の結果をローカルまたは中間リゾルバホストにキャッシュすることです。各DNSクエリ結果には、情報が破棄または更新されるまで有効な期間を示すTTL（Time to Live）が付与されます。このTTLは権威DNSサーバーの管理者によって決定され、数秒から数日、あるいは数週間まで及ぶ場合があります。[ 34 ]
この分散キャッシュアーキテクチャの結果、DNSレコードの変更はネットワーク全体にすぐには伝播せず、すべてのキャッシュがTTL後に期限切れになり、更新される必要があります。RFC 1912は、適切なTTL値を決定するための基本的なルールを示しており、一般的な値は1～5日、メールホストのアドレスやネームサーバーなど、頻繁に変更されないレコードの場合は1～2週間です。個々のレコードのTTL値は、変更を予測して短縮することができ、変更が行われるまでネットワークトラフィックが増加します。
プロトコルは最大 68 年間のキャッシュ、またはキャッシュなしをサポートしているため、一部のリゾルバは TTL 値を上書きする場合があります。ネガティブ キャッシュ、つまりレコードが存在しないという事実のキャッシュは、ゾーンの権威ネーム サーバーによって決定され、要求されたタイプのデータが存在しないことを報告する際には、権限開始(SOA) レコードを含める必要があります。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解決はWebブラウザ、電子メールクライアント、その他のインターネットアプリケーションなどのアプリケーション内で透過的に行われます。アプリケーションがドメイン名のルックアップを必要とするリクエストを行うと、これらのプログラムはローカルオペレーティングシステムのDNSリゾルバに解決リクエストを送信し、DNSリゾルバが必要な通信を処理します。
DNSリゾルバは、ほぼ例外なく、最近のルックアップ結果を格納するキャッシュ（上記参照）を保持しています。キャッシュにリクエストに対する回答が含まれている場合、リゾルバはキャッシュ内の値をリクエストを行ったプログラムに返します。キャッシュに回答が含まれていない場合、リゾルバはリクエストを1つ以上の指定されたDNSサーバーに送信します。ほとんどの家庭ユーザーの場合、マシンが接続するISPが通常このDNSサーバーを提供します。このようなユーザーは、サーバーのアドレスを手動で設定するか、DHCPで設定することを許可します。ただし、システム管理者が独自のDNSサーバーを使用するようにシステムを構成している場合、DNSリゾルバは組織が別途管理するネームサーバーを指します。いずれの場合も、このようにクエリされたネームサーバーは、結果が正常に見つかるか見つからないかにかかわらず、上記の手順に従います。その後、結果をDNSリゾルバに返します。結果が見つかった場合、リゾルバはその結果を将来の使用のために適切にキャッシュし、リクエストを開始したソフトウェアに結果を返します。
大手ISPの中には、TTLを無視したり、ネームサーバーの1つが応答しないという理由だけでドメイン名が存在しないと示したりするなど、規則に違反するようにDNSサーバーを設定しているところもある。[ 35 ]
ウェブブラウザなどの一部のアプリケーションは、ネットワーク経由での繰り返しルックアップを避けるために内部DNSキャッシュを保持しています。この方法は、このようなデータの履歴を隠蔽するため、DNSの問題をデバッグする際にさらに困難になる可能性があります。これらのキャッシュは通常、1分程度の非常に短いキャッシュ時間を使用します。[ 36 ]
Google Chromeは、DNSサーバーに問題が検出されると、特定のエラーメッセージを表示します。
ドメインネームシステムには、他にもいくつかの機能と特徴が含まれています。
ホスト名とIPアドレスは必ずしも1対1で一致する必要はありません。1つのIPアドレスに複数のホスト名が対応付けられる場合があり、これは仮想ホスティングにおいて、1つのホストから多数のWebサイトが配信される場合に便利です。あるいは、1つのホスト名が複数のIPアドレスに解決されることで、耐障害性を高め、企業全体またはグローバルインターネット上の複数のサーバーインスタンスに負荷分散を行うことができます。
DNSは、名前をIPアドレスに変換する以外にも様々な用途があります。例えば、メール転送エージェントはDNSを使用して、電子メールを配信する最適なメールサーバーを見つけます。MXレコードはドメインとメール交換機のマッピングを提供し、これにより耐障害性と負荷分散のレイヤーをさらに強化できます。
DNSは、ブロックリストに登録されたメールホストのIPアドレスを効率的に保存および配信するために使用されます。一般的な方法としては、対象ホストのIPアドレスを上位ドメイン名のサブドメインに配置し、その名前を肯定または否定を示すレコードに解決するという方法があります。
例えば：
メールサーバーは、blocklist.example に問い合わせることで、接続してくる特定のホストがブロックリストに含まれているかどうかを確認できます。このようなブロックリストは、有料のものも無料のものも含め、メール管理者やスパム対策ソフトウェア向けに多数提供されています。
コンピュータやネットワークの障害発生時に備え、各ドメインをカバーするために複数のDNSサーバーが通常用意されています。グローバルDNSの最上位レベルには、13のルートネームサーバーグループが存在し、それらの「コピー」がエニーキャストアドレス指定によって世界中に分散されています。
ダイナミックDNS （DDNS）は、例えばISP間やモバイルホットスポット間を移動する場合、あるいはIPアドレスが管理上変更された場合などに、クライアントのIPアドレスをDNSサーバーにリアルタイムで更新します。
DNSプロトコルはクエリとレスポンスという2種類のDNSメッセージを使用し、どちらも同じ形式です。各メッセージはヘッダーと4つのセクション（質問、回答、権限、および追加のスペース）で構成されます。ヘッダーフィールド（フラグ）は、これら4つのセクションの内容を制御します。[ 24 ]
ヘッダーセクションは、識別子、フラグ、質問数、回答数、権限リソースレコード（RR）数、追加RR数というフィールドで構成されます。各フィールドは16ビット長で、記載されている順序で表示されます。識別子フィールドは、クエリと応答を照合するために使用されます。フラグワードの後には、ヘッダーの最後に、後続の各セクションのレコード数を表す4つの16ビット整数が同じ順序で表示されます。
質問セクションは、他のセクションで使用されているリソースレコードの形式よりもシンプルな形式になっています。各質問レコード（通常、セクションには1つだけあります）には、次のフィールドが含まれています。
ドメイン名は個別のラベルに分割され、それらが連結されます。各ラベルには、そのラベルの長さが接頭辞として付けられます。[ 38 ]
ドメインネームシステム（DNS）は、ネットワークリソースの情報要素のデータベースを規定します。情報要素の種類は、DNSレコードタイプのリスト、すなわちリソースレコード（RR）によって分類および整理されます。各レコードには、タイプ（名前と番号）、有効期限（有効期間）、クラス、およびタイプ固有のデータがあります。同じタイプのリソースレコードは、特別な順序付けなしにリソースレコードセット（RRset）として記述されます。DNSリゾルバはクエリに対してセット全体を返しますが、サーバーは負荷分散を実現するためにラウンドロビン方式を実装する場合があります。これに対し、ドメインネームシステムセキュリティ拡張機能（DNSSEC）は、正規の順序でリソースレコードの完全なセットに対して動作します。
インターネットプロトコルネットワーク経由で送信される場合、すべてのレコード（回答、認証局、および追加セクション）はRFC 1035: [ 39 ] : §3で規定されている共通フォーマットを使用します。
NAMEは、ツリー内のノードの完全修飾ドメイン名です。ネットワーク上では、ラベル圧縮を使用して名前が短縮される場合があります。これは、パケット内で先に言及されたドメイン名の末尾を、現在のドメイン名の末尾に置き換えることによって行われます。
TYPEはレコードの種類を示します。データの形式を示し、その用途を推測する手がかりとなります。例えば、Aレコードはドメイン名をIPv4アドレスに変換するために使用され、NSレコードはDNSゾーンのルックアップに応答できるネームサーバーを一覧表示し、MXレコードは電子メールアドレスで指定されたドメインのメールを処理するメールサーバーを指定します。
インターネットホスト名、サーバー、または IP アドレスを含む一般的な DNS レコードの場合、レコードのCLASS はIN (インターネット用) に設定されます。さらに、Chaos (CH) およびHesiod (HS) クラスも存在します。[ 39 ] : 11各クラスは、DNS ゾーンの委任が異なる可能性のある独立した名前空間です。
RDATAは、アドレスレコードのIPアドレスやMXレコードの優先度とホスト名など、タイプ固有の関連性を持つデータです。よく知られているレコードタイプはRDATAフィールドでラベル圧縮を使用できますが、「不明」のレコードタイプは使用してはなりません（RFC 3597）。
ドメインネームシステムは、ゾーンファイルで定義されたリソースレコードに加えて、ゾーン転送（AXFR/IXFR）やEDNS （OPT）など、他のDNSノードとの通信（ネットワーク上）でのみ使用されるいくつかのリクエストタイプも定義しています。
ドメイン ネーム システムでは、アスタリスク ラベルで始まる名前を指定するワイルド カード DNS レコードがサポートされています。例:。[ 24 ] [ 40 ]ワイルドカードドメイン名に属する DNS レコードは、クエリ名の一致するコンポーネント (指定された子孫を含む) でラベル全体を置き換えることにより、単一の DNS ゾーン内でリソース レコードを生成するルールを指定します。たとえば、次の構成では、DNS ゾーンx.exampleは、 x.exampleのすべてのサブドメイン (サブドメインのサブドメインを含む) がメール エクスチェンジャー (MX) axexampleを使用することを指定します。axexample の AAAA レコードは、メールエクスチェンジャーの IP アドレスを指定するために必要です。この結果、このドメイン名とそのサブドメインがワイルド カード マッチから除外されるため、サブドメイン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の元の定義は不完全で、実装者による誤解を招いていたためです。[ 40 ]
当初のDNSプロトコルには、新機能を追加するための拡張機能が限られていました。1999年、ポール・ヴィクシーはRFC 2671（後にRFC 6891に置き換えられた）において、DNS拡張メカニズム（EDNS）と呼ばれる拡張メカニズムを発表しました。これは、使用されていないときにオーバーヘッドを増やすことなく、オプションのプロトコル要素を導入するものでした。これは、プロトコルのワイヤ送信にのみ存在し、ゾーンファイルには存在しないOPT擬似リソースレコードによって実現されました。また、UDPデータグラムにおけるDNSメッセージサイズの増加など、初期の拡張（EDNS0）も提案されました。
動的 DNS 更新では、UPDATE DNS オペコードを使用して、権威 DNS サーバーで管理されているゾーン データベースからリソース レコードを動的に追加または削除します。[ 41 ]この機能は、ネットワーク クライアントが起動したり、ネットワーク上で利用可能になったときに、DNS に登録するのに役立ちます。起動中のクライアントには、 DHCPサーバーから毎回異なる IP アドレスが割り当てられる可能性があるため、そのようなクライアントに静的 DNS 割り当てを提供することはできません。
DNSは1983年の誕生以来、 IP上でのデータ転送にユーザーデータグラムプロトコル（UDP）を使用してきた。しかし、その限界が、その後数十年にわたり、信頼性、セキュリティ、プライバシーなどの基準を満たすための数多くのプロトコル開発を促してきた。
UDP は、クエリをリッスンするサーバー用にポート番号 53 を予約しています。[ 6 ]このようなクエリは、クライアントから単一の UDP パケットで送信される平文の要求と、サーバーから単一の UDP パケットで送信される平文の応答で構成されます。応答の長さが 512 バイトを超え、クライアントとサーバーの両方がDNS の拡張メカニズム(EDNS) をサポートしている場合、より大きな UDP パケットが使用されることがあります。[ 42 ] UDP 上での DNS の使用は、とりわけ、トランスポート層の暗号化、認証、信頼性の高い配信、およびメッセージ長の欠如によって制限されます。1989 年に、RFC 1123 は、DNS クエリ、応答、特にゾーン転送のためのオプションの伝送制御プロトコル(TCP) トランスポートを規定しました。TCP は、長い応答の断片化により、より長い応答、信頼性の高い配信、およびクライアントとサーバー間の長期間にわたる接続の再利用を可能にします。より大きな応答の場合、サーバーはクライアントを TCP トランスポートに誘導します。
DNS over TLSは、2016年にIETFの暗号化DNS標準として登場し、DNSペイロードだけでなく接続全体を保護するためにトランスポート層セキュリティ（TLS）を利用します。DoTサーバーはTCPポート853で待機します。RFC 7858では、機会的暗号化と認証付き暗号化がサポートされる可能性があると規定されていますが、サーバー認証またはクライアント認証のいずれも必須とはしていません。
DNS over HTTPSは、DNSクエリ転送の競合標準として2018年に開発され、HTTPをTLSで転送するHTTPS上でDNSクエリデータをトンネル化します。DoHは、DNSCryptと同様にTCPポート443を使用するため、Webトラフィックに似ており、よりWebフレンドリーなDNSの代替手段として宣伝されましたが、適切なパディングなしでは実際には容易に区別できます。[ 43 ]
インターネット技術タスクフォースが2022年に公開したRFC 9250では、QUIC上のDNSについて説明されています。これは「TLS上のDNS（DoT）と同様のプライバシー特性を持ち、UDP上の従来のDNSと同様の遅延特性を持つ」ものです。この方法はHTTP/3上のDNSとは異なります。[ 44 ]
インターネット技術タスクフォースが2026年に公開したRFC 9953では、DNS over CoAPについて説明されています。「DoCのアプリケーションユースケースは、DNS over HTTPS（DoH）（RFC 8484）に触発されています。しかし、DoCは制約のあるモノのインターネット（IoT）での展開を目指しており、これは通常HTTPSによって導入された要件と矛盾します。」[ 45 ] DoCは、制約のあるシナリオで他のDNS解決メカニズムよりも優れたパフォーマンスを発揮します。[ 46 ]
Oblivious DNS (ODNS) は、 DoH が標準化され広く普及する前に、プリンストン大学とシカゴ大学の研究者によって暗号化されていない DNS の拡張として発明され実装されました。 [ 47 ]その後、Apple と Cloudflare は、 Oblivious DoH (ODoH)として、DoH のコンテキストでこの技術を実装しました。[ 48 ] ODoH は、(ODNS で発明された) イングレス/エグレス分離と、DoH の HTTPS トンネリングおよび TLS トランスポート層暗号化を単一のプロトコルに組み合わせたものです。[ 49 ]
DNSは仮想プライベートネットワーク（VPN）やトンネリングプロトコル上で実行できます。オブリビアスDNSのプライバシー向上は、既存のTorネットワークのイングレスノードとエグレスノードをTLSによるトランスポート層暗号化と組み合わせることで実現できます。[ 50 ]
IETF標準フレームワーク外で 2011 年に開発されたDNSCryptプロトコルは、再帰リゾルバのダウンストリーム側で DNS 暗号化を導入しました。これにより、クライアントは、DNS に公開されているサーバーの公開鍵を使用してクエリ ペイロードを暗号化します (サードパーティの認証局に依存するのではなく)。この公開鍵は、 DNSSEC署名によって保護される場合もあります。[ 51 ] DNSCrypt は、 HTTPS暗号化ウェブ トラフィックと同じ TCP ポート 443、または UDP ポート 443 のいずれかを使用します。これにより、クエリの内容に関するプライバシーだけでなく、ファイアウォールを通過できる能力が大幅に向上しました。2019 年に、DNSCrypt はさらに拡張され、提案されている「Oblivious DNS」と同様の「匿名化」モードをサポートするようになりました。このモードでは、イングレス ノードが別のサーバーの公開鍵で暗号化されたクエリを受信し、それをそのサーバーに中継します。そのサーバーはエグレス ノードとして機能し、再帰解決を実行します。[ 52 ]イングレスノードはクエリの内容を知らず、エグレスノードはクライアントのIDを知らないため、ユーザー/クエリペアのプライバシーが確保されます。 DNSCryptは、 2011年12月にOpenDNSによって初めて実運用で実装されました。ODoHを統合した無料のオープンソースソフトウェア実装もいくつかあります。[ 53 ] Unix、Apple iOS、Linux、Android、Windowsなど、さまざまなオペレーティングシステムで利用可能です。
当初、セキュリティ上の懸念は、DNSソフトウェアや初期のインターネット上で展開されるソフトウェアの設計において主要な考慮事項ではありませんでした。なぜなら、ネットワークは一般の人々の参加に開放されていなかったからです。しかし、1990年代にインターネットが商用分野に拡大すると、データの完全性とユーザー認証を保護するためのセキュリティ対策に対する要求が変化しました。
悪意のあるユーザーによって、いくつかの脆弱性が発見され、悪用されました。その一つがDNSキャッシュポイズニングです。これは、権威あるオリジンサーバーを装ってキャッシュリゾルバにデータを配信し、データストアを誤った情報や長い有効期限（TTL）で汚染するものです。その結果、正当なアプリケーション要求が、悪意を持って運用されているネットワークホストにリダイレクトされる可能性があります。
DNS 応答には従来、暗号署名が付いておらず、多くの攻撃の可能性が生じていました。ドメイン ネーム システム セキュリティ拡張機能(DNSSEC) は、DNS を変更して暗号署名付き応答のサポートを追加します。[ 54 ] DNSCurve はDNSSEC の代替として提案されています。TSIG などの他の拡張機能は、信頼できるピア間の暗号認証のサポートを追加し、ゾーン転送や動的更新操作の認証によく使用されます。
フォワード確認型リバースDNSなどの技術も、DNS結果の検証に役立てることができます。
DNSは、設定に注意を払わないと、本来は安全またはプライベートな接続から「漏洩」する可能性があり、また、DNSは無害なものと見なされることが多いため、悪意のある人物がファイアウォールを回避してデータを抜き取るために悪用されることもあります。
ドメイン名によっては、なりすまし効果を狙って悪用されることがあります。例えば、paypal.comとpaypa1.com は異なる名前ですが、ユーザーが選択したフォントによっては、グラフィカルユーザーインターフェース上で区別できない場合があります。多くのフォントでは、文字lと数字の1が非常に似ているか、あるいは同一に見えることがあります。この問題はIDN ホモグラフ攻撃として知られており、 ISO 10646の多くの文字コードが一般的なコンピュータ画面上で同一に見える可能性があるため、国際化ドメイン名をサポートするシステムでは深刻です。この脆弱性は、フィッシングで悪用されることがあります。[ 55 ]
DNSMessenger [ 56 ] [ 57 ] [ 58 ] [ 59 ]は、DNS を使用してマルウェアをリモートで通信および制御するサイバー攻撃手法の一種で、警戒信号となる可能性のある従来のプロトコルに依存しません。DNSMessenger 攻撃は、DNS が主にドメイン名解決に使用され、ネットワーク セキュリティ ツールによって厳密に監視されていないことが多いため、攻撃者が悪用する効果的なチャネルとなり、隠蔽されています。
この手法では、DNS TXTレコードを使用して感染システムにコマンドを送信します。マルウェアが被害者のマシンに密かにインストールされると、制御されたドメインにアクセスして、DNSテキストレコードにエンコードされたコマンドを取得します。この種のマルウェア通信は、DNSリクエストが通常ファイアウォールを通過することが許可され、DNSトラフィックがしばしば無害とみなされるため、多くのネットワークセキュリティ対策を回避できることから、非常に巧妙です。
DNSメッセンジャー攻撃は、データ漏洩から追加ペイロードの配信まで、多岐にわたる悪意のある活動を可能にする一方で、従来のネットワークセキュリティ対策の監視をかいくぐります。このような攻撃手法を理解し、防御することは、強固なサイバーセキュリティを維持するために不可欠です。
DNSプロトコルは、もともとパブリックで階層的、分散型でキャッシュを多用するデータベースとして設計されているため、機密性制御がありません。ユーザーのクエリとネームサーバーの応答は暗号化されずに送信されるため、ネットワークパケットスニッフィング、DNSハイジャック、DNSキャッシュポイズニング、中間者攻撃が可能になります。この欠陥は、サイバー犯罪者やネットワークオペレーターによって、マーケティング目的、キャプティブポータルでのユーザー認証、検閲などによく利用されています。[ 60 ]
コンテンツ配信ネットワークの利益のために、DNSクエリにおけるクライアントIP情報のレベルを上げる提案（RFC 7871）により、ユーザーのプライバシーはさらに危険にさらされています。
DNSにおけるプライバシー問題に対処するために用いられている主なアプローチは以下のとおりです。
ローカルネットワークオペレーターによるDNS検査を阻止するソリューションは、企業のネットワークセキュリティポリシーやインターネット検閲を妨害するとして批判されてきた。パブリックDNSサーバーは、パブリックリゾルバを運用できる少数の大企業にDNS解決の制御を委ねることで、インターネットの中央集権化に寄与しているとして批判されている。[ 60 ]
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に対して最もよく使用されます。登録者とは、ドメイン登録を要求した個人または組織のことです。[ 25 ] レジストリは、対応するゾーンで名前を割り当てる権限（認定）を持つ各ドメイン名レジストラから登録情報を受け取り、 WHOISプロトコルを使用して情報を公開します。2015年現在、RDAPの使用が検討されています。[ 61 ]
ICANNは、TLD、TLDレジストリ、ドメイン名レジストラの完全なリストを公開しています。ドメイン名に関連付けられた登録者情報は、WHOISサービスでアクセスできるオンラインデータベースで管理されています。290を超える国別コードトップレベルドメイン（ccTLD）のほとんどについては、ドメインレジストリがWHOIS（登録者、ネームサーバー、有効期限など）情報を保持しています。たとえば、ドイツのNICであるDENICは、DEドメインのデータを保持しています。2001年頃から、ほとんどの汎用トップレベルドメイン（gTLD）レジストリは、レジストラデータベースではなく中央レジストリにWHOISデータを保持する、いわゆるシックレジストリ方式を採用しています。
COMおよびNETのトップレベルドメインでは、軽量レジストリモデルが採用されています。ドメインレジストリ（GoDaddy、BigRock、PDR、VeriSignなど）は、基本的なWHOISデータ（レジストラやネームサーバーなど）を保持しています。一方、組織、つまりORGドメインを使用する登録者は、パブリック・インタレスト・レジストリにのみ登録されます。
ネットワーク情報センター(NIC)と呼ばれるドメイン名レジストリの中には、WHOIS データセットへのアクセスを提供するだけでなく、エンドユーザーに対してレジストラとしても機能するものがあります。COM、NET、ORG などのトップレベルドメインレジストリは、多数のドメイン名レジストラで構成されるレジストリ・レジストラモデルを使用しています。[ 62 ]この管理方法では、レジストリはドメイン名データベースとレジストラとの関係のみを管理します。登録者(ドメイン名のユーザー) はレジストラの顧客であり、場合によっては再販業者への追加の下請けを通じて顧客となります。
{{cite web}}: CS1 maint: 複数の名前: 著者リスト (リンク)トラフィックが暗号化されたWebトラフィックと区別できるかどうかを調査します。この目的のために、HTTPSトラフィックをWebまたはDoHに分類する機械学習モデルをトレーニングします。DoH識別モデルを導入すると、権威主義的なISPがDoHパケットの約97.4%を正しく識別し、Webパケットの誤分類は10,000個に1個のみであることを示します。
DNS over HTTPS (DoH) は多くのリスクを回避しますが、すべてではありません。また、そのトランスポート プロトコル (つまり HTTPS) は、(たとえば「クッキー」) によりプライバシーに関する懸念を引き起こします。Tor ネットワークは、TCP 回路に追跡、監視、およびブロックからの自由をある程度提供するために存在します。したがって、Tor、DoH、およびリクエスト フィンガープリンティングを軽減するための「Don't Do That, Then」(DDTT) の原則と組み合わせることで、DNS over HTTPS over Tor (DoHoT) について説明します。
これらのRFCは助言的な性質のものですが、標準やBCPを定義していないにもかかわらず、有用な情報を提供する可能性があります。[ 1 ]
これらのRFCは公式には「不明」というステータスですが、その古さから明確にそのようにラベル付けされていません。