特集インターネット「常時」接続計画(第2回)6.プライマリDNSサーバとセカンダリDNSサーバデジタルアドバンテージ |
||
各ドメインの情報をサービスするDNSサーバは、ドメインごとに最低でも2台用意することが求められている。これは障害発生時のバックアップや負荷分散のためであり、システムやネットワークなどの障害のために1台が利用できなくなっても、2台あれば、もう1台が代わりに応答を返すことができるからである。もしDNSサーバが何らかの原因で停止してしまうと、インターネット側からのWebアクセスやメール送信など、ほとんどすべての公開サービスへのアクセスが利用できなくなってしまう。また、そのDNSサーバの下位にあるドメインへのアクセスもすべて影響を受けてしまうので(たとえ下位ドメインのDNSサーバが物理的に別のネットワーク上にあったとしても、上位DNSサーバへのアクセスができなければ、そこから下位ドメインのDNSレコードを引くことができなくなる)、DNSサーバに障害が発生することはドメインの運営にとってダメージが大きい。このような問題を避けるため、インターネットに接続されるドメインのためのDNSサーバは、最低でも2台は用意しなければいけないことになっている。大規模な組織ではさらに多くのDNSサーバを用意して、より大規模な負荷分散や耐障害性の向上を図っている。例えば以下に示すのは、InterNICのWhoisデータベースで調べた、Microsoft社のドメイン(microsoft.com)に対するDNSサーバの情報である。このデータベースでは、.com/.net/.org/.eduドメインに対する登録状況を確認することができる。
MICROSOFT.COMのDNSサーバ登録情報の例 | |||||||||
.COM/.NET/.ORG/.EDUドメインにおけるDNSサーバの登録状況は、InterNICのWebページにある Whoisデータベース で調べることができる。ここでは「MICROSOFT.COM」ドメインを調べてみた。DNSサーバが全部で12台も登録されている。名前の文字列などから推測すると、世界中に分散して配置しているようだ。 | |||||||||
|
これを見ると分かるように、microsoft.comドメインには全部で12台ものDNSサーバがあり、地理的にも分散して配置させているようだ。ここまでしなくても、実際には2台のDNSサーバを、“物理的に”分散して配置しておけば実用上はまず問題ない。“物理的に”というのは、距離的、地理的に十分離れた場所にある、異なるネットワーク上へ配置するということを指す。もし同じ部屋の同じネットワーク上に2台のDNSサーバを設置したとすると、例えばビル全体が停電してしまうと両方のDNSサーバが止まってしまうし、インターネットへのアクセス回線が障害を起こしてしまっても、やはり外部からはどちらのDNSサーバにもアクセスできなくなってしまう。これではわざわざ2重化している意味がない。このため、現実的には、物理的(地理的)にも、ネットワーク的にもまったく離れた場所にある2台のDNSサーバで、1つのドメインをサポートしなければならない。一般的には、自社内に1台目のDNSサーバ(プライマリDNSサーバ。後述)を配置し、ISP側に2台目のDNSサーバ(セカンダリDNSサーバ)を配置することが多い。もちろんISP側に置かれた2台目のDNSサーバは、ユーザーが管理するものではなく、ISP側で用意・管理しているものである(他のドメインのセカンダリDNSサーバとしても利用される)。このような2台体制を採用することにより、自社内のシステムがダウンしたり、ISPへの接続回線に障害が発生したりしても、外部からのDNSサーバへのアクセスは可能となる。だたしISP内部や、ISPからさらに上流のインターネットへの回線などで障害が発生すれば外部からDNSサービスが利用できなくなるので、万全を期すならばさらにバックアップ用のDNSサーバを用意することも考えるべきだろう(もっとも、いくらDNSサーバが万全でも、メール・サーバやWebサーバなどがダウンしていては意味がないので、バランスを考えてサーバなどを配置するべきだが)。
プライマリDNSサーバとセカンダリDNSサーバ
ドメインの情報を管理するDNSサーバには、「プライマリDNSサーバ」と「セカンダリDNSサーバ」という2つの種類がある(それぞれ「プライマリ・ネーム・サーバ」と「セカンダリ・ネーム・サーバ」と呼ばれることもある)。ドメインを運営する場合は、この2つのDNSサーバの機能の違いについて理解しておくことは非常に重要である。通常は、ユーザーの側に用意するDNSサーバはプライマリDNSサーバにしておき、ISPの側に用意する2台目のサーバをセカンダリDNSサーバとする。
プライマリDNSサーバとセカンダリDNSサーバ |
プライマリDNSサーバの持つゾーン情報(「ゾーン・ファイル」に書き込まれている)は、自動的にセカンダリDNSサーバにコピーされ、DNSサーバとして稼働する。いずれのDNSサーバの場合でも、ユーザー(DNSのクライアント)の側から見ればその違いはない。 |
どちらのDNSサーバも、DNSクライアントの側から見るとまったく同じように振る舞い、その違いはない。2台のDNSはどちらを利用しても、同じ情報が得られるようになっっている。しかし内部的な構造、つまりドメインに関する情報をどのようにして保持しているかという点は異なっている。
ドメインの定義とゾーン情報
DNSサーバが管理しているドメインに関する情報は「ゾーン情報」と呼ばれる。「ゾーン」とは「ドメイン」とほぼ同じ意味か、やや狭い領域を指す言葉であり、DNSサーバで管理する対象となる、一連の情報の集まりのことを指す。例えば、「d-advantage.jp」という「ドメイン」をDNSサーバで管理する場合、DNSサーバには次の4つの「ゾーン」をセットにして定義する必要がある。
ゾーン名 | 意味 |
「d-advantage.jp」の「正引きゾーン」 | 例えば、「www.d-advantage.jp」という名前からそのIPアドレス(「1.2.3.4」)を求めるためのデータを定義する |
「d-advantage.jp」の「逆引きゾーン」 | 例えば、「1.2.3.4」というIPアドレスからその名前(「www.d-advantage.jp」というFQDN名)を求めるためのデータを定義する |
「localhost」の「正引きゾーン」 | 「localhost」という名前から「127.0.0.1」というIPアドレスを求めるためのデータを定義する |
「127.0.0.1」の「逆引きゾーン」 | 「127.0.0.1」というIPアドレスから「localhost」という何前を求めるためのデータを定義する |
DNSサーバにおけるドメイン名とゾーンの関係 | |
1台のDNSサーバでは、指定されたドメイン名のほかに、ローカルホスト(localhost)に対するゾーンも定義しなければならない。それぞれ「正引き」と「逆引き」の2つがあるので、全部で4つのゾーンを定義することになる。1台のDNSサーバで複数のドメインを管理する場合は、「localhost」に対する2つのゾーン定義は1組だけあればよい。 |
DNSサーバ・ソフトウェアを稼働させるためには、ユーザーがこの4つのゾーン情報を定義して、サーバに与える必要があるが、プライマリDNSサーバとセカンダリDNSサーバでは、このゾーン情報の取り扱い方法が異なる。プライマリDNSサーバは、ユーザーが与えたゾーン情報に基づいて動作するが、セカンダリDNSサーバは、プライマリDNSサーバから自動的にゾーン情報をコピーして取得し(これを「ゾーン転送」という)、その情報に基づいて動作する。そのためセカンダリDNSサーバに対しては、ユーザーがいちいちゾーン情報ファイルを設定する必要はない。ドメインの管理者はプライマリDNSサーバの情報さえきちんとメンテナンスしておけば、その内容が自動的にセカンダリDNSサーバにコピーされ、動作するのである。プライマリDNSサーバの内容は一方的にセカンダリDNSサーバにコピーされるため、それぞれ「マスター(DNS)サーバ」、「スレーブ(DNS)サーバ」とも呼ばれることがある。
1つのドメインには複数のDNSサーバが必要と述べたが、その場合、通常は1台だけをプライマリDNSサーバにして、残りのサーバはすべてセカンダリDNSサーバとして構築しておく。こうすればプライマリDNSサーバの情報を更新するだけで、自動的に残りのセカンダリDNSサーバの情報も更新され、管理の手間が最小限ですむ(すべてをプライマリDNSサーバにしてもよいが、管理の手間が増えるだけで、特に何のメリットもないだろう)。通常、ISP側に置かれたセカンダリDNSサーバは、ユーザー側にあるプライマリDNSサーバからドメインのゾーン情報をコピーして動作するようになっているので、ユーザーがいちいちセカンダリDNSサーバの設定を行ったり、操作を依頼したりする必要はない。
INDEX | ||
[特集]インターネット「常時」接続計画 | ||
第2回 ドメイン構成のプランニング | ||
1.インターネット・ドメインで必要なサービスとその配置(1) | ||
2.インターネット・ドメインで必要なサービスとその配置(2) | ||
3.ホスティング・サービスと自社サーバの使い分け | ||
4.DNSサービスとは? | ||
5.階層化されたDNS名前空間 | ||
6.プライマリDNSサーバとセカンダリDNSサーバ | ||
インターネット「常時」接続計画 |
- Azure Web Appsの中を「コンソール」や「シェル」でのぞいてみる (2017/7/27)
AzureのWeb Appsはどのような仕組みで動いているのか、オンプレミスのWindows OSと何が違うのか、などをちょっと探訪してみよう - Azure Storage ExplorerでStorageを手軽に操作する (2017/7/24)
エクスプローラのような感覚でAzure Storageにアクセスできる無償ツール「Azure Storage Explorer」。いざというときに使えるよう、事前にセットアップしておこう - Win 10でキーボード配列が誤認識された場合の対処 (2017/7/21)
キーボード配列が異なる言語に誤認識された場合の対処方法を紹介。英語キーボードが日本語配列として認識された場合などは、正しいキー配列に設定し直そう - Azure Web AppsでWordPressをインストールしてみる (2017/7/20)
これまでのIaaSに続き、Azureの大きな特徴といえるPaaSサービス、Azure App Serviceを試してみた! まずはWordPressをインストールしてみる
|
|