DNS導入に向けての予備知識：DNSの仕組みと運用（3）（2/3 ページ）

[加地眞也，＠IT]

リゾルバ・サービスの構築〜フルサービス・リゾルバとキャッシュ・サーバ

　DNSサーバというと、ついついプライマリ・サーバやセカンダリ・サーバの設定に目を奪われがちだが、実際のサービスとしては、内部ユーザーのために「リゾルバ・サービス」を提供するDNSサーバも重要なファクトとなる。実際の運用に当たっては、両面からの考慮が必要だ。

　「フルサービス・リゾルバ」は、すでに本連載の第1回「DNSの仕組みの基本を理解しよう」で述べた。いうなれば、組織内のDNSクライアントを代表して、実際のDNS検索を行うDNSサーバだ。クライアントPCなどで設定している「DNSサーバ」とは、このフルサービス・リゾルバ機能を提供しているDNSサーバのことである。これは、純粋なプライマリ・サーバやセカンダリ・サーバの機能とは異なる。純粋なプライマリ・サーバやセカンダリ・サーバは、通常、再帰検索には対応しないので、ユーザーが必要とするDNS検索には利用できない。

画面1　Windows 2000のネットワーク・プロパティにおけるDNSサーバの指定。ここで指定するサーバがフルサービス・リゾルバだ。複数指定しておくと、先頭のサーバがダウンしていても順に再試行してくれる（画面をクリックすると拡大表示します）

domain example.com
server 192.168.22.250
server 192.168.24.251

リスト1　Linuxの/etc/resolv.conf（リゾルバ機能設定ファイル）の例。Windowsと考え方は同じだ。複数のserver行の指定で、複数のフルサービス・リゾルバが指定できる

　フルサービス・リゾルバ機能を提供するDNSサーバが1台でプライマリ・サーバやセカンダリ・サーバも兼ねている場合があるが、正しい理解のためには別機能として区別して考えてほしい。

　また、多くのフルサービス・リゾルバは「キャッシュ・サーバ」機能も備えている。キャッシュ・サーバは、一度受け付けて解決した問い合わせを一定期間キャッシュし、次に同じ問い合わせを受けた場合には、キャッシュの情報を回答する。さらに探索経路上のDNSサーバ名もキャッシュするので、毎回ルート・ネーム・サーバから検索を開始する可能性も減る。これにより、ルート・ネーム・サーバなどへの負荷は極力低減することができる＊5。また、自組織としてもインターネット・アクセスがそれだけ減らせるため、有効な手段となる。

図4　フルサービス・リゾルバとキャッシュ・サーバ

　キャッシュ・サーバの役目は、外部のDNSサーバ（プライマリ・サーバやセカンダリ・サーバ）からの問い合わせ結果をキャッシュすることである。キャッシュ・サーバは、あたかも自身が保持する情報であるかのようにクライアントへ返答することになる。これらDNSキャッシュは、当然ではあるが、もともとオーソリティを持たない。だが、クライアントからは区別が付かないので、キャッシュ・サーバがキャッシュを返答する場合には、そのデータがオーソリティを持っていないことを明示しなくてはならない。

C:\>nslookup
Default Server:  ns.XXX.ad.jp
Address:  202.XXX.XXX.10
> www.atmarkit.co.jp
Server:  ns.XXX.ad.jp
Address:  202.XXX.XXX.10
Name:    atmarkit-www.atmarkit.co.jp
Address:  211.4.251.193
Aliases:  www.atmarkit.co.jp
> www.atmarkit.co.jp
Server:  ns.XXX.ad.jp
Address:  202.XXX.XXX.10
Non-authoritative answer:
Name:    atmarkit-www.atmarkit.co.jp
Address:  211.4.251.193
Aliases:  www.atmarkit.co.jp
>

リスト1　nslookupによるキャッシュ・サーバからの非オーソリティ・データの返答例。「Non-authoritative answer:」とあるのが、オーソリティを持たないキャッシュの返答だ。2度問い合わせた結果だが、2度目の結果はキャッシュが返答されていると分かる

　また、キャッシュを効率的に機能させるためには、ゾーン情報に「有効期間（TTL）」を明示する必要もある。さもなければ、新しい情報と古い情報が共存してしまう可能性もあるからだ。まず、SOAレコードにおいてゾーン全体でのデフォルトが設定される。一般には、1日〜数日というのが多いようだ。レコードごとに設定することもできる。この有効期間を過ぎたゾーン情報やレコードは、キャッシュ・サーバなどにおいて破棄されなければならない。また、セカンダリ・サーバが定期的にプライマリ・サーバから最新の情報を確認できない場合にも、ゾーン情報は破棄されることになる。

画面2　Windows 2000 ServerのDNS ServerサービスでのSOAレコードの設定。「最小TTL値」がこのドメインのゾーン情報でのデフォルトのキャッシュ有効期間だ（画面をクリックすると拡大表示します）

＊5ルート・ネーム・サーバである「f.root-servers.net」を運用しているISC（Internet Software Consortium）のWebページによれば、このサーバだけで1日当たり2億7000万回以上のDNS問い合わせを受けているのだそうだ。これら公共のサーバは、インターネットの重要な資源だ。ほぼボランティア的にインターネット・コミュニティのために提供している例も少なくない。キャッシュ・サーバの積極的な活用は、インターネット参加者としての重要な貢献でもある

なぜドメイン情報の反映に時間がかかる？

　よく、DNS情報の設定ミスや事故によりあるサーバへ数日間接続できない、という現象が発生することがある。この場合、より正確には、IPルーティングによるサーバへの到達性はあり、単にDNSからIPアドレスを解決できないだけなのだが、Webサーバなどでは困ってしまうことがある。あるいは、新規のドメインやサーバを構築した場合にも、同様の現象に遭遇することがある。果たして、数日もの間、DNSへ内容が反映されないような状況はなぜ起こり得るのだろうか。

　まず第1に考えられるのは、プライマリ・サーバからセカンダリ・サーバへのゾーン転送に時間がかかっている場合だ。通常、セカンダリ・サーバは定期的にゾーンが更新されているかどうか確認するので、少なくとも瞬時に反映できるとは限らない。しかし多くの場合はせいぜい数時間置きであるし、更新はその組織内の作業で済むので、可能性はあるものの、ほとんどの場合は問題にならないタイムラグだろう。またプライマリ・サーバさえ正常に稼働していれば、可能性はより低くなる。

　実際にタイムラグとなり得るのは、キャッシュ・サーバが保持するキャッシュ情報の問題だ。本文でも述べたが、すべてのDNSキャッシュは必ずTTLを保持し、定期的に最新キャッシュに更新される。しかしこの間隔は、多くの場合、1日〜数日に設定されており、この間は古い情報しかクライアントは参照できない。つまり、プライマリ・サーバやセカンダリ・サーバは、世界中のキャッシュ・サーバからの要求に応じてゾーン情報を配布しているわけだが、行き渡った情報が再度最新に差し替わるのに、それだけの時間が必要になる、ということなのだ。

ダイナミックDNSを活用する

　ダイナミックDNS（動的DNS）は、「DNS Update」とも呼ばれる動的にDNS情報を更新する仕組みだ。RFC2136で規定されている。

　通常のDNSでは、ゾーン情報はもともとローカル・データ（BINDでは「ゾーン・ファイル」、Windows 2000 DNS Serverサービスではレジストリの場合もある)を基に、「静的」な情報をサービスするにすぎない。DNS情報を更新するには、このローカル・データを変更するしかない。ダイナミックDNSでは、クライアントやそのほかのサーバから更新要求を送ることで、外部からAレコードやMXレコードなどのゾーン情報をリアルタイムで更新できる。

　ダイナミックDNSの典型的な適用場面としては大きく2つある。1つ目は社内イントラネットなど、クライアントの数が多くゾーン設定が煩雑な場合だ。特にマシンの移動が激しい場合には、従来ではどうしても必要なとき以外はまったく登録しないことも多かったかもしれない。だが、クライアントがブート時などに自動的に自らDNSへの登録を行ってくれれば、管理の手間なくDNS情報を自動保守できる。

画面3　Windows 2000におけるダイナミックDNSクライアント機能の設定。チェックしておくと、DNSサーバへ自身のホスト名とIPアドレスを自動更新する（画面をクリックすると拡大表示します）

画面4　Windows 2000 ServerのDNS ServerサービスでのダイナミックDNS設定。これは各ゾーンのプロパティ設定だ。「動的更新を使用可能にしますか」を「はい」としておくと、クライアントからの更新要求を受け付けるようになる（画面をクリックすると拡大表示します）

　本来、OSがDNSクライアント機能とともに対応していれば非常に便利なところだが、残念ながらWindows 98／Meなどでは対応していないため、この方法での利用はまだ進んでいない。そこで現在では、DHCPと組み合わせた方法がよく用いられている。Windows

2000 Serverでは、DHCPサーバとDNSサーバを連動させ、DHCPによりリースされたIPアドレスとホスト名をDNSサーバへ自動登録する仕組みが導入されている。DNSサーバから見ると、DHCPサーバがダイナミックDNSクライアントとなる。

図5　DHCPにおけるダイナミックDNS連動

画面5　Windows 2000 ServerのDHCP ServerサービスにおけるダイナミックDNS更新機能の設定。自身がリースしたIPアドレスとホスト名をDNS Serverサービスへ登録する（画面をクリックすると拡大表示します）

　特にActive Directoryでは、ドメイン・コントローラ（DC）のホスト管理のために、この連動機能が必要となる。欠点は、DHCPクライアントとして設定したホストしか登録できない点だが、特に保守の手間がかかるのはクライアント機であろうから、現実的なニーズは高いだろう。Linuxでは、BINDとISC DHCPサーバとの組み合わせで同様の連動機能が利用できる。実際の適用手順については、「連載：BINDで作るDNSサーバ 第4回」（Linux Square）を参照してほしい。なお、どのホストからも任意のレコードが更新可能となっていると、セキュリティ上問題にもなる。それぞれの製品では、通常はネットワーク番号などによりアクセス制限が可能になっているので、活用してみよう。

　2つ目の局面が、現在広まりつつある常時接続環境向けダイナミックDNSサービスだ。一般に、ブロードバンドなどの常時接続環境でWebサーバやメール・サーバを公開したいと思っても、ISPから固定IPが与えられなければ、静的DNS環境では運用がままならない。そこでダイナミックDNSを利用して動的にホスト名やドメイン名を登録しておけば、固定化されたホスト名やドメイン名で公開できることになる。

図6　dyndns.orgにおけるダイナミックDNSサービスの例

　そのためにパブリックなダイナミックDNSサービスをISPや専用のサービスサイトが提供している。ISPが対応してくれていれば、特に設定も必要なく公開可能になるだろうが、そうでない場合には専用のサービスを探してみよう（ぷららネットワークスのサービスではIPアドレスのリースと同時にDNSへ反映してくれる）。有料の場合もあるが、無料のサービスも多い。またサービスの幅も広い。

　一点理解していただきたいのは、1つ目の場面では主にAレコードとPTRレコードの動的更新（ホスト登録）が目的だったのに対し、このダイナミックDNSサービスではAレコードとPTRレコードはもちろん、ドメイン登録のためのSOAレコードやNSレコード、メール・サーバ設定のためのMXレコード設定が可能な場合もあるということだ。単なるホスト登録だけでなくドメインも登録できれば、サブドメインを構築したり独自のメール・ルーティングを導入できたりするなど、利用のバリエーションも広がることだろう。

　ただし、Windows 2000などOSがサポートするダイナミックDNSクライアント機能では、AレコードとPTRレコード登録にしか対応していないため、ほかの更新方法を必要とする。多くのダイナミックDNSサービスでは、Webから更新可能にするなどの対応をしているものの、Web経由の更新をエミュレートしてくれる専用のダイナミックDNSクライアントソフトを準備した方が便利だ。手動によらなくとも定期的に割り振られているIPアドレスを更新してくれる。