DNSサーバ

DNSサーバは、コンピュータ・ネットワークにおいて、Domain Name Systemの「名前解決」機能が実装されたサーバである。

1. 概要
-----

DNSサーバには、後述するように2種類があり、それぞれ全く異なる働きをするので、「DNSサーバはこのようなことを行う」と説明することはできない。そのためここでは、Domain Name Systemの役割をまず説明する。

インターネットでの通信に際し、URLの中やメールアドレスの中などでの相手先は、IPアドレスが直接指定されることはまず無く、ドメイン名などといった「名前」が使われている。そういった名前から、IPアドレスなどを得る「解決」を行うシステムがDomain Name Systemである。

あるコンピューターが他のコンピュータとインターネットプロトコルを介して通信する際には、通信の相手となるコンピュータに付与されたIPアドレスを知る必要がある。一方、URLなどには、もっぱらドメイン名を使って対象を記述する。ドメイン名から、IPアドレスなどといった必要な情報を得るために、ネットワーク上で情報を提供する仕組みがDomain Name Systemであり、それを担う各サーバがDNSサーバである。

DNSサーバは分散型データベースの1ノードとして機能している。DNSサーバには以下の2種類がある。

#DNSコンテンツサーバ - 自らの「ゾーン」について、情報を管理し問い合わせに回答する。独自のドメイン名をドメインレジストラで登録する際、「そのドメイン名を管理するDNSサーバ」として指定するのがDNSコンテンツサーバである。
社内専用など、一般に公開しないゾーンを管理するコンテンツサーバというようなものもある。当然ながら、レジストラへの登録の必要はない。
コンテンツサーバについては、「権威DNSサーバ」という用語もある。コンテンツサーバという語は上記のような役割のサーバ全般の総称であるのに対し、権威DNSサーバは例えば「wikipedia.orgドメインの権威DNSサーバ」といったように、個々のドメインとの関係を意味する。
#DNSキャッシュサーバ - 依頼された問い合わせに応じて、コンテンツサーバへ必要な問い合わせを行い、結果を依頼元に返す。結果を再利用できるよう、一定期間自らキャッシュする。
フルリゾルバ・フルサービスリゾルバ・キャッシュDNSサーバとも呼ばれる。 DNSサーバが持つ「ゾーン情報」を他のDNSサーバから取得し、同期する仕組みを「DNSゾーン転送」と言う。

2. コンテンツサーバとキャッシュサーバ
--------------------

DNSサーバは、ドメインの持ち主が情報を提供するための「DNSコンテンツサーバ」と、ネットワークの利用者が名前解決に利用するための「DNSキャッシュサーバ」の２種類に大別できる。

両者は全く違うものだが、これらを総称して「DNSサーバ」と呼ぶ。コンテンツサーバはドメインの持ち主が管理することもできるが、多くの場合、プロバイダやレンタルサーバ業者などが提供しているものを利用する。キャッシュサーバは、接続プロバイダなどがほとんどの場合に用意しており、「インターネットを利用するための機器の設定」にその設定が含まれていたり、あるいはDHCPでIPアドレス等と一緒に自動的に設定してしまうことが専らであるが、ユーザのLAN内に用意して、そちらを使うこともできる。DNSの仕組み上キャッシュすることが前提の設計になっているため、キャッシュを持っていて「キャッシュサーバ」と専ら呼ばれるのであるが、中継するのみでキャッシュしない、いわゆるプロキシ的な動作をするものもある。

BINDなどのDNSサーバソフトウェアでコンテンツサーバとキャッシュサーバの両方の設定が行えるため、誤った設定によりセキュアでない状態で運用されてしまうことが指摘されている。

3. DNSコンテンツサーバ
--------------

DNSコンテンツサーバの役割は、Domain Name Systemにおいて、ドメインの管理情報、すなわち、自ゾーンの管理するサーバのIPアドレスなどの各種リソースレコードと、ドメインの委任に関する情報を保持し、問い合わせ要求があったときに応答することである。

DNSサーバが保持する「ゾーン情報」内のリソースレコードの種類の例を以下に示す。

リソースレコードの例
Aレコード 名前に対するIPv4アドレス
AAAAレコード 名前に対するIPv6アドレス
PTRレコード 逆引きたとえば 198.51.100.234 というIPアドレスを逆引きするには 234.100.51.198.in-addr.arpa という名前のPTRレコードを問い合わせればよい
NSレコード そのゾーンの権威あるDNSコンテンツサーバの名前
MXレコード MXレコード}}そのゾーンのメールサーバの名前
SOAレコード ゾーンそのものの情報
CNAMEレコード 　その名前に対する別名
TXTレコード テキスト情報
DNSKEYレコード/RRSIGレコード DNSSECのための公開錠/署名など。

wikipedia.orgのDNSコンテンツサーバの例 このDNSコンテンツサーバは、ja.wikipedia.orgやwww.wikipedia.orgなどwikipedia.orgゾーンの各種リソースレコードを保持している。ただし、orgゾーンに保持されているIPアドレスは知らない。このDNSコンテンツサーバは、ja.wikipedia.orgのIPアドレスを教えるよう要求を受けると、自らが保持しているコンテンツから、ja.wikipedia.orgのIPアドレスを探し、その情報を含めた返答を返す。なお、ドメイン名からIPアドレスを検索する事を正引きと呼び、反対にIPアドレスからドメイン名を検索することを逆引きと呼ぶ。

3.1. プライマリサーバとセカンダリサーバ
----------------------

コンテンツサーバの役割での「プライマリサーバ」と「セカンダリサーバ」は、マスタとスレーブの関係にある。類似の用語である、オペレーティングシステムのネットワーク構成で指定する「DNSサーバ設定」の「優先」「代替」とは全く無関係であり、混同しないよう注意したい。

プライマリサーバ:ゾーン情報を自ら管理し、自らのゾーン情報に関する問い合わせに回答したり、セカンダリサーバへ配信したりする。Windows Server同梱のDNSサービスにある動作モード「Active Directory統合ゾーン」は、プライマリサーバとしての役割に機能拡張がされたものである。セカンダリサーバ:担当するゾーンに関する問い合わせに回答するが、自らはゾーン情報を管理せずプライマリサーバから受け取ったゾーン情報を保持している。

3.2. セキュリティ
-----------

DNSサーバが応答不能になれば、管理しているゾーン内のコンピューターが提供しているサービスを利用できなくなり、誤った情報を回答するとクライアントコンピューターは意図していないノードにアクセスしてしまうことになる。

健全な利用環境を確保するために、DNSサーバのリソースレコードの改ざんやDoS攻撃を防ぐよう、DNSサーバソフトウエアおよびOSの設定やセキュリティ更新プログラムの適用、コンテンツサーバの多重化、ファイアウォールや侵入防止システムの導入などにより対策を講じる必要がある。

電子署名を用いてDNSの応答が正しいことを検証する「DNSSEC」機能が提供されている。

3.2.1. KSKロールオーバー問題
-------------------

DNSSECにおいて、電子署名の正当性検証に使われる最上位の暗号鍵である「ルートゾーンKSK」を更新する際に、EDNSによるIPフラグメンテーションが発生するほどのサイズの応答データが発生するが、通信設定が対応できていないDNSで通信ができず、DNSSECによる正当性検証ができなくなり、インターネットの利用に問題が発生する。

これは、「ルートゾーンKSK」が2016年まで更新されてこなかったために問題になっていなかったが、2016年10月から2018年3月にかけて、 順次変更を行うことになったために顕在化した問題である。特に2017/09/19、2017/12/20、2018/01/11から始まる更新では、IPフラグメンテーションが発生しない1280bytesを超える1414～1424Bytesの応答データが発生するために、問題が発生する。

基本的には、DNSの運用責任者がソフトウェアのアップデートや設定変更で対応すべきものであるが、一般消費者向けのルータに内蔵されているDNS Proxyでも問題が発生する可能性があり、インターネットの利用に問題が発生する場合がある。

4. DNSキャッシュサーバ
--------------

DNSキャッシュサーバの役割は、DNSクライアントからの再帰的問い合わせによって名前解決の依頼を受け、非再帰的問い合わせを行い名前を解決することである。たとえば、Webブラウザで、www.wikipedia.orgなどを入力した際、そのコンピュータがまず名前解決しに行くのがDNSキャッシュサーバである。

DNSキャッシュサーバ自身については、直接なんらかの方法でそのIPアドレスを設定する。近年のLinux環境などでの典型としては、ネットワークインタフェースの立ち上げ時に、DHCPによって受け取ったかネットワーク設定スクリプトに書き込まれているものが、設定ファイルに書き込まれる。あるいは古典的には /etc/resolv.conf は静的な設定ファイルであった。

4.1. 再帰的問い合わせと非再帰的問い合わせ
-----------------------

名前解決における問い合わせには、再帰的問い合わせと非再帰的問い合わせの2種類がある。典型的で単純な例で説明すると、ユーザプログラムからlibcの gethostbyname  を通して、/etc/resolv.conf で設定されたDNSキャッシュサーバへの問い合わせが再帰的問い合わせで、キャッシュサーバが行う、DNSコンテンツサーバ群への繰返しの問い合わせが非再帰的問い合わせである。

再帰的問い合わせ:名前解決がされたのであれば、その完全な結果を、できなかった場合は「存在しない」とするやはり完全な結果を求める問い合わせである。ユーザのパーソナルコンピュータなどといった端末から、DNSキャッシュサーバに対して送られる。非再帰的問い合わせ:反復問い合わせとも。この問い合わせを受けたDNSコンテンツサーバは、自分自身が持っている情報であればそれを、委任している情報であればそのことを返す。DNSキャッシュサーバはその内容に応じて次々と問い合わせを反復する。

5. 実装
-----

代表的なDNSサーバソフトウエアは次のものがある。 DNSサーバの中には、DNSコンテンツサーバとDNSキャッシュサーバが別々になっているものもあれば、両方機能を搭載するものもある。

BIND
djbdns - コンテンツサーバであるtinydnsとキャッシュサーバであるdnscacheからなる
Dnsmasq
Microsoft DNS Server
NSD
Unbound
Knot DNS
PowerDNS
Yadifa
XACK DNS - 国産のDNS製品

6. 端末で指定する「DNSサーバ」
------------------

PCに搭載されるWindowsやmacOS、携帯端末に搭載されるiOSやAndroidをはじめとする、ネットワーク通信可能なオペレーティングシステムには、ネットワーク関連の設定に「DNSサーバ」のIPアドレスを指定する項目がある。一般に gethostbyname といったようなライブラリ関数による処理の中で、これらの設定に従い、DNSキャッシュサーバへの問い合わせ等が行われる。

これらの情報は、DHCPによる管理下にあるネットワークでは、DHCPサーバから受け取ることが可能である場合もある。管理ポリシーによっては、それに従うよう要求されている場合もある。

大抵、複数のDNSサーバを指定可能になっている。DNSサーバへ問い合わせる際に優先順位の高い順に行い、応答がない場合に次位以降のDNSサーバへ問い合わせを行うようになっている。

7. 脚注
-----

7.1. 注釈
-------

7.2. 出典
-------

8. 外部リンク
--------

[1]
[2]
[3]

9. 関連項目
-------

Domain Name System
ダイナミックドメインネームシステム
リゾルバ
DNSルートゾーン
DNS over HTTPS
DNS64

9.1. パブリックなキャッシュDNSサーバ
----------------------

Quad9
1.1.1.1
OpenDNS
Google Public DNS
Yandex.DNS

de:Domain Name System#Nameserver