DNSはドメイン名システムの略です。 DNSは、TCP/IPネットワークの名前解像度に使用されます。 DNSが何であり、どこから来たのかを理解する前に、最初にDNSが開発される前に名前の解像度がどのように発生したかを理解する必要があります。
インターネットが開始されたばかりで、数百コンピューターしか接続されていない場合、名前の解決は非常にシンプルでメンテナンスが簡単でした。元のTCP/IP仕様は、 HOSTS
と呼ばれる特別なテキストファイルを使用して名前の解決を実装しました。このファイルのコピーは、インターネット上のすべてのコンピューターシステムに保存されました。
HOSTS
ファイルには、対応するシステム名にマッピングしたインターネット上のすべてのコンピューターのIPアドレスのリストが含まれていました。中央HOSTS
ファイルが更新され、毎日配布されました。これは、インターネットに数千のシステムが接続されるまで、かなりうまく機能しました。 TCP/IPシステムにはまだコンピューターにHOSTS
ファイルがありますが、 HOSTS
ファイルは名前解像度の主要なソースではなくなりました。
もともと、名前解像度のために中央のスーパーコンピューターを持つという概念が考慮されましたが、このソリューションも制限に達し、あまり実用的ではありませんでした。名前解決プロセスを委任するという考えは、制限プロセスの懸念を軽減するでしょう。 DNSの階層は生まれ、今日まで、まだ大きくなって拡大しています。
root
ドメインは、DNSルートサーバーとして総称される世界中に分散された13のDNSシステムで構成されています。これらのシステムを表す13のIPアドレスがありますが、実際には13を超えるサーバーがあります。
一部のIPアドレスは、実際にはバランスバランスの仮想IPをロードするため、IPアドレスの一部をロード共有している2つ以上のDNSサーバーがある場合があります。 Hostnameによる13のRoots Serversのリストを次に示します。
DNSサーバー | IPアドレス |
---|---|
a.root-servers.net |
198.41.0.4 |
b.root-servers.net |
192.228.79.201 |
c.root-servers.net |
192.33.4.12 |
d.root-servers.net |
128.8.10.90 |
e.root-servers.net |
192.203.230.10 |
f.root-servers.net |
192.5.5.241 |
g.root-servers.net |
192.112.36.4 |
h.root-servers.net |
128.63.2.53 |
i.root-servers.net |
192.36.148.17 |
j.root-servers.net |
192.58.128.30 |
k.root-servers.net |
193.0.14.129 |
l.root-servers.net |
199.7.83.42 |
m.root-servers.net |
202.12.27.33 |
DNSルートサーバーは階層を確立しますが、名前解決プロセスのほとんどは他のDNSサーバーに委任されます。階層のDNSルートのすぐ下には、トップレベルのドメインサーバーがあります。これらのトップレベルのDNSサーバーは、 com
、 net
、 org
、 edu
、 gov
、 mil
などのトップレベルドメインを処理します。
トップレベルのDNSサーバーは、数千の第2レベルのDNSサーバーに委任します。セカンドレベルのドメイン名は、企業や他の組織に販売されています。この構造の第2レベルは、数百万のドメイン名で構成されています。セカンドレベルのDNSサーバーはさらにゾーンを委任できますが、最も一般的なホストレコードwww
など、個々のホストレコードをドメイン名に保存します。
たとえば、 corp.com
ドメインには、192.168.0.1のIPアドレスを持つwww
と呼ばれるDNSエイリアスを備えたサーバーがあります。 corp.com
ドメインを制御するDNSサーバーのみが、ホストレコードwww.corp.com
の実際のIPアドレスを保存します。 corp.com
ゾーンを保存しない他のDNSシステムには、この情報がありません。
DNSシステムは、リゾルバーがこのゾーンをホストしているDNSサーバーに到達するまで、リゾルバー(クライアントにDNSリクエストを作成する)を紹介します。このゾーンをホストするDNSサーバーがリゾルバーからクエリを受信すると、クエリへの回答とともにリゾルバーが送信されます。
DNSネームスペース
DNSネームスペースは、コンピューターのファイルシステムの仕組みと同様の方法で機能します。 DNSネームスペースは、 DNSドメインと、木のような構造に編成された個々のホスト名の階層です。
各ドメインはフォルダーに似ています。典型的なフォルダー構造と同様に、フォルダーにはフォルダーまたはドキュメントを含めることができます。 DNSでは、ドメインには他のドメインまたはレコードを含めることができます。
リソースレコード
セカンドレベルのDNSサーバーでは、通常、リソースレコードを見つけます。リソースレコードマップサービスとホスト名からIPアドレス。たとえば、最も一般的なリソースレコードはホスト(a)レコードです。ホスト名は、名前をIPアドレスにマップするだけです。最も一般的なホスト名はwww
レコードです。場合によっては、別のホストレコードを指すためにエイリアス( CNAME
)レコードを使用することが望ましいです。
たとえば、サーバーにサーバーに関連付けられた複数の名前がある場合、Server1と呼ばれるホスト(a)レコードを作成し、コンピューターのIPアドレスにマッピングできます。次に、 www
、 ftp
、 mail
などのいくつかのエイリアス( CNAME
)レコードを作成し、同じホスト名に戻ります。ゾーン内で使用される最も一般的なDNSレコードのリストを次に示します。
説明 | タイプ | 目的 |
---|---|---|
標準名 | CNAME |
ホスト名へのエイリアス |
ホスト | A |
HOSTNAMEからIPアドレスへのマップ |
名前サーバー | NS |
マップServer Name Name to IPアドレス |
メール交換器 | MX |
Maps Mail Exchange Server DNS名 |
権威の始まり | SOA |
ゾーン構成 |
名前解決プロセス
DNSが最初に設計されて以来、名前解決プロセスは大幅に変更されていません。 DNS Resolver(DNSクライアント)がホスト名を解決してリソースにアクセスできるようにする必要がある場合、最初にDNSサーバーに連絡する必要があります。
接触するDNSサーバーは、クライアントTCP/IP構成によって異なります。 DNSクライアント構成がDHCP構成に含まれるか、クライアント設定で手動で構成する必要があります。
プライベートネットワーク内のコンピューターの場合、内部DNSサーバーを指すように構成することをお勧めします。インターネット上のシステムの場合、ISPのDNSサーバー、またはGoogleのパブリックサーバー( 8.8.4.4
および/または8.8.8.8
)など、インターネット上の多くのパブリックDNSサーバーの1つを指すように構成できます。
上記のグラフィックでは、名前解決プロセスには、DNSクライアントからホスト名を解決するために取る必要がある8つのステップを示しています。このグラフィックを使用して、典型的な例をより詳細に説明できます。
次の例では、DNSクライアントがインターネット上のWebサーバーにアクセスしようとしています。クライアントがWebサーバーと通信する前に、Webサーバーのホスト名をIPアドレスに解決する必要があります。
- ステップ1 :DNSクライアントがISP DNSサーバーをクエリして、ホスト名
www.domain.com
を解決します。 - ステップ2 :ISP Webサーバーは、DNSキャッシュとローカルゾーンをチェックします。一致していない場合、DNSサーバーはルートDNSサーバーをクエリします。
- ステップ3 :ルートDNSサーバーは、リクエストを
.COM
DNSサーバーに送信できるように、紹介でISP DNSサーバーに返信されます。 - ステップ4 :ISP DNSサーバーは、クエリを
.COM
DNSサーバーに送信します。 - ステップ5 :
.COM
DNSサーバーは、リクエストをDOMAIN.COM
DNSサーバーに送信できるように、紹介でISP DNSサーバーに返信されます。 - ステップ6 :ISP DNSサーバーは、クエリを
DOMAIN.COM
DNSサーバーに送信します。 - ステップ7 :
DOMAIN.COM
DNSサーバーは、www.domain.com
クエリに対する回答を使用して、ISP DNSサーバーに返信されます。 - ステップ8 :ISP DNSサーバーは答えをキャッシュし、答えをリゾルバーに送り返します。
Resolver(DNSクライアント)がWebサーバーのIPアドレスを持っているため、ResolverはWebサーバーとの直接通信を開始できるようになりました。また、DNSサーバーは、このプロセス中に受け取った情報をキャッシュすることに注意する必要があります。
そのため、将来の要求がキャッシュレコードの時間(TTL)期間内にある限り、このホスト名の将来のリクエストは、プロセス全体を最初から最後まで実行するのではなく、キャッシュから解決できます。