コンテンツにスキップ

DNSサーバ

出典: フリー百科事典『ウィキペディア（Wikipedia）』

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

概要

[編集]

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

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

DNSの仕組み

[編集]

DNSによる名前解決には、以下の3種類の構成要素によって成り立っている。その内、DNSサーバは分散型データベースの1ノードとして機能しており、「フルリゾルバ（DNSキャッシュサーバ）」と「権威サーバ（DNSコンテンツサーバ）」の2種類に分類される。

  • スタブリゾルバ（DNSクライアント）: PCやスマートフォン、サーバなどのOSに組み込まれているDNSクライアント機能のこと。DNSライブラリとも言われる。
  • フルリゾルバ（DNSキャッシュサーバ）: 問い合わせを代行してくれるサーバ。フルサービスリゾルバ、参照サーバとも言われる。
  • 権威サーバ（DNSコンテンツサーバ）: ドメイン名の情報を持つ「持ち主」のサーバ。権威DNSサーバ、ゾーンサーバとも言われる。

名前解決の流れ

[編集]
  1. PCやスマートフォンのスタブリゾルバ（DNSクライアント）が、設定されたフルリゾルバ（DNSキャッシュサーバ）に「www.wikipedia.orgのIPアドレスは？」と問い合わせる（再帰的問い合わせ）。
  2. DNSキャッシュサーバは、まずルートサーバ（DNSの階層構造における最上位に位置する権威サーバ）に尋ねる。
  3. ルートサーバから「.org」を管理するサーバを教わる。
  4. 「.org」のサーバから「wikipedia.org」を管理する権威サーバ（DNSコンテンツサーバ）を教わる。
  5. 「wikipedia.org」のDNSコンテンツサーバに尋ね、最終的なIPアドレスを受け取る（ここまでのキャッシュサーバの動きが反復問い合わせ）。
  6. フルリゾルバ（DNSキャッシュサーバ）は結果をPCに返し、一定期間その情報をキャッシュ（保存）する。

スタブリゾルバ（DNSクライアント）

[編集]

クライアント側で動作する名前解決プログラムの一種である。「スタブ (Stub)」は英語で「木の切り株」「（切符などの）半券」「端くれ」といった意味を持ち「機能が簡略化されたダミープログラム」を指す言葉として用いられる。通常、パソコンやスマートフォンなどのオペレーティングシステム (OS) のネットワーク機能の一部として組み込まれている。

「DNSクライアント」「DNSライブラリ」とも呼ばれる。

役割と機能

[編集]
  • アプリケーション（ウェブブラウザやメールソフトなど）からの名前解決要求を受け付ける。
  • OSのネットワーク設定（DHCPによる自動取得、または手動設定）であらかじめ指定されたフルリゾルバ（DNSキャッシュサーバ）に対し、DNSクエリ（再帰的問い合わせ）を送信する。
  • フルリゾルバ（DNSキャッシュサーバ）から返ってきたIPアドレスなどの情報をアプリケーションに引き渡す。サーバーから応答がない場合は、タイムアウト処理や代替サーバーへの再問い合わせを行ったり、見つからない場合はエラーを返したりする。
  • 過去の問い合わせ結果をOSレベルでキャッシュし、同一のドメイン名に対する次回以降の通信を高速化する機能を持つものもある（例: Windowsの「DNS Client」サービス、Linuxの「systemd-resolved」など）。

フルリゾルバ（DNSキャッシュサーバ）

[編集]

フルリゾルバ（DNSキャッシュサーバ）は、DNSクライアント（ウェブブラウザなど、ドメイン名を利用する何らかのアプリケーション等）から再帰的問い合わせによって依頼を受け、反復問い合わせを行い、解決プロセスを代行するサーバである。結果を再利用できるよう、一定期間自らキャッシュする。

「フルリゾルバ」「フルサービスリゾルバ」「キャッシュDNSサーバ」とも呼ばれる。

フルリゾルバ（DNSキャッシュサーバ）では、分散システムであることが多い。システムの各所で情報の一貫性（Consistency）を保つことが極めて重要となる。

再帰的問い合わせと反復問い合わせ

[編集]

キャッシュサーバは、再帰的問い合わせと反復問い合わせ（非再帰的問い合わせ）の2種類の問い合わせを使い分けて名前解決を行う。

再帰的問い合わせ

[編集]

名前解決がされたのであれば、その完全な結果を、できなかった場合は「存在しない」とするやはり完全な結果を求める問い合わせである。ユーザのパーソナルコンピュータなどといった端末のスタブリゾルバから、フルリゾルバ（DNSキャッシュサーバ）に対して送られる。

反復問い合わせ

[編集]

反復問い合わせとも。この問い合わせを受けた権威サーバ（DNSコンテンツサーバ）は、自分自身が持っている情報であればそれを、委任している情報であればそのこと（委任情報）を返す。フルリゾルバ（DNSキャッシュサーバ）はその内容に応じて次々と問い合わせを反復する（一般的にはルートサーバから順にドメインツリーをたどる）。

典型的で単純な例で説明すると、ユーザプログラムからlibcの gethostbyname (3) を通して、/etc/resolv.conf で設定されたフルリゾルバ（DNSキャッシュサーバ）への問い合わせが「再帰的問い合わせ」で、キャッシュサーバが行う、権威サーバ（DNSコンテンツサーバ）群への繰返しの問い合わせが「反復問い合わせ」である。

DNSキャッシュサーバへの接続

[編集]

ほとんどの場合、キャッシュサーバは接続プロバイダなどによって用意されており、「インターネットを利用するための機器の設定」にその設定が含まれている。あるいは、DHCPを利用してIPアドレス等と一緒に自動的に設定してしまうことが多い。

ネットワーク内に、キャッシュサーバを用意し、そちらを使うこともできる。

受けた問い合わせを単に上位のDNSサーバーに転送（フォワード）するだけのものも存在する。これは一般にDNSフォワーダと呼ばれ、プロキシに近い動作原理を持つ。情報の一貫性が優先される場合、DNSフォワーダのようなキャッシュをもたない動作のほうが、システム全体の情報の不整合の防止という観点で有利であるとされることがある。

  • WindowsやmacOS、iOSやAndroidをはじめとする、ネットワーク通信可能なオペレーティングシステムには、ネットワーク関連の設定に「DNSサーバ」のIPアドレスを指定する項目がある[1]。一般に gethostbyname(3) といったようなライブラリ関数による処理の中で[2]、これらの設定に従い、フルリゾルバ（DNSキャッシュサーバ）への問い合わせ等が行われる。
  • 応答がない場合に備え、優先（プライマリ）と代替（セカンダリ）の2つを設定できる。これにより、フルリゾルバ（DNSキャッシュサーバ）の可用性を高める。これはコンテンツサーバのプライマリ/セカンダリとは全く異なる概念であるので、混同しないように注意したい。（#プライマリサーバとセカンダリサーバ）。

権威サーバ（DNSコンテンツサーバ）

[編集]

権威サーバ（DNSコンテンツサーバ）の役割は、Domain Name Systemにおいて、ドメインの管理情報、すなわち、自ゾーンの管理するサーバのリソースレコード(RR)と、ドメインの委任に関する情報を保持し、問い合わせ要求があったときに応答することである。コンテンツサーバはドメインの持ち主が管理することもできるが、多くの場合、プロバイダやレンタルサーバ業者などが提供しているものを利用する[3]。

役割と機能

[編集]
  • 自らが「ゾーン」（ドメイン名空間、例: wikipedia.org）を管理し、情報を世界に公開する。
  • 独自のドメイン名をドメインレジストラで登録するときに、「そのドメイン名を管理するDNSサーバ」として指定する。
  • 外部からの反復問い合わせに応答し、自身の持つ情報、あるいは「知らない」という情報（委任情報）を返す。
  • 社内ネットワーク専用で使用され、一般に公開しないゾーンを管理するものもある。この場合、ドメインレジストラへの登録の必要はない。

リソースレコード(RR)

[編集]

権威サーバ（DNSコンテンツサーバ）は、「ゾーン情報」（ゾーンファイル）内のリソースレコード（資源レコード）と呼ばれるデータ内で、以下のような情報を管理する。

→詳細は「DNSレコードタイプの一覧」を参照
  • Aレコード：名前に対するIPv4アドレス
  • AAAAレコード：名前に対するIPv6アドレス
  • MXレコード：メールサーバーのホスト名の完全修飾ドメイン名（FQDN）
    →詳細は「MXレコード」を参照
  • NSレコード：そのゾーンを管理する権威サーバ（DNSコンテンツサーバ）名
  • CNAMEレコード：その名前に対する別名（エイリアス）
    →詳細は「CNAMEレコード」を参照
  • PTRレコード：IPアドレスに対応するドメイン名。逆引き用である。（例： 198.51.100.234 というIPアドレスを逆引きするには 234.100.51.198.in-addr.arpa という名前のPTRレコードを問い合わせればよい）
  • SOAレコード：ゾーンそのものの情報
  • TXTレコード：テキスト情報、汎用性が高い。
    • SPF (Sender Policy Framework) - ドメインのメール送信を許可するサーバーのIPアドレスなどを記述
    • DKIM (DomainKeys Identified Mail) - 公開鍵を記述し、なりすましを防止する
    • DMARCレコード - DMARCのバージョン、認証に失敗したメールのポリシー、集計レポートの送信先などのタグと値を記述
    • BIMI（Brand Indicators for Message Identification）レコード - バージョン番号、ロゴのURL、PMCのURLを登録することで、メールにロゴを表示できる。
    • GoogleやAWSなどのサービスにおけるドメイン所有権
  • DNSKEYレコード/RRSIGレコード：応答の正当性を保証するDNSSECの電子署名情報

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

[編集]

DNSでは、安定した名前解決のため、複数のサーバで運用されるのが一般的である。コンテンツサーバには、「プライマリサーバ」と「セカンダリサーバ」の分類があり、マスタとスレーブの関係にある。

プライマリサーバ

[編集]

ゾーン情報（オリジナル）を管理し、自らのゾーン情報に関する問い合わせに回答したり、セカンダリサーバへ配信したりする。Windows Server同梱のDNSサービスにある動作モード「Active Directory統合ゾーン」は、プライマリサーバとしての役割に機能拡張[4]がされたものである。

セカンダリサーバ

プライマリサーバから受け取った情報を保持し、担当するゾーンに関する問い合わせに回答する。自らはゾーン情報を管理しない。

DNSゾーン転送

[編集]

プライマリサーバからセカンダリサーバーへ、「ゾーン情報」（ゾーンファイル）を同期する仕組み。「DNSゾーン転送」とも言う。

→詳細は「DNSゾーン転送」を参照

セキュリティ

[編集]

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

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

DNSSEC

[編集]

電子署名を用いてDNSの応答が改ざんされていないことを保証する「DNSSEC」機能が提供されている。

→詳細は「DNSSEC」を参照

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でも問題が発生する可能性があり、インターネットの利用に問題が発生する場合がある。

オープンリゾルバ

[編集]

フルリゾルバ（DNSキャッシュサーバ）に不適切な設定をすることで、誰からの再帰検索要求に対しても応じてしまう状態になることがある。これを「オープンリゾルバ」という。オープンリゾルバは、攻撃者に利用され、DNSamp攻撃やその他攻撃の踏み台にされる恐れがありセキュリティ上の問題がある。点検用にオープンリゾルバであるかを確認するサイトがある[5]。

実装と運用

[編集]

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

注意

[編集]

BINDなどに代表されるDNSサーバソフトウェアの多くでは、1台でコンテンツサーバとキャッシュサーバの両方の機能を設定できる。このため、設定を誤ると、セキュリティ上のリスクを抱えてしまうことが指摘されている[6]。

脚注

[編集]

注釈

[編集]
  1. ↑ MXレコードなどはIPアドレス以外に解決される。他にも近年はメイルの返信元の真正性確認などに使われるTXTフィールドなどがある。設計上は任意の拡張が容易なように作られている（たとえば、IPv6のために追加されたAAAAレコードなど）。
  2. ↑ フィッシングサイトなど悪意のあるウェブサーバへ誘導されてしまったり、メールの転送先を変更され窃取されたりすることになる。

出典

[編集]
  1. ↑ Windowsでは、コントロールパネルのネットワーク設定、macOSでは「システム環境設定」の「ネットワーク」、Unix系では/etc/resolve.confなど
  2. ↑ 「オペレーティングシステムが名前解決を必要とした際」ではない。
  3. ↑ 特に、可用性を上げるためのセカンダリサーバは、上流のネットワークなどができるだけ別系統であることが望ましく、2系統のネットワークを持たない場合などには外部に出すのが現実的なことが多い。
  4. ↑ https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc731204(v=ws.10)?redirectedfrom=MSDN
  5. ↑ オープンリゾルバー確認サイト
  6. ↑ “DNSサーバの脆弱性に関する再度の注意喚起：IPA 独立行政法人 情報処理推進機構”. www.ipa.go.jp. 2022年3月10日閲覧。

外部リンク

[編集]

関連項目

[編集]

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

[編集]

DNSをターゲットとしたエクスプロイト

[編集]
「https://ja.wikipedia.org/w/index.php?title=DNSサーバ&oldid=110333837」から取得