|
|
通信とネットワークの基礎知識
|
通信とネットワークTCP/IPとはTCPとUDP上位プロトコルとポート番号IPアドレスとは〜その1IPアドレスとは〜その2IPアドレスとは〜その3回線の種類についてISPの選択ネットワークの構築ルーターの設定〜その1ルーターの設定〜その2ドメイン名について名前解決とネームサーバーダイナミックDNS |
DNSの本当の利点とは任意の クライアント からインターネット経由でホームページを見たり、メールをやり取りしたりするときに、クライアントがそれらのサービスを提供してくれる サーバー を特定するのに用いる所在地情報は、大抵は FQDN です。FQDNではなく直接 IPアドレス を指定するケースはほとんどありません。 クライアントからFQDNによるサーバーの探索が行われると、その探索情報は、「FQDNからそれを指し示すIPアドレスを教えてくれる」 DNSサーバー へと送られ、クライアントはそのIPアドレス情報を元にサーバーを特定し、接続を行う、というのがインターネットにおける一般的な接続手順となります。 単純に考えると、「人間が見て解り難い」という問題にさえ目をつぶれば、サーバーの所在地情報は IPアドレス だけでも構わないように思われます。 そうするとインターネット上に DNS という仕組みそのものが必要ありませんから、 TCP/IP の通信システムはずっとシンプルに、わかりやすくなるはずです。 確かにDNSは、その役目だけをいうならば「FQDNとIPアドレスを結びつける」という単純なシステムです。 しかしそのシステムをうまく利用すれば、IPアドレスだけでは決して実現できないインターネットの便利な運用が可能となります。 例えば、インターネット上の、
211.183.111.34
というIPアドレスを ノード に持つ Webサーバー で、FQDNを利用していない コンテンツ が公開されているとします。 この場合、このコンテンツを閲覧しようと思えば、インターネットに接続した任意の ホスト機 の Webブラウザ で
http://211.183.111.34/
と、IPアドレスを指定してやればよい訳ですから、別に困ることはなさそうに思えます。 ところがもしもその、 "211.183.111.34" のノードが、例えば通信回線の工事でしばらく使用できなくなるとか、あるいは事情があって他の地域にサーバーを移さなければならないとか、そういう場合には困った事態に陥ります。 そういう場合は、サーバーのIPアドレスを一時的に変更、あるいはずっと変更したままにしなければならないわけですから、それまで"http://211.183.111.34/"に接続してくれていたユーザーは、ある日突然、何の前触れもなくコンテンツを閲覧できなくなってしまいます。 |
||||||||
|
|
コンテンツは不特定多数の人が匿名で閲覧するものですから、例えば引越しの後の「電話番号が変わりました。」のような案内状で済ませることはできません。 ところが、インターネット上で
www.obenri.com = 211.183.111.34
という 名前解決 がおこなわれていたとして、クライアントが
http://www.obenri.com/
でコンテンツを閲覧してくれていたとすれば、例えばノードのIPアドレスが 219.189.222.153 に変更になっても、DNSサーバーの設定を、
www.obenri.com = 219.189.222.153
に変更してしまえば、クライアントはサーバーのIPアドレスが変更になったことを何ら意識することなく同じコンテンツに接続しつづけることが可能となる訳です。 つまり、この名前解決の仕組みを利用することで、サーバーのIPアドレスが変更になる環境であっても、所在地情報を継続できるというわけです。 また、IPアドレスとFQDNは必ずしも一対一で対応していなければならない訳ではありません。例えば、
www.obenri.com = 211.183.111.34
及び、
www.uheuhe.com = 211.183.111.34
という具合に、一つのIPアドレスに対して複数のFQDNを割り当てることで、一つの サーバー機 上で "http://www.obenri.com" と "http://www.uheuhe.com" を同時に運用することも普通にできるようになります。 DNSはこのように、実は「所在地名をわかりやすくする」ということが主目的ではなく、所在地情報を自由自在に操ることで有益なサービスを提供することにこそ本当の意義をもっています。
|
||||||||
名前解決の手順とDNSキャッシュDNS による、 FQDN から IPアドレス へ、あるいはIPアドレスからFQDNへの対応を行う作業を、通常 名前解決 と呼びます。そして、その名前解決を行う サーバー が DNSサーバー です。 DNSサーバーは、 Webサーバー や メールサーバー のように単独で全てのサービスを提供するサーバーと異なり、インターネット上の無数のDNSサーバーが協調して動作する 分散型システム になっています。 例えば、あなたが手持ちのパソコン( クライアント )で Webブラウザ を開き、
http://www.obenri.com/
へのアクセスを試みるものとします。
名前解決の流れ図 もし、あなたのパソコンが "http://www.obenri.com/" に対する名前解決情報を持っていない場合、あなたのパソコンは インターネット空間上に設けられた、 DNSサーバー(A) に 「www.obenri.comが指し示すIPアドレスは?。」 という問い合わせ 1 を行います。 |
|||||||||
| DNSサーバー(B) は、必ず存在するわけではありませんし、逆に上位に別のDNSサーバーが存在するかもしれません。DNSサーバーの分散システムとは、そういうものです。 |
もしも DNSサーバー(A) が問い合わせに答えられる名前解決情報を持っていれば、その情報をあなたのパソコンに送り、名前解決は終了します 8 。しかしそうではなかった場合には、 DNSサーバー(A) は更に上位の DNSサーバー(B) へ同じように問い合わせ 2 を行います。 もしもここで DNSサーバー(B) が問い合わせに答えられる名前解決情報を持っていれば、 DNSサーバー(A) へ問い合わせが行われたときと同様に、回答 7,8 の順に情報をあなたのパソコンに送り、名前解決は終了します。 ところが、このように何段階かDNSサーバーを上位へ遡行しても名前解決ができない場合があります。 そういうときには、最終的には世界に十数台だけ設置されている ルートサーバー へ問い合わせ 3 が行われます。 ルートサーバーは、実は自分自身では名前解決を行いません。ルートサーバーは、 |
||||||||
|
|
「全ての ドメイン名 に対して、それぞれが名前解決できるDNSサーバーの場所をIPアドレスで記憶している」 サーバーです。 従って、問い合わせ 3 の内容は、 「ドメイン名"obenri.com"に関する名前解決を行っているDNSサーバーのIPアドレスは?」 というものになります。するとルートサーバーは、 「ドメイン名"obenri.com"に関する名前解決を行っているDNSサーバーのIPアドレスは"211.162.255.31"である。」 という回答 4 を返すことになります。 すると DNSサーバー(B) は "211.162.255.31" に対して、つまり DNSサーバー(X) に対して 「www.obenri.comが指し示すIPアドレスは?。」 という問い合わせ 5 を行いうことになります。 するとリクエストを受けた DNSサーバー(X) は、 「www.obenri.comはIPアドレス"211.183.111.34"を指します。」 という回答 6 を DNSサーバー(B) に返します。 そして同じ回答が、 7 の経路で DNSサーバー(A) へ、更に 8 の経路で大元の問い合わせを行ったパソコンへと送られることになります。 そしてようやくあなたのパソコンは、IPアドレス "211.183.111.34" 宛てに HTTP による接続を行い、 コンテンツ を受け取る、という手順になる訳です。 と、こういう説明をすると、「どうしてもっとすっきりとした仕組みにならないの?」、あるいは、「そのルートサーバーとやらが名前解決を全部やってくれれば簡単なのに。」と思われるかもしれません。 しかし、このDNSの一見複雑なシステムは、その複雑さゆえの大きなメリットをもっています。 先の例でルートサーバーまで順次問い合わせを行ったそれぞれのDNSサーバーは、ただ単に名前解決の問い合わせを中継しただけではありません。 実は、その名前解決に関わったDNSサーバーは、FQDNである "www.obenri.com" の名前解決情報、正確にはドメイン名 "obenri.com" に関するすべての名前解決情報を一定期間 キャッシュ として保存します。 |
||||||||
| DNSキャッシュはDNSサーバーだけではなく、普通はルーターやホスト機自身にも実装されていて、負荷分散の一部を担っています。 |
例えば DNSサーバー(A) を利用するクライアント(あなたを含めて、DNSサーバー(A)を利用する人すべてです。)から、 "obenri.com" に関する問い合わせが再び行われたときは、 DNSサーバー(A) はもう他のDNSサーバーへ問い合わせを行うことなく、自分自身でクライアントに名前解決情報を返すことになります。こういう働きを DNSキャッシュ と呼びます。 実は、前の説明の中でDNSサーバー(A)、(B)が、 「問い合わせに答えられる名前解決情報を持っていれば」 という部分がありますが、これは、 「問い合わせに答えられるDNSキャッシュを持っていれば」 ということを意味しています。 DNSはこのように、名前解決に関わったDNSサーバーがDNSキャッシュを持つことで、ルートサーバーを含む各DNSサーバーへの負荷の一極集中を防ぐような仕組みになっているわけです。
|
||||||||
「権威ある」DNS情報上のパートでも説明しましたが、 DNS のシステムの最高位にある ルートサーバー は、それ自身は 名前解決 の情報を一切持っていません。ただ、 「○○○○という ドメイン名 に関する名前解決情報は、 IPアドレス △△△△で稼動している DNSサーバー が管理しているから、そこに問い合わせに行きなさい。」 という回答を返すだけです。 |
|||||||||
| 特定のドメイン名に関する名前解決を担うDNSサーバーは、問い合わせ負荷の分散と、システムダウンに備える意味でバックアップ用DNSサーバーの設置が必須です。 |
つまり、例えば "www.obenri.com" という FQDN の名前解決情報、つまり "obenri.com" というドメイン名に関する名前解決の情報は、どこかの大きな団体が一括して管理しているわけではなく、会社や団体、個人の所有するDNSサーバー、つまり下の図の DNSサーバー(X) そしてそのバックアップである DNSサーバー(Y) にのみ存在しているということです。 そしてインターネット上で行われる "www.obenri.com" に関する名前解決のうち、 DNSサーバー(X)、(Y) が行う回答を 権威ある回答(Authoritative Answer) と呼び、 DNSサーバー(A)、(B) が行う DNSキャッシュ からの回答を 権威なき回答(Non-authoritative Answer) と呼びます。 そしてこの場合、 DNSサーバー(X)、(Y) は、ドメイン名 "obenri.com" の 権威あるDNSサーバー という表現をします。
「権威あるサーバー」とは つまり、世の中で稼動している無数のDNSサーバーは、その規模の大小には関係なく、 "obenri.com" に関する名前解決情報を得るためには、 DNSサーバー(X)、(Y) のいずれかを参照しなければならないということです。 ということは、 DNSサーバー(X) があなたの自宅にあるDNSサーバーだとすれば、そのたった一台の設定内容を変更するだけで、世の中の "obenri.com" に関する名前解決情報をすべて変更できる、ということを意味しています。 ただ、自宅に設置したDNSサーバーに「権威ある回答」を行わせるためには、 1.そのDNSサーバーのIPアドレスをルートサーバーに登録すること。 2.名前解決を行いたい「ドメイン名」に対して、「権威ある回答」を行わせるDNSサーバーのFQDNを登録すること。 の二つの登録が事前に必要となります。
|
||||||||
一つのIPアドレスに複数のFQDNを設定する上のパートでも少し触れましたが、 IPアドレス と FQDN は、必ずしも一対一の対応で名前解決をするわけではありません。 例えば、 WindowsOS や MacintoshOS を LAN で接続してファイル共有を行う場合には、一台の ホスト機 には一つのコンピュータ名しか割り当てられないのが普通です。 |
|||||||||
| 例えば今、あなたがご覧になっているホームページのFQDNは "www.obenri.com" ですが、これはホームページを見ていただくための「サーバー機に設定されたFQDNのうちのひとつ」に過ぎません。 |
しかし 公開サーバー の場合は、 ファイルサーバー としてだけではなく、 Webサーバー や メールサーバー など、いくつもの サーバー アプリケーション を並行して運用するのが普通です。 そのため、一つの IPアドレス しか持たない サーバー機 に対しても、サービス毎に異なるFQDNを設定して運用するほうが解り易く、整理し易いというわけです。 更に、一種類のサーバーアプリケーションの運用においても目的の異なる複数のサービスを提供する場合や、複数の ドメイン名 をFQDNとして利用する場合には、更に多くのFQDNを割り当てることもあります。 |
||||||||
| もちろんこのバーチャルホスト機能はWebサーバーだけではなく、メールサーバーなどでも利用されます。 |
それは例えば一台のサーバー機の中で、 "http://www.obenri.com/" と "http://yyy.obenri.com/" といった、同じドメイン名を使った異なる URL で表される別々の コンテンツ を運用できる機能です。また、それに加えて "http://www.uheuhe.com/" のように異なるドメイン名を使ったURLも混在させることができます。 この場合は当然、 "www.obenri.com" 、 "yyy.obenri.com" そして、 "www.uheuhe.com" は、DNSサーバーで全く同じIPアドレスを指し示すように設定することになります。
取得数に制限のある
属性型ドメイン
複数のドメイン名を併用すると、個人用、仕事用、コミュニティ用などに分けて運用することが可能になりますから、 公開サーバー としての楽しさも実用性もぐっと高くなります。 |
||||||||
| もちろん、取得したドメイン名の数だけの管理手数料は支払う必要がありますけど。 |
また、 WBEL や CentOS などの LinuxOS 、 UNIX 系 OS は、ひとつのシステムで複数のドメイン名を効率よく扱えるように設計されていて、複数のドメイン名を運用するからといって複数のインターネット接続契約が必要なわけでもドメイン名ごとに別の サーバー機 が必要になるわけでもありませんから、そのことで大きな金銭負担が発生するわけでもありません。 WindowsOSやMacintoshOSのネットワークのように、「ひとつのパソコンにはひとつのコンピュータ名」という運用が原則の クライアント機 のネットワークしか扱ったことがない人にとっては、 「一つのIPアドレスに対して複数のFQDNがあたりまえに存在する」 というサーバー運用の世界は、とても違和感があることかもしれませんし、管理が面倒のように思えるかもしれません。 しかし、サーバープログラム毎、サービスの対象毎に違うFQDNを付けておくことによって、例えばメールサーバーのFQDNだけを変更したい、Webサーバーの一部だけを停止したい、などという場合に、他のFQDNによるサービスを巻き添えにすることなく任意に操作が可能になりますので、逆に管理がとても容易になります。 最初のうちは戸惑うかもしれませんが、これはサーバー運用の必須ともいえるテクニック(というより常識)なので、是非ともマスターしてください。
|
||||||||
DNSサーバーをどうすべきかDNSサーバー を自宅に設置するべきかそうでないか、ということは、色々な意味で頭を悩ませるところではあります。 自宅に設置したDNSサーバーに、自分専用の ドメイン名 に基づく 「権威ある回答」 を持たせるためには、そのDNSサーバーの所在地情報を ルートサーバー に登録しなければなりません。
DNSサーバーの構成 |
|||||||||
| 固定 グローバルIPアドレス 1個の契約の場合には、 ISP によっては、そのIPアドレスの利用者が「ISP名義のまま」であるケースがあります。この場合はDNSサーバーの登録そのものができない場合がありますので、契約の際は注意が必要です。 |
つまり、まず第一の条件としては、自宅の通信契約が
固定
IPアドレス
また、DNSサーバーには、主動作のための マスターDNSサーバー と、その「バックアップ」として動作する スレーブDNSサーバー が必要ですから、このスレーブDNSサーバーまで自分で設置しようとすれば、 二つの固定IPアドレスが必要 になります。 |
||||||||
もちろん、DNSサーバーとして登録するIPアドレスは、他のサービスと兼用してもかまいませんから、一台のサーバー機で
Webサーバー
などと混在しても大丈夫です。また、
NAT
+
IPマスカレード
を利用すれば、一つのグローバルIPアドレスを利用して、別々の
サーバー機
でDNSサーバー、Webサーバー、
メールサーバー
を分けて運用することも可能です。
|
ということは、 DNS をすべて自分で賄おうとすれば、複数の固定IPアドレス契約か、1個の固定IPアドレス契約の回線二つが最低は必要となるわけですから、かなりのランニングコストを覚悟する必要があります。 ランニングコストにさえ目をつぶるならば、自分でマスターDNS、スレーブDNSを設置してもいいかもしれませんが、実はわざわざ自分でDNSサーバーを設置しなくても、契約する ISP によっては、DNSサーバー運用を代行してくれるところもあります。 ISPのDNSサーバーは信頼性が高く、自宅で運用するよりも安心です。代行料金は1ドメインあたりで月額\1,000〜\3,000程度ですので、自宅で専用のDNSサーバーを運用するよりは経済的かもしれません。 この場合、例えばマスターDNSサーバーだけ自宅に設置し、スレーブDNSサーバーのみISPに依頼する、という方法もあります。会社や団体などで 公開サーバー を所有し、運用しているところはこういう形式が多いようです。 |
||||||||
| DNSサーバーは「マスター機」と「スレーブ機」に分かれている訳ではありません。マスター/スレーブというのはDNSサーバーの「ドメイン名毎の」動作状態に過ぎません、例えばDNSサーバー(A)をobenri.comのマスター、uheuhe.comのスレーブとし、DNSサーバー(B)をuheuhe.comのマスター、obenri.comのスレーブとすることが「普通に」できます。 |
ちょっと変わった方法として、自宅と同じような通信環境で、自分でDNSサーバーを運用しているユーザーさえ見つけられれば、 お互いに相手のDNSサーバーをスレーブサーバーとして使う という方法もとることができます。 この場合は、まずそういう変わった?相手を見つけるのが一苦労かもしれません。もちろん、お互いのDNSサーバーが継続して運用される保証はありませんから、そのあたりも注意が必要です。もちろん運用費用は無料になるはずですから、そういう選択肢も悪くはないでしょう。 さて、いずれにせよここまでの運用パターンは、 自宅の通信契約が固定のグローバルIPアドレス 、であることが前提になっていますので、固定IPアドレスのオプション契約の設定のない多くのISPでは、自宅にDNSサーバーを設置することはおろか、自宅の公開サーバーに対して名前解決を行うことすらできません。 |
||||||||
|
管理人おススメの
ネットワーク解説書です ↓ |
ところがここ数年、非固定のIPアドレスの通信契約(つまりごく普通の通信契約)で、自分でDNSサーバーを設置することなく、低料金または無料で自分専用のドメイン名の名前解決を使用可能にする ダイナミックDNS を利用する例が増えています。 運用コストと手軽さを考えれば、本格的なDNSを構築する前にまずはこちらを選択すべきではないかと思います。 「やっぱりダイナミックDNSには頼らずに、固定IPアドレス契約で自前のDNSサーバーを設置して運用したい!。」
というチャレンジ精神旺盛な方は、
「固定IPアドレス一個でDNSサーバーを構築する」
|
|
|
ドメイン名について
<<Previous
|
Next>>
ダイナミックDNS
|
| このサイトは既に更新を終了していますが、今のところ店じまいの予定はありません。 リンクフリー ですので、趣味や勉強のためでしたら、引用、転用、コピー、朗読、その他OKです。このサイトへのリンクについては こちら をご覧ください。 |
| ”Linux”は、Linus Torvalds 氏の各国における登録商標です。”Red Hat”及びRed Hatのロゴおよび Red Hat をベースとしたすべての商標とロゴは、各国におけるRed Hat, Inc. 社の商標または登録商標です。その他のプログラム名、システム名、製品名などは各メーカー、ベンダの各国における登録商標又は商標です。 |