Practice For Learning DNS

DNSの仕組みについて

はじめに

このトピックでは、DNSの基本的な動作について説明します。
現在、DNSに関する情報はいくらでも手に入るようになりました。書籍も充実しています。
BINDを使って独習するのに何の不足もありません。

  1. お気に入りのブラウザーを開く
  2. FirefoxやCromeであれば、URLの入力欄に"DNS BIND"と打ち込んでください
  3. 凡そ1,300,000件の中からお気に入りのコンテンツをお選びください。

検索スキルを駆使して独学でDNSを立ててはみたけれど、なんだか物足りない気持ちになりませんか?何故でしょう?

DNSは分散ディレクトリの先駆けとして登場し早くから利用されてきました。DNSを理解するためにはサーバの知識よりもむしろ、分散ディレクトリという技術を用いた、なんだか良くわかないけど、実に壮大(そう)なDNSの仕組みを理解する必要があります。

理解するといっても技術知識エリアについてはこのトピックではあまり大事にしません。それよりも、ただ一つの名前を解決するという動作を通じて、世界はみんな繋がっているんだなぁと感じていただければ、このトピックは成功です。

後半では、エンタープライズにおけるDNSデプロイのポイントについて、多少突っ込んだ紹介も行います。

今回、DNSの基本的な仕組みを知る手掛かりとして、ある架空の企業を用いたプラクティスに参加していただきます。
架空と言えばやはり、XYZですね。



XYZカンパニーのITシステム

まずは架空企業XYZカンパニーのITシステムについて概観します。

XYZカンパニーITシステム概略図

Practice For Learning DNS

XYZカンパニーは、まるでエンタープライズ企業のモデルのようなITシステムを有しています。
以前は社内の情シスで管理していた公開システムも、そのほとんどはマネージド・サービス業者に委託したり、クラウドサービスに切り替えたり、多くの企業が標榜する「所有から利用」を積極的に推進しているようです。

XYZカンパニーが主に利用しているマネージド・サービス業者は2社あります。ひとつはMSP-1でもうひとつがMSP-2です。(もう少し気の利いた名称はつけられなかったのでしょうか・・・)XYXカンパニーにとって、社員の働き方は重要な関心事項です。

「ワークライフバランス」という旗印のもと、社員は自宅からでも社内システムへアクセスして仕事をすることが出来てしまうのです。いつ、いかなる時でも働ける環境を社員のために用意する、XYZカンパニーはそんな社員思いの企業です。

アイテムの説明

それでは、図に示されている個々のアイテムについて説明します。

ロケーション

アイテム 説明
黒い線 各ロケーションの境界線を表します。
xyz.company 本シナリオの主役であるXYZカンパニーの本社拠点です。
DMZ XYZカンパニーの外部公開システム用のDMZエリアです。
現在は外部公開システムの殆どをマネージド・サービス業者に委託しているため、随分閑散としています。
MSP-1 XYZカンパニーが契約しているマネージド・サービス業者の一つであるMSP-1のデータセンタです。
Backend-A MSP-1が保有するバックエンドシステムを表わしています。
MSP-2 XYZカンパニーが契約している二つのマネージド・サービス業者のうち、もう一つの事業社であるMSP-2のデータセンタです。
Backend-B MSP-2が保有するバックエンドシステムを表わしています。
Remote XYZカンパニーの社員の自宅です。
XYZカンパニーは、社員がVPNを経由して自社システムにアクセスすることが許可されており、社員は自宅(リモート)から自社のITシステムを利用することが出来ます。
Carrier, ISP for Enterprise XYZがインターネット接続用に契約している通信会社及びISP事業社です。
Carrier. ISP for Consumers 自宅(リモート)からアクセスする社員が自ら契約しているインターネット通信業者及びISP事業社です。
TLD DNSのトップレベルドメインを表しています。

次に、図に示されている機器について説明します。

ノード

ノード 説明
Web サーバ XYZカンパニーが提供しているe-コマースビジネスのフロントエンドサービスを提供しているWEBサーバです。
ホスト名は"www.xyz.com."です。
実際のシステムの運用管理はMSP-1に委託しています。
同様に、システムはMSP-1のデータセンタで管理されています。
MAILサーバ XYZカンパニーのメールサーバです。ホスト名は"mail.xyz.com."です。
システムの運用管理はMSP-2に委託しています。
同様に、システムはMSP-2のデータセンタで管理されています。
ERPシステム XYZカンパニーのERPシステムです。
システムのフロントエンドサービスを提供しているサーバのホスト名は"erp.xyz.com."です。
システムの運用管理はMSP-2に委託しています。
同様に、システムはMSP-2のデータセンタで管理されています。
MRPシステムのフロントエンドサーバ XYZカンパニーのグループ企業が利用するMRPシステムです。
システムのフロントエンドサービスを提供しているサーバのホスト名は"mrp.xyz.com."です。
システムの運用管理は自社で行っています。
システムはXYZのイントラ内(internal)で管理されています。
IP電話システム XYZカンパニーのIP電話システムです。
SIPサーバのホスト名は"voip.xyz.com."です。
システムの運用管理は自社で行っています。
システムはXYZのイントラ内(internal)で管理されています。
VPNゲイトウェイ 社員のリモートアクセス用のVPN終端装置です。
ホスト名は"vpn.wyz.com."です。
ファイヤーウォールの機能を利用しています。
ホームゲイトウェイ リモートからアクセスする社員が使用しているインターネットアクセス用の宅内ルータです。
宅内機器のインターネットアクセスのプロキシをおこなっています。
DNSの問い合わせについても、リゾルバとして動作する言わばオープンリゾルバです。

DNSの配置場所

では、前述したXYZカンパニーに関連するDNSを配置してみます。

DNSをデプロイ

設置場所

XYZカンパニーに関連したDNSだけでも3つ種類があることがわかります。

  • Cache
  • Master
  • Slave

個々の役割りについては以降一つひとつ説明しますが、全て同じDNSサーバであることに違いはありません。
同じDNSサーバでも異なる役割があるというのはとても重要なポイントです。
ひとつのサーバで複数の役割りを担うことは出来ないものでしょうか?
可能です。

本来この役割は、サーバにではなくゾーンと言うある限られた名前空間に対して与えらるものです。複数のゾーンを管理するサーバの場合、ゾーンごとに異なる役割を与えられた結果、複数の役割を担う場合が往々にしてあります。

しかしながら、よりセキュアでかつ運用効率を高めたいと考えるのであれば、ひとつのサーバが複数の役割りを兼任するようなデザインは避けるべきです。このことは、このプラクティスの中でとても重要なポイントの一つです。

以下、注意事項です。

  • 配置したDNSは役割毎にアイコンの色が異なります。
  • 当然ながら、数(台数)は表現していません。

それでは、DNSのアイテムについて説明します。

角丸四角の白抜きアイコン
白抜き

XYZカンパニーのドメインである、"xyz.com"を管理している権威ネームサーバを表してます。

Master

"xyz.com"ドメインのマスターサーバです。XYZカンパニーのイントラ内で管理されています。
上位のドメインサーバにはこのマスターサーバのNSレコードは登録していないため、公(おおやけ)からは隠ぺいされています。

また、マスターサーバはプライベートなネットワーク用の" xyz.com "ゾーンと、インターネット公開用の xyz.com "ゾーンの2つをそれぞれ分けて管理しています。

仮に同じドメインであっても、社内からの問い合わせに対してはプライベート用のアドレスを、インターネットに公開しているスレーブサーバに対しては公開用のゾーン情報を提供します。

Slave

スレーブサーバ。"xyz.com"ドメインの権威サーバです。
ゾーンのリソース情報は、マスターサーバから転送された複製データを利用します。

note:
前述した通り、マスターサーバは社内用と公開用で異なるViewを用いて社内と社外を分離・管理しています。

社内用:Internal View
公開用:External View

スレーブサーバには公開用のExternal Viewで管理されているゾーン情報が転送されます。

外部からの"xyz.com"ドメインに関する問い合わせ要求に対して名前解決のサービスを提供します。広域災害を考慮して、スレーブサーバは二つのロケーションに分散して配置しています。

それぞれのスレーブサーバは固有のホスト名をもっています。

  1. 自社のDMZ上のスレーブサーバの名前は、"ns1.xyz.com"です。
  2. 契約している通信業者が提供するホスティングサービスを利用して運用されているスレーブサーバの名前は"ns2.xyz.com"です。

赤塗り
赤塗り

XYZカンパニーの社内ユーザ用のキャッシュネームサーバを表しています。社内からインタネットにサクセスする際に利用されるキャッシュサーバですので非常に重要な役割を担っています。紙面の都合上一つしか描いていませんが、当然のことながら、冗長化されています。

また、リモートからVPN経由でアクセスする社員も、社内システムを利用する際の名前解決にはこのキャッシュサーバを利用します。

緑塗り
緑塗り

リモートからアクセスする社員が契約しているISPが提供している、契約ユーザ向けのキャッシュサーバです。
キャッシュサーバとは?については後ほど詳しく解説します。
ここでは、当該ISPと契約しているユーザがインターネットにアクセスする際の名前解決で利用されるネームサーバとだけ覚えておいてください。

契約時に「DNSサーバのアドレスにはこの値を入れてください」と指示されたり、IPアドレスと一緒に勝手に設定される参照先DNSサーバがこれにあたります。このネームサーバに障害が発生した場合、当該ISPと契約している全ユーザのインターネットアクセスに影響を与えてしまいます。

紙面の都合上一つしか描いていませんが、通常はロードバランサをフロントに配置して複数台のDNSサーバで負荷分散しています。

青塗り
青塗り

関係するトップレベルドメインである"com."の権威ネームサーバ群です。
説明の便宜上、ルートドメインも含んでいます。

note:
xyx.comの権威サーバは"com."にNSレコードとして登録されています。このシナリオでは、XYZカンパニーの"xyz.com"ドメインのマスターネームサーバは隠ぺいされているため、マスタネームサーバは"com."には登録されていません。

"com."ドメインに登録されている"xyz.com"のネームサーバは"ns1.xyz.com"と"ns2.xyz.com"の2つです。

少し込み入った内容になりますが、それぞれのネームサーバの関係をソーンファイルで表現してみます。
水色の線はゾーン転送を表わしています。

Configurations of Zone files

ネームサーバ

まったく正確ではないゾーンファイルですが、DNSの世界がどのようにつながっているのかを少しだけ概観するにはちょうど良い感じです。

DNSの基礎知識

以降、DNSの基本的な仕組みについて説明します。
手はじめに、XYZカンパニーの社員がリモートから社内システムの生産管理システム(MRP)にアクセスする場合の、DNSの動きを追ってみます。

名前解決フローの概略図

MRPにアクセス

図の中の番号を順番に追ってみてください。
社員がリモートから社内システムにアクセスするまでに、多くのDNSが関わっている様子が見て取れると思います。

DNSの基本動作1 キャッシュサーバの役割り

リモートの社員(以降、社員)が社内のシステムにアクセスするためには、最初にVPNゲイトウェイに接続する必要があります。社員がVPNゲイトウェイに接続するためには、VPNゲイトウェイのIPアドレスを知る必要があります。

VPNゲイトウェイのホスト名は、vpn.xyz.com.です。社員がVPNゲイトウェイのホスト名"vpn.xyz.com."からIPアドレスを特定するまでの動作(図の番号@〜E)を追ってみます。

note:
正確には社員のPCが本来の要求元ですが、社員宅のホームゲイトウェイが社員のインターネットアクセスを代理しているので、要求元はホームゲイトウェイとします。ただし、表記は”社員”とします。

番号 社員 ISP Cache Server(緑) Root(.) Name Server com. Name Server xyz.com. Name Server VPN Controller
@ ISPのキャッシュサーバにVPNゲイトウェイ"vpn.xyz.com."の名前解決を要求 > > 問い合わせ受信
A Root Name Serverに"com."のネームサーバを問い合わせ> < "com."のネームサーバのアドレスを回答
B com Name Serverに"xyz.com."のネームサーバを問い合わせ> < "xyz.com."のネームサーバのアドレスを回答
C xyz.com Name Serverに"vpn.xyz.com."のアドレスを問い合わせ> "vpn.xyz.com."のアドレスを回答
D "vpn.xyz.com."のアドレスを受信< < 社員に"vpn.xyz.com."のアドレスを回答
E VPNゲイトウェイとVPNを確立> < 社員とVPNを確立

上述の通り、ただ一つのアドレス(この場合" vpn.xyz.com")を解決するだけでも、多くのネームサーバが連携しているのがわかります。

DNSの仕組みには厳密な基本ルールが存在します。

ルール1 ドメインネームはルート(.)を頂点とした階層構造を表しています。
xyz.com.(エックスワイゼット.コム.)を例にとると、
* xyz.com.はcom.配下に属しています。
* com.はルート(.)に属しています。
ルール2 上位のドメインは、下位のドメインの権威ネームサーバのアドレスを知っています。
ルール3 権威ネームサーバは自身が管理するドメインの名前解決要求に対して回答する責任があります。
ルール4

権威ネームサーバは自身のドメインの一部をサブドメインとして他のネームサーバに管理を委譲することが出来ます。

ただし、その場合はルール2の規則に従い、委譲先のネームサーバ(=下位のドメインの権威サーバ)のアドレスを管理する必要があります。xyz.com.(エックスワイゼット.コム.)を例にとると、.comは、xyz.com.ドメインの管理をXYZカンパニーに委譲しています。

名前解決をしたい要求元は、ルールに従って上位から順にたどっていけば、いずれ特定のホスト名を解決できるというわけです。 インターネット上に広がる途方もなく大きなネームスペースはこのような非常にシンプルな階層構造で繋がっています。 この連携の一つでも上手くいかない時、社員はVPNゲイトウェイのアドレスをDNSの仕組みを用いて解決することは出来ません。

  • DNSの重要な機能としてキャッシュがありますが、今回はDNSの基本的な動作を理解することが目的なので、キャッシュの動作は無視しています。

note:
ルートのアドレスはどうする?
階層構造に頂点に君臨するルート、現在ここには13脚の椅子が用意されています。

では、社員はルートのアドレスはどうやって知ることが出来るのでしょうか?
解決策はいたってシンプルです。要求元のサービス(今回の例の場合、ISPキャッシュサーバが要求もとに相当します)がルートサーバのアドレス情報をファイルなどで管理しています。キャッシュサーバはルートの情報を知っていることが前提のサービスです。

さて、前述した手順をもう一度ご覧ください。

番号 社員 ISP Cache Server(緑) Root(.) Name Server com. Name Server xyz.com. Name Server VPN Controller
@ ISPのキャッシュサーバにVPNゲイトウェイ"vpn.xyz.com."の名前解決を要求 > > 問い合わせ受信
A Root Name Serverに"com."のネームサーバを問い合わせ> < "com."のネームサーバのアドレスを回答
B com Name Serverに"xyz.com."のネームサーバを問い合わせ> < "xyz.com."のネームサーバのアドレスを回答
C xyz.com Name Serverに"vpn.xyz.com."のアドレスを問い合わせ> "vpn.xyz.com."のアドレスを回答
D "vpn.xyz.com."のアドレスを受信< < 社員に"vpn.xyz.com."のアドレスを回答
E VPNゲイトウェイとVPNを確立> < 社員とVPNを確立

ある特定のサーバがやたらと仕事をしているのが見て取れます。緑色をしたISPのキャッシュサーバです。
クラインとに代わって、何度も何度も色々なネームサーバに問い合わせを行っています。この動作を再帰的な問い合わせと呼びます。

キャッシュサーバとは、クライアントに代わって何度も何度も問い合わせを行う(再帰的問い合わせ)とても有り難いサーバのことです。では、キャッシュサーバについてもう少し詳しく見ていきます。

キャッシュサーバとは

キャッシュサーバとは何でしょうか?本稿では技術的な仕様よりも概念が共有できれば良いと思います。

前章でキャッシュサーバを以下のように定義しました。
クライアントに代わって何度も何度も問い合わせを行う(再帰的問い合わせ)とても有り難いサーバのこと。

次のような背景があります。
通常、クライアントは名前解決の処理をサーバに依頼すること しか できません。クライアントは、「調べたい名前を入れて、検索ボタンを押して、結果を待つ」ような動作しか出来ないのです。

ところが前述した通り、DNSの名前解決は、大抵一度のクエリで回答を得られるようにはなっていません。一つの名前を解決するために、何度も何度も問い合わせを行う必要が度々出てきます。知りたいホスト名を入れてただ待つことしかできないクライアントにはこの、 繰り返し問い合わせる(これを、再帰的問い合わせと呼びます)動作が出来ません。

故にインターネットを利用するシステムにおいてはキャッシュサーバの役割りは非常に重要です。クライアントが仮に結果が得られなかった場合(例で言うと、社員が"vpn.xyz.com"のアドレスを得られなかった場合)、以降の処理すなわち、実際にやりたかったことは全て滞ってしまいます。(例でいうと、社員は生産管理システムにアクセスすることが出来ません)サービス利用者から見るとこの状態はサービスが停止している状態と同じことです。

仮にISPのDNSサーバから名前解決の正しい結果が得られなかった場合、ユーザはインターネットを利用することが出来ません。インターネットを利用するために契約しているユーザがそれを利用できなくなる・・・ただ事ではありません。

キャッシュサーバの動作仕様を簡単に解説します。
これは前述した手順の@~Dを説明しています。

Cache Sever1

キャッシュサーバ1

さて、キャッシュサーバと言う名前の通り、このサーバは問い合わせで得た答えをしばらくの間、メモリ上にキャッシュします。キャッシュしている間は、同じドメインを要求された場合、キャッシュサーバは通常の面倒な問い合わせ作業は省略して自身が記憶している値を回答して処理を簡略化します。図で説明するとこのような感じになります。

Cache Sever2

キャッシュサーバ2

キャッシュサーバによってインターネット上の権威サーバの負荷は大幅に軽減されていることが図でも確認できると思います。多くのクライアントから多くの問い合わせを一手に担うことによりキャッシュの効果はますます期待できます。

が反面、クリティカルの度合もなんだか高まっている感じを受けませんか?それは非常に正しい感覚です。

DNSの基本動作2 マスターサーバの役割り

では、めでたくVPN接続を果たした社員は実際にやりたかった生産管理システムへアクセスるための処理に入ります。社員はホスト名を手掛かりにして、生産管理システムのアドレスを調べます。生産管理システムのホスト名は、" mrp.xyz.com."です。名前解決フローの概略図を再掲します。

名前解決フローの概略図

名前解決

社員が生産管理システムのホスト名"mrp.xyz.com."からIPアドレスを特定するまでの動作(図の番号F〜I)を追ってみます。

番号 社員 Internal Cache Server(赤) Master Name Server MRP
F I社内のキャッシュサーバに対して" mrp.xyz.com "の名前解決を要求> > 問い合わせ受信
G 社内のMaster Name Serverに" mrp.xyz.com"のアドレスを問い合わせ> < "mrp.xyz.com"のアドレスを回答
H 受信< < 社員に"mrp.xyz.com"のアドレスを回答
I 生産管理システムに接続> >社員と接続

前述した動作との大きな違いは、内部のキャッシュサーバがDNSの基本ルールに従っていないことです。通常であれば、クライアントから問い合わせを受けたキャッシュサーバは、キャッシュが存在しな場合(このシナリオの想定も同様です)はDNSの基本ルールに従ってルートネームサーバに問い合わせを行うべきですが、ここではいきなりxyz.comの権威サーバであるマスターサーバに問い合わせを行っています(動作G)。

これは自社のドメインの名前解決については自社のマスターサーバに問い合わせを実施し、それ以外は通常のルールに従って名前解決を行うよう、予めキャッシュサーバに設定されているからです。

ではここで、いきなり質問です。
この問い合わせで回答するアドレスは、前述した2つのViewのどちらが適用されるでしょうか?

  1. Internal View
  2. External View

正解は添え字をクリック1

ビューの機能について、紙面の都合上ここでは説明は省きますが、マスターサーバが中と外をどのように管理しているかを理解するためには必要な知識エリアです。

以前、マスターサーバを以下のように説明しました。

上位のドメインサーバにはこのマスターサーバのNSレコードは登録していないため、公(おおやけ)からは隠ぺいされています。

これは、DNSの基本ルールの" ルール2"に反した行為です。

ルール2:上位のドメインは、下位のドメインの権威ネームサーバのアドレスを知っています。そのためには権威サーバのアドレスを上位のドメイン管理者に報告して登録してもらう必要があります。

ルールに反した意図は何でしょうか?
マスターサーバを公(おおやけ)から隠ぺいすることです。ルールに反するという事は、DNSの仕組みではこのマスターサーバの存在を知ることは出来ないという事を意味しています。意図通りですね。

マスターサーバは自身のドメインに関するデータのオリジナルを保持する唯一のサーバです。" 唯一 "なので重要です。企業にとって重要なものは、外部からのアクセスは極力制限されている内部で管理して、可能な限り隠しておきたいものです。

上記内容を踏まえ、再度概略図をご覧ください。

概略図(再掲)

設置場所

マスターサーバが堅牢なセキュリテイシステムに守られた内部のネットワーク内で管理され且つ、DNSの仕組み上において隠ぺいされているのがわかると思います。これは、自社のドメイン(上位ドメインから委譲されたドメインとも言えます)をセキュアに管理するための重要なプラクティスです。

では、自社のドメインの名前解決要求に対してサービスを提供するネームサーバはどれでしょう?
上記図に記されているスレーブサーバ(Slave)が、外部からの問い合わせに対してサービスを提供します。

1 答え:Internal View

DNSの基本動作3 スレーブサーバの役割り

スレーブサーバの役割りを理解するために、もう一つシナリオを考えてみます。
シナリオ:XYZカンパニーの顧客がXYZカンパニーが提供するeコマースを利用しました。
DNSの動きを見てみます。

DNSの動作

DNS動作

eコマースのシステムはマネージド・サービス業者であるMSP-1に全て委託しており、実際のシステムはMSP-1のデータセンターで運用・管理されています。

DNSの動作を順を追って確認します。

番号 社員 ISP Cache Server(緑) Root(.) Name Server com. Name Server xyz.com. Name Server VPN Controller
@ ISPのキャッシュサーバにVPNゲイトウェイ"vpn.xyz.com."の名前解決を要求 > > 問い合わせ受信
A Root Name Serverに"com."のネームサーバを問い合わせ> < "com."のネームサーバのアドレスを回答
B com Name Serverに"xyz.com."のネームサーバを問い合わせ> < "xyz.com."のネームサーバのアドレスを回答
C xyz.com Name Serverに"vpn.xyz.com."のアドレスを問い合わせ> "vpn.xyz.com."のアドレスを回答
D "vpn.xyz.com."のアドレスを受信< < 社員に"vpn.xyz.com."のアドレスを回答
E VPNゲイトウェイとVPNを確立> < 社員とVPNを確立

やはりキャッシュサーバの多忙ぶりが目立ちますが、ここでは"www.xyz.com"の問い合わせに対して回答したxyz.com Name Serverに注目です。このサーバは"xyz.com"ドメインの権威サーバ1でホスト名"はns2.xyz.com"です。XYZカンパニーはこのネームサーバの他にもう一つ権威サーバ(ns1.xyz.com)を自社のDMZに公開しています。

このNS1とNS2のサーバはどちらもスレーブサーバです。前述した通り、XYZカンパニーのドメインを管理するマスターサーバは隠ぺいされています。"マスターを隠してスレーブを公開サーバとして利用する"というこのプラクティスはDNSの運用者に多くのメリットを与えてくれます。

Master & Slave

マスター&スレーブ

技術的には要約し過ぎている感じがしますが、メリットは3つあります。

1.ゾーン情報の一元管理が出来る

自社ゾーンのメンテナンスはマスターサーバだけ行えば残る分散配備されたスレーブサーバはゾーン転送の仕組みによって自動的にデータを同期します3

ここでは、例としてFTPサーバ(ftp.xyz.com)を一つ追加してみます。

  1. マスターサーバのゾーンファイルを編集
  2. FTPサーバのレコードを追加
  3. ゾーンファイルのシリアル番号をインクリメントする
  4. 対象ゾーンを指定してリロード

以上です。
仮にスレーブサーバが数十台あっても、DNS運用者はマスターサーバのゾーンファイルの編集だけ行えば後はスレーブサーバが自動的に同期します。

マスターサーバとスレーブサーバの間で以下のようなやり取りが行われます。

  1. マスターサーバからスレーブサーバに対してNotifyが発行される
  2. スレーブサーバはマスターサーバにゾーンの状態を問い合わせ、マスター側のシリアル番号を確認
  3. 自身のシリアル番号と比較してマスターサーバの番号の方が大きい場合には、ゾーンが更新されたと見做し、マスターサーバにゾーン転送を依頼
  4. スレーブサーバの転送依頼を受けたマスターサーバはゾーンデータを転送

以上、手間いらずです。

ここで質問です。
マスターから転送されるゾーン情報は、2つのViewのどちらが適用されるでしょうか?

  1. Internal View
  2. External View

正解は添え字をクリック4

2.セキュアなDNSシステムが維持できる

DNSに限ったことですが、人が介在するスレーブサーバへのアクセスを極力減らすことだ出来ます。
また、前述した通りマスターサーバは堅牢な仕組みで守ることが出来ます。
もう一つ、スレーブサーバをよりセキュアにするための重要なルールがあります。

スレーブサーバは再帰問い合わせ要求を許可しない

このルールは自社だけにとどまらず全インターネットの健全性を守る意味で非常に重要です。再帰的問い合わせの要求に応えるという事はキャッシュサーバとしても動作するという事と同じ意味です。前述した通り、権威ネームサーバは自身が管理するドメインの名前解決要求に対して回答する責任はありますが、キャッシュサーバとして動作する責任は負っていません。むしろ、 "キャッシュサーバとして動作してはいけません" 。

これはオープンリゾルバの問題として、現在インターネットの健全性を侵す重大な問題として知られています。この問題についてここでは深く触れませんが、ここでは、スレーブサーバは再帰問い合わせ要求を許可しないという重要なルールを押えてください。

先に解説した重要なポイントを再掲します。
よりセキュアでかつ運用効率を高めたいと考えるのであれば、ひとつのサーバが複数の役割りを兼任するようなデザインは避けるべき

3.様々な要求に応じた柔軟なデプロイが可能

分散配置が出来る理由には"1"で説明した通りです。様々な要求とは何でしょう?

  • DR2対策がしたい
  • サービスの応答を時間を改善したい
  • ローカルサバイバビリティを強化したい

事業継続性であったりお客様の体感品質の課題であったりと、どれも事業に直結した要件ばかりです。 これらのビジネス要件に応じたデプロイメントをするためには、それを可能にするための最適なデザインとは何か?を明確に理解しておく必要があります。

1 権威サーバはコンテンツサーバとも呼ばれます。
2 DR ディザスターリカバリ、広域災害対策のことです。
3 勿論、ゾーン転送を正しく行うための設定は必要です。が、その方法については本稿では扱いません。
4 答えはExternal Viewです。

まとめ、そして、おまけ"エンタープライズにおける最適なDNS構成とは?"

以上で今回のプラクティスは終了です。
XYZカンパニーの社員を通じて、DNSの基本的な仕組みを解説しようというのが本稿の試みでした。

DNSの理解は個よりも全体を理解することが大事

設定ファイルの定義や、ゾーンファイルの記述方法などはブラウザに知りたいワードを入れた方がよほど効率的です。
※この時にもDNSは大活躍です。

それよりも、広大なインターネットに接続されている膨大なDNSサーバが、それぞれ役割を持って連携することで成り立っている様子を感じることの方が大事です。

この仕組みによって管理されているホスト名の数は年間10%以上の成長率で増加しています。このとてつもなく巨大な名簿が、「委譲」というシンプルなルールに従い、それぞれが独立した企業や団体によって管理されているというのは凄いことだなと、個人的には関心しきりです。

この巨大なシステムに参加するという事には責任が伴います。冒頭で述べた「所有から利用」の加速度的な促進にともなって、DNSに対する負荷は過去にないほど、うなぎ上りに増加し、ミッションクリティカルなリスクは異常なほどに高まっています。また、別のTipで解説している通りDNSは常に様々な攻撃に晒されてもいます。

本稿では、このシステムを利用し、このシステムに参加する我々自身が、その責任を果たすために必要な知識について、ほんの一部でありますが紹介させていただきました。

最後に" おまけ "です。

本稿で解説した内容を踏まえて、エンタープライズにとって最適(だと思う)DNS構成について紹介します。
実際には各社各様、最適な構成というものがあるとは思いますが、考える際のベンチマークとしてお役に立てば幸甚です。

エンタープライズ企業における最適なDNS構成とは?

この章では、エンタープライズ企業にとってよりセキュアなDNSの構成とは何か?について考えてみようと思います。

レガシーモデル

以前はこうでした。

DNS Best Practice For Enterprise Legacy model

マスター&スレーブ

一般的な概念を踏襲して、エリアを3つに分類しています。

  • 社内ネットワーク(Internal Zone)
  • 公開サーバエリア(Demilitarized zone)
  • インターネットエリア(External Zone)

赤・青・黒色の矢印はそれぞれ目的の異なる名前解決要求を表わしています。

  • 赤色の矢印は、自社のクライアントが外部または自社システムの利用を目的とした名前解決要求を表わします。
  • 青色の矢印は、外部から自社が所有(管理)するドメインの名前解決要求を表わします。
  • 黒色の矢印は自社のクライアントから要求された名前解決をキャッシュサーバが代理して動作する名前解決要求を表します。

薄い青色の矢印は、ゾーン転送の通信を表現しています。
次に、各コンポーネントについて説明します。

名前 場所 役割り
G/W Security Node(s) ネットワーク内外の境界で出入りする通信を監視・制御するためのセキュリティに特化した機器。代表的なファイヤウォールをはじめ、IPSやAPT製品など、ゲートウェイ型に分類されるものも含む。
Slave DNS1 DMZ DMZに配置された、自ドメインのスレーブサーバ。
マスターサーバから受け取った複製情報をもとに、外部からの自ドメインの名前解決要求に対してサービスを提供する。 外部へサービスを提供するため、攻撃の対象に成り得るが、再帰的問い合わせ(Recursion)の機能を無効にすることで攻撃を限定することが出来る。
Slow Drip DNS Attackのような、キャッシュDNSを介した攻撃を受ける可能性はある。
Slave DNS2 DMZ 前述した通り。
ゾーン転送についてはいくつか方法があるが、ここではディジーチェーンのような方法を紹介している。G/Wを介した通信を極力制限するためあえてマスター -> スレーブ -> スレーブと逐次的にゾーン転送を行わせている。
Cache DNS for DMZ nodes DMZ DMZで動作するサーバが利用するキャッシュDNSサーバ。
インターネットに公開されたキャッシュサーバは踏み台に利用される危険があるため御法度になっているが、DMZで動作するサーバに利用を制限することでリスクを軽減することが可能。
Cache DNS for Internal Internal 社内の様々なクライアントの名前解決を請負うキャッシュサーバ。
WEB閲覧など、インターネットのコンテンツを利用するシーンでは欠かすことが出来ない重要なシステムの一つで冗長化されている。通常、強固なセキュリティシステムで守られたエリア(Internal Zone)に置かれているため、外部からの攻撃に対しては安全が保たれているが、昨今ではDNSプロトコルを経由したデータの流出をはかるマルウェアなどが出現し、情報セキュリティの観点から対策の再考が求められている。
Master DNS (Hidden) Internal 自社で所有(管理)するドメインのリソースレコードのマスターデータを管理する唯一の権威サーバ。
重要な役割を担うため、当該サーバへのアクセスは厳しく管理(制限・記録)され、サーバの存在自体も隠ぺいされる。
マスターの権威サーバとして適確に管理されている限り、セキュリティのリスクにさらされることは少ない。

最近の主流モデル

次に現在最も多いDNSの構成について説明します。
XYZカンパニーも同じような構成になっていました。

DNS Best Practice For Enterprise Modern model

主流モデル

大きなアーキテクチャの変更はありませんが、DMZで管理されていたスレーブサーバがホスティング業者(またはマネージド・サービス業者)にアウトソースされていることがポイントです。

実はこのわずかな違いと思える変更から受ける企業の恩恵は、絶大です。企業は、自社で所有するドメインのワークフローを変更することなく、サーバ管理業務のみならず外部攻撃のリスク管理も併せてホスティング業者に肩代わりさせることが出来ます。

各コンポーネントについて説明します。

名前 場所 役割り
G/W Security Node(s) ネットワーク内外の境界で出入りする通信を監視・制御するためのセキュリティに特化した機器。代表的なファイヤウォールをはじめ、IPSやAPT製品など、ゲートウェイ型に分類されるものも含む。
Slave DNS1 HOSTING レガシーモデルとは異なり、デプロイされるロケーションが自社ではなく委託先のホスティング業者側になっている。
レガシーモデルとの変化は僅かだが、恩恵は大きい。
当該DNSサーバは外部に公開されているため、通常、メンテナンスコストも少なくなくイベントが発生した場合の対応や負う責任も大きいが、管理を外部に委譲することでその多くの部分も併せてホスティング業者に肩代わりさせることが出来る。
レガシーモデルと同様にSlow Drip DNS Attackのような攻撃を受ける可能性はあるが、Anycastの仕組みを使ったDNSクラスタ構成を採用するなど、攻撃に備える業者も増えている。
Slave DNS2 DMZ 前述した通り。
ゾーン転送についてはいくつか方法があるが、ここではディジーチェーンのような方法を紹介している。G/Wを介した通信を極力制限するためあえてマスター -> スレーブ -> スレーブと逐次的にゾーン転送を行わせている。
Cache DNS for DMZ nodes DMZ DMZで動作するサーバが利用するキャッシュDNSサーバ。
インターネットに公開されたキャッシュサーバは踏み台に利用される危険があるため御法度になっているが、DMZで動作するサーバに利用を制限することでリスクを軽減することが可能。
Cache DNS for Internal Internal 社内の様々なクライアントの名前解決を請負うキャッシュサーバ。
WEB閲覧など、インターネットのコンテンツを利用するシーンでは欠かすことが出来ない重要なシステムの一つで冗長化されている。通常、強固なセキュリティシステムで守られたエリア(Internal Zone)に置かれているため、外部からの攻撃に対しては安全が保たれているが、昨今ではDNSプロトコルを経由したデータの流出をはかるマルウェアなどが出現し、情報セキュリティの観点から対策の再考が求められている。
Master DNS (Hidden) Internal 自社で所有(管理)するドメインのリソースレコードのマスターデータを管理する唯一の権威サーバ。
重要な役割を担うため、当該サーバへのアクセスは厳しく管理(制限・記録)され、サーバの存在自体も隠ぺいされる。
マスターの権威サーバとして適確に管理されている限り、セキュリティのリスクにさらされることは少ない。

まとめ

どんなに理想的なDNSシステムを構築出来ても攻撃を100パーセント防ぐことは出来ません。
とは言え、前述したプラクティスを採用することで、攻撃にさらされる箇所を制限し、攻撃者が利用できる攻撃手法を限定することは可能です。

さらには唯一外部へ名前解決のサービスを行う権威DNSサーバを専門業者にアウトソースすることで、サーバの管理業務のみならずリスクのアセスメントをも併せて専門業者に委譲することになり、企業自身でアセスメントを行うエリアを更に縮小することが出来ます。

無論、アウトソース先の業者を監査・監督する責任が新たに発生しますがここでは言及しません。

Terilogy HOME > momentum TOP > トピック:DNSの仕組みについて

デモ
momentum
オンラインデモ予約

「説明を聞きながら時間をかけずに理解したい」という方には、オンラインデモをご用意しています。日本全国どこでも、ご覧いただけますので、お気軽にお申込みください。

デモを予約する
デモ
momentum DNS viewer
今すぐ体験する

「自分で操作してみたい」という方には、セルフデモをご用意しています。今すぐDNS viewerを体験してください。

今すぐ体験する
資料請求
資料請求

momentumのカタログを
お届けします。

資料を請求する
テリロジーに相談
お問い合わせ

ご不明な点がありましたら、
お気軽にご連絡ください。
お急ぎの方は 03-3237-3291 へお電話ください。

ウェブからお問い合せ

トップへ