ドメインネームシステム

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

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

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

DNS データベースに保存される最も一般的なレコードの種類は、権限の開始 ( SOA )、IP アドレス ( AおよびAAAA )、SMTP メール エクスチェンジャ(MX)、ネーム サーバー (NS)、逆 DNS ルックアップのポインター(PTR)、およびドメイン名エイリアス(CNAME) です。DNS は汎用データベースとして意図されたものではありません。しかし、時間の経過とともに拡張され、DNSSECレコードなどの自動ルックアップ用、または責任者(RP) レコードなどの人間によるクエリ用の他の種類のデータのレコードを保存できるようになりました。汎用データベースとして、DNS はリアルタイム ブラックホール リスト(RBL) を保存することで迷惑メール(スパム)対策にも使用されています。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で更新されました。

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

1987年11月、RFC 1034 ^[22]とRFC 1035 ^[5]が1983年のDNS仕様に取って代わりました。さらにいくつかのRequest for CommentsでコアDNSプロトコルの拡張が提案されました。^[23]

ドメイン名空間はツリーデータ構造で構成されています。ツリー内の各ノードまたはリーフにはラベルと、ドメイン名に関連付けられた情報を保持する0個以上のリソースレコード（RR）があります。ドメイン名自体は、ラベルと、右側の親ノードの名前をドットで区切って連結したもので構成されています。^[24]

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

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

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

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

ドメインの階層は右から左へと下がっています。左側の各ラベルは、右側のドメインのサブドメインまたはサブドメインを指定します。たとえば、ラベルexampleはcomドメインのサブドメインを指定し、wwwは example.com のサブドメインです。このサブディビジョンのツリーは最大 127 レベルまで持つことができます。^[26]

ラベルには0から63文字まで含めることができます。長さ0のヌルラベルはルートゾーン用に予約されています。完全なドメイン名は、テキスト表現で253文字を超えることはできません。^[22] DNSの内部バイナリ表現では、最大長には255オクテットのストレージが必要です。これは、名前の長さも格納するためです。^[5]

ドメイン名のラベルにオクテットで表現できる文字を使用することを禁止する技術的な制限はありませんが、ホスト名では推奨される形式と文字セットが使用されます。ラベルに使用できる文字は、 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 システムを採用しています。

ドメイン ネーム システムは、クライアント サーバー モデルを使用する分散データベースシステムによって管理されています。このデータベースのノードはネーム サーバーです。各ドメインには、そのドメインとその下位のドメインのネーム サーバーに関する情報を公開する、少なくとも 1 つの権威 DNS サーバーがあります。階層の最上位は、 TLD を検索 (解決)するときに照会するサーバーであるルート ネーム サーバーによって処理されます。

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

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

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

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

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

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

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

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

このメカニズムは、インターネット上のすべての解決がルートから開始する必要がある場合、ルート サーバーに大きなトラフィック負荷をかけることになります。実際には、DNS サーバーではキャッシュがルート サーバーの負荷を軽減するために使用されるため、ルート ネーム サーバーが関与するのは実際にはすべての要求の比較的小さな部分だけです。

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

効率性を高め、インターネット上の DNS トラフィックを減らし、エンドユーザー アプリケーションのパフォーマンスを向上させるために、ドメイン ネーム システムは、DNS キャッシュ サーバーをサポートしています。DNS キャッシュ サーバーは、問題のドメイン名レコードの構成 (存続時間) で決定された期間、DNS クエリの結果を保存します。通常、このようなキャッシュ DNS サーバーは、DNS ルートから始まって、クエリされたドメインの権威ネーム サーバーに至るまで、特定の名前を解決するために必要な再帰アルゴリズムも実装しています。ネーム サーバーにこの機能が実装されているため、ユーザー アプリケーションは設計と操作の効率が向上します。

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

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

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

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

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

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

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

この場合、委任を提供するネーム サーバーは、委任に記載されている権限のあるネーム サーバーの 1 つ以上の IP アドレスも提供する必要があります。この情報はグルーと呼ばれます。委任するネーム サーバーは、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サーバーの管理者によって決定され、数秒から数日、さらには数週間に及ぶことがあります。^[33]

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

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

逆DNS ルックアップは、IP アドレスがわかっている場合に、ドメイン名を DNS に問い合わせることです。1 つの IP アドレスに複数のドメイン名を関連付けることができます。DNS は、インフラストラクチャ トップレベル ドメイン arpa 内のポインタ (PTR) レコードに、ドメイン名の形式で IP アドレスを特別な形式の名前として保存します。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 サーバに送信します。ほとんどのホーム ユーザーの場合、マシンが接続するインターネット サービス プロバイダが通常この DNS サーバを提供します。そのようなユーザーは、そのサーバのアドレスを手動で構成するか、DHCPにその設定を許可します。ただし、システム管理者が独自の DNS サーバを使用するようにシステムを構成している場合、DNS リゾルバは組織で個別に管理されているネーム サーバを指します。いずれにしても、このようにクエリされたネーム サーバは、結果が見つかるか見つからないかのどちらかになるまで、上記のプロセスに従います。その後、その結果を DNS リゾルバに返します。結果が見つかったと仮定すると、リゾルバはその結果を将来使用するために適切にキャッシュし、要求を開始したソフトウェアに結果を返します。

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

ウェブブラウザなどの一部のアプリケーションは、ネットワーク経由での繰り返し検索を避けるために内部DNSキャッシュを維持しています。この方法では、このようなデータの履歴が不明瞭になるため、DNSの問題のデバッグがさらに困難になる可能性があります。これらのキャッシュは通常、1分程度の非常に短いキャッシュ時間を使用します。^[35]

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

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

ドメイン ネーム システムには、他にもさまざまな機能と特徴が含まれています。

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

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

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

例えば：

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

電子メール サーバーは、blacklist.example を照会して、接続している特定のホストがブラックリストに含まれているかどうかを確認できます。このようなブラックリストの多くは、サブスクリプションベースまたは無料で、電子メール管理者やスパム対策ソフトウェアで使用できます。

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

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

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

ヘッダー セクションは、次のフィールドで構成されます:識別、フラグ、質問の数、回答の数、権限リソース レコード(RR) の数、および追加 RR の数。各フィールドは 16 ビットの長さで、指定された順序で表示されます。識別フィールドは、応答とクエリを一致させるために使用されます。フラグ フィールドは、次のサブフィールドで構成されます。

フラグ ワードの後に​​、ヘッダーは 4 つの 16 ビット整数で終わります。これには、後続の各セクションのレコード数が、同じ順序で含まれています。

質問セクションの形式は、他のセクションで使用されるリソース レコード形式よりも単純です。各質問レコード (通常、セクションには 1 つだけあります) には、次のフィールドが含まれます。

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

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

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

NAME は、ツリー内のノードの完全修飾ドメイン名です。^{[説明が必要]}回線上では、ラベル圧縮を使用して名前が短縮されることがあります。この場合、パケット内で先に記述されたドメイン名の末尾が、現在のドメイン名の末尾に置き換えられます。

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

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

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

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

ドメイン名システムは、アスタリスクラベルで始まる名前を指定するワイルドカード DNS レコードをサポートしています(例: ) 。^{[22] [41]}ワイルドカードドメイン名に属する DNS レコードは、指定された子孫を含むクエリ名の一致するコンポーネントでラベル全体を置き換えることによって、単一の DNS ゾーン内でリソース レコードを生成するためのルールを指定します。 たとえば、次の構成では、DNS ゾーンx.exampleは、サブドメインのサブドメインを含むx.exampleのすべてのサブドメインがメール エクスチェンジャ (MX) axexample を使用することを指定します。 axexampleの A レコードは、メール エクスチェンジャの 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 の元の定義 が不完全で、実装者による誤解を招いたためです。^[41]

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

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

DNS は 1983 年に誕生して以来、 IP 経由の転送にユーザー データグラム プロトコル(UDP) を使用してきました。その制限により、その後数十年間にわたり、信頼性、セキュリティ、プライバシー、その他の基準を満たす多数のプロトコルが開発されました。

UDP reserves port number 53 for servers listening to queries.^[5] Such queries consist of a clear-text request sent in a single UDP packet from the client, responded to with a clear-text reply sent in a single UDP packet from the server. When the length of the answer exceeds 512 bytes and both client and server support Extension Mechanisms for DNS (EDNS), larger UDP packets may be used.^[43] Use of DNS over UDP is limited by, among other things, its lack of transport-layer encryption, authentication, reliable delivery, and message length. In 1989, RFC 1123 specified optional Transmission Control Protocol (TCP) transport for DNS queries, replies and, particularly, zone transfers. Via fragmentation of long replies, TCP allows longer responses, reliable delivery, and re-use of long-lived connections between clients and servers. For larger responses, the server refers the client to TCP transport.

DNS over TLS emerged as an IETF standard for encrypted DNS in 2016, utilizing Transport Layer Security (TLS) to protect the entire connection, rather than just the DNS payload. DoT servers listen on TCP port 853. RFC 7858 specifies that opportunistic encryption and authenticated encryption may be supported, but did not make either server or client authentication mandatory.

DNS over HTTPS was developed as a competing standard for DNS query transport in 2018, tunneling DNS query data over HTTPS, which transports HTTP over TLS. DoH was promoted as a more web-friendly alternative to DNS since, like DNSCrypt, it uses TCP port 443, and thus looks similar to web traffic, though they are easily differentiable in practice without proper padding.^[44]

RFC 9250, published in 2022 by the Internet Engineering Task Force, describes DNS over QUIC. It has "privacy properties similar to DNS over TLS (DoT) [...], and latency characteristics similar to classic DNS over UDP". This method is not the same as DNS over HTTP/3.^[45]

Oblivious DNS (ODNS) was invented and implemented by researchers at Princeton University and the University of Chicago as an extension to unencrypted DNS,^[46] before DoH was standardized and widely deployed. Apple and Cloudflare subsequently deployed the technology in the context of DoH, as Oblivious DoH (ODoH).^[47] ODoH combines ingress/egress separation (invented in ODNS) with DoH's HTTPS tunneling and TLS transport-layer encryption in a single protocol.^[48]

DNS may be run over virtual private networks (VPNs) and tunneling protocols. A use which has become common since 2019 to warrant its own frequently used acronym is DNS over Tor. The privacy gains of Oblivious DNS can be garnered through the use of the preexisting Tor network of ingress and egress nodes, paired with the transport-layer encryption provided by TLS.^[49]

The DNSCrypt protocol, which was developed in 2011 outside the IETF standards framework, introduced DNS encryption on the downstream side of recursive resolvers, wherein clients encrypt query payloads using servers' public keys, which are published in the DNS (rather than relying upon third-party certificate authorities) and which may in turn be protected by DNSSEC signatures.^[50] DNSCrypt uses either TCP or UDP port 443, the same port as HTTPS encrypted web traffic. This introduced not only privacy regarding the content of the query, but also a significant measure of firewall-traversal capability. In 2019, DNSCrypt was further extended to support an "anonymized" mode, similar to the proposed "Oblivious DNS", in which an ingress node receives a query which has been encrypted with the public key of a different server, and relays it to that server, which acts as an egress node, performing the recursive resolution.^[51] Privacy of user/query pairs is created, since the ingress node does not know the content of the query, while the egress nodes does not know the identity of the client. DNSCrypt was first implemented in production by OpenDNS in December 2011. There are several free and open source software implementations that additionally integrate ODoH.^[52] It is available for a variety of operating systems, including Unix, Apple iOS, Linux, Android, and Windows.

Originally, security concerns were not major design considerations for DNS software or any software for deployment on the early Internet, as the network was not open for participation by the general public. However, the expansion of the Internet into the commercial sector in the 1990s changed the requirements for security measures to protect data integrity and user authentication.

Several vulnerability issues were discovered and exploited by malicious users. One such issue is DNS cache poisoning, in which data is distributed to caching resolvers under the pretense of being an authoritative origin server, thereby polluting the data store with potentially false information and long expiration times (time-to-live). Subsequently, legitimate application requests may be redirected to network hosts operated with malicious intent.

DNS responses traditionally do not have a cryptographic signature, leading to many attack possibilities; the Domain Name System Security Extensions (DNSSEC) modify DNS to add support for cryptographically signed responses.^[53] DNSCurve has been proposed as an alternative to DNSSEC. Other extensions, such as TSIG, add support for cryptographic authentication between trusted peers and are commonly used to authorize zone transfer or dynamic update operations.

Some domain names may be used to achieve spoofing effects. For example, paypal.com and paypa1.com are different names, yet users may be unable to distinguish them in a graphical user interface depending on the user's chosen typeface. In many fonts the letter l and the numeral 1 look very similar or even identical. This problem, known as the IDN homograph attack, is acute in systems that support internationalized domain names, as many character codes in ISO 10646 may appear identical on typical computer screens. This vulnerability is occasionally exploited in phishing.^[54]

Techniques such as forward-confirmed reverse DNS can also be used to help validate DNS results.

DNS can also "leak" from otherwise secure or private connections, if attention is not paid to their configuration, and at times DNS has been used to bypass firewalls by malicious persons, and exfiltrate data, since it is often seen as innocuous.

Originally designed as a public, hierarchical, distributed and heavily cached database, DNS protocol has no confidentiality controls. User queries and nameserver responses are being sent unencrypted which enables network packet sniffing, DNS hijacking, DNS cache poisoning and man-in-the-middle attacks. This deficiency is commonly used by cybercriminals and network operators for marketing purposes, user authentication on captive portals and censorship.^[55]

User privacy is further exposed by proposals for increasing the level of client IP information in DNS queries (RFC 7871) for the benefit of Content Delivery Networks.

The main approaches that are in use to counter privacy issues with DNS:

• VPNs, which move DNS resolution to the VPN operator and hide user traffic from local ISP,
• Tor, which replaces traditional DNS resolution with anonymous .onion domains, hiding both name resolution and user traffic behind onion routing counter-surveillance,
• Proxies and public DNS servers, which move the actual DNS resolution to a third-party provider, who usually promises little or no request logging and optional added features, such as DNS-level advertisement or pornography blocking.
  • Public DNS servers can be queried using traditional DNS protocol, in which case they provide no protection from local surveillance, or DNS over HTTPS, DNS over TLS and DNSCrypt, which do provide such protection

Solutions preventing DNS inspection by local network operator are criticized for thwarting corporate network security policies and Internet censorship. They are also criticized from a privacy point of view, as giving away the DNS resolution to the hands of a small number of companies known for monetizing user traffic and for centralizing DNS name resolution, which is generally perceived as harmful for the Internet.^[55]

Google is the dominant provider of the platform in Android, the browser in Chrome, and the DNS resolver in the 8.8.8.8 service. Would this scenario be a case of a single corporate entity being in a position of overarching control of the entire namespace of the Internet? Netflix already fielded an app that used its own DNS resolution mechanism independent of the platform upon which the app was running. What if the Facebook app included DoH? What if Apple's iOS used a DoH-resolution mechanism to bypass local DNS resolution and steer all DNS queries from Apple's platforms to a set of Apple-operated name resolvers?

— DNS Privacy and the IETF

The right to use a domain name is delegated by domain name registrars which are accredited by the Internet Corporation for Assigned Names and Numbers (ICANN) or other organizations such as OpenNIC, that are charged with overseeing the name and number systems of the Internet. In addition to ICANN, each top-level domain (TLD) is maintained and serviced technically by an administrative organization, operating a registry. A registry is responsible for operating the database of names within its authoritative zone, although the term is most often used for TLDs. A registrant is a person or organization who asked for domain registration.^[23] The registry receives registration information from each domain name registrar, which is authorized (accredited) to assign names in the corresponding zone and publishes the information using the WHOIS protocol. As of 2015, usage of RDAP is being considered.^[56]

ICANN publishes the complete list of TLDs, TLD registries, and domain name registrars. Registrant information associated with domain names is maintained in an online database accessible with the WHOIS service. For most of the more than 290 country code top-level domains (ccTLDs), the domain registries maintain the WHOIS (Registrant, name servers, expiration dates, etc.) information. For instance, DENIC, Germany NIC, holds the DE domain data. From about 2001, most Generic top-level domain (gTLD) registries have adopted this so-called thick registry approach, i.e. keeping the WHOIS data in central registries instead of registrar databases.

For top-level domains on COM and NET, a thin registry model is used. The domain registry (e.g., GoDaddy, BigRock and PDR, VeriSign, etc., etc.) holds basic WHOIS data (i.e., registrar and name servers, etc.). Organizations, or registrants using ORG on the other hand, are on the Public Interest Registry exclusively.

Some domain name registries, often called network information centers (NIC), also function as registrars to end-users, in addition to providing access to the WHOIS datasets. The top-level domain registries, such as for the domains COM, NET, and ORG use a registry-registrar model consisting of many domain name registrars.^[57] In this method of management, the registry only manages the domain name database and the relationship with the registrars. The registrants (users of a domain name) are customers of the registrar, in some cases through additional subcontracting of resellers.

• Evans, Claire L. (2018). Broad Band: The Untold Story of the Women Who Made the Internet. New York: Portfolio/Penguin. ISBN 9780735211759.

• RFC 1034, Domain Names - Concepts and Facilities
• RFC 1035, Domain Names - Implementation and Specification
• RFC 1123, Requirements for Internet Hosts—Application and Support
• RFC 1995, Incremental Zone Transfer in DNS
• RFC 1996, A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
• RFC 2136, Dynamic Updates in the domain name system (DNS UPDATE)
• RFC 2181, Clarifications to the DNS Specification
• RFC 2308, Negative Caching of DNS Queries (DNS NCACHE)
• RFC 3225, Indicating Resolver Support of DNSSEC
• RFC 3226, DNSSEC and IPv6 A6 aware server/resolver message size requirements
• RFC 3596, DNS Extensions to Support IP Version 6
• RFC 3597, Handling of Unknown DNS Resource Record (RR) Types
• RFC 4343, Domain Name System (DNS) Case Insensitivity Clarification
• RFC 4592, The Role of Wildcards in the Domain Name System
• RFC 4635, HMAC SHA TSIG Algorithm Identifiers
• RFC 5001, DNS Name Server Identifier (NSID) Option
• RFC 5011, Automated Updates of DNS Security (DNSSEC) Trust Anchors
• RFC 5452, Measures for Making DNS More Resilient against Forged Answers
• RFC 5890, Internationalized Domain Names for Applications (IDNA):Definitions and Document Framework
• RFC 5891, Internationalized Domain Names in Applications (IDNA): Protocol
• RFC 5892, The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)
• RFC 5893, Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)
• RFC 6672, Non-Terminal DNS Name Redirection
• RFC 6891, Extension Mechanisms for DNS (EDNS0)
• RFC 7766, DNS Transport over TCP - Implementation Requirements
• RFC 8945, Secret Key Transaction Authentication for DNS (TSIG)

• RFC 4033, DNS Security Introduction and Requirements
• RFC 4034, Resource Records for the DNS Security Extensions
• RFC 4035, Protocol Modifications for the DNS Security Extensions
• RFC 4509, Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records
• RFC 4470, Minimally Covering NSEC Records and DNSSEC On-line Signing
• RFC 5155, DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
• RFC 5702, Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC
• RFC 5910, Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)
• RFC 5933, Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC
• RFC 7830, The EDNS(0) Padding Option
• RFC 7858, Specification for DNS over Transport Layer Security (TLS)
• RFC 8310, Usage Profiles for DNS over TLS and DNS over DTLS
• RFC 8484, DNS Queries over HTTPS (DoH)

• RFC 1183, New DNS RR Definitions

• RFC 2182, Selection and Operation of Secondary DNS Servers (BCP 16)
• RFC 2317, Classless IN-ADDR.ARPA delegation (BCP 20)
• RFC 5625, DNS Proxy Implementation Guidelines (BCP 152)
• RFC 6895, Domain Name System (DNS) IANA Considerations (BCP 42)
• RFC 7720, DNS Root Name Service Protocol and Deployment Requirements (BCP 40)

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

• RFC 1178、コンピュータの名前の選択(FYI 5)
• RFC 1591、ドメインネームシステムの構造と委任
• RFC 1912、一般的な DNS 操作および構成エラー
• RFC 2100、ホストの命名
• RFC 3696、名前のチェックと変換のアプリケーション技術
• RFC 3833.ドメインネームシステム (DNS) の脅威分析
• RFC 4892、ネームサーバインスタンスを識別するメカニズムの要件
• RFC 5894、アプリケーション用国際化ドメイン名 (IDNA):背景、説明、および根拠
• RFC 5895、アプリケーションにおける国際化ドメイン名の文字マッピング (IDNA) 2008
• RFC 8806、リゾルバのローカルルートサーバの実行
• RFC 9076、DNS プライバシーに関する考慮事項
• RFC 9156、プライバシー向上のための DNS クエリ名の最小化
• RFC 9499、DNS 用語

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

• RFC 920、ドメイン要件– 指定された元のトップレベルドメイン
• RFC 1032、ドメイン管理者ガイド
• RFC 1033、ドメイン管理者操作ガイド
• RFC 1101、ネットワーク名およびその他のタイプの DNS エンコーディング

Wikiversityにはドメインネームシステムに関する学習リソースがあります

• Vixie, Paul (2007年5月4日). 「DNS Complexity」. ACM Queue . 2023年3月29日時点のオリジナルよりアーカイブ。
• ボール、ジェームズ (2014 年 2 月 28 日)。「世界中のインターネット セキュリティの鍵を握る 7 人の人物に会う」。ガーディアン。ガーディアン ニュース & メディア リミテッド。2014年2 月 28 日閲覧。
• Kruger, Lennard G. (2016 年 11 月 18 日)。「インターネット ガバナンスとドメイン ネーム システム: 議会が取り組むべき課題」(PDF)。議会調査局。2024年7 月 27 日に閲覧。
• Zytrax.com、オープンソース ガイド – ロケット科学者向け DNS。
• Mess with DNS – DNS の実験ができるサイト。