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

» 2002年01月19日 00時00分公開

IPv6環境とDNSIPv6環境とDNS

　現在皆さんがお使いのネットワークは、ほぼIPv4のネットワークに間違いないだろう。現在のDNSはIPv4を前提に考えられた仕組みではあるが、IPv6でも同様にDNSは使用されるし、大きな変更が予定されているわけではない。IPv6が導入されたとしても、それはプロトコル・スタックが入れ替わるだけで、上位レイヤにそれほど大きな影響は与えられないからだ。ただし、いくつかのIPv6用のレコードを追加することで、IPv4環境との共存が図られている。なぜなら、共存が前提でなければ、移行期や過渡期に対応できないためだ。

　IPv6そのものの仕組みについてはほかの連載に譲るが、まずプロトコル・スタックとしてIPv6に対応したDNSサーバ製品がIPv6ネットワーク内では必要になる。BINDの次期バージョンであるBIND9では、プロトコル・スタックとしてIPv6にも対応し、IPv4との共存も可能だ（ただし現在はまだベータ段階）。つまり、DNSサーバがIPv4／IPv6双方のネットワークから問い合わせが受けられるようになる。これは製品としてのデュアル・スタック対応も意味する。

図7　デュアル・スタック構成されたホストでのDNSサーバ

　ゾーンにおける多くのレコードはIPv6環境でも同様に使用されるが、IPv6のために次のようなレコードが追加されている。AAAA（「クワッド・エー」と読む：RFC1886）レコードRFC1886）レコードは、IPv4におけるAレコードと同じだ。IPv6の128bitsアドレスを格納できるように想定されている。語源はAレコードの4倍のサイズのアドレス（128bits）を格納するところからきているそうだ。

　A6レコード（RFC2874）RFC2874）は、IPv6のステートレス・アドレスの性質を利用して、アドレスを複数のDNSサーバへ分割して登録する仕組みだ。例えば、IPv6アドレスでは前半64bitsの先頭から順に、「TLA（Top Level Aggregator）」「NLA（Next Level Aggregator）」「SLA（Site Level Aggregator）」などが管理する国、地域、ISPや組織などの階層に従って自動的に決定される（連載：IPv6ネットワークへの招待第2回「拡張されたIPv6のアドレス空間」を参照）。従って同一の組織内であれば、前半はほぼ変わらない場合が多い。逆に後半の64bitsはインターフェイス識別子で、一般にMACアドレスなどから決定されるはずなので、管理する組織によらずほぼ一定である（例えば接続されるネットワークが変更されてもインターフェイス識別子は変更されない可能性が高い）。こうした事情から、AAAAレコードのようにすべてを登録しなくとも、前半部分は組織のアドレス専用のDNSサーバから取得できるなど、すでに明白なことも多いだろうし、後半だけ組織のDNSサーバから取得すればよい、という発想である。

　両者はそういう意味からは、同一の目的のレコード（Aレコードの置き換え）であり、いずれが主流となるかはまだ流動的だ。ただし、比較的古くから存在することから、AAAAレコードの方をサポートするDNSサーバが多いようだ。また、この2つのレコードは正引き用レコードということになる。逆引きに関してはこれまでと同じだが、従来「.in-addr.arpa」が使用されていた逆引き用ドメインは、IPv6環境では「.ip6.arpa」ドメインに変更されている＊6。IPv4よりアドレス書式が複雑となるため、アドレスを4bitsごとに32文字の16進数に区切って、IPv4と同様に逆順に並べたnibbleと呼ばれる書式が現在では一般的だ（例：「b.a.9.8……1.0.0.2.ip6.arpa」など）。少なくとも、この違いによってIPv4とIPv6の見分けができるとともに、共存も可能になる。

＊6（修正および追記：2002/1/28）

当初、IPv6用の逆引きドメイン名としては「.ip6.int」が予約されていたが、RFC3152などにおいて「.ip6.arpa」への移行が決定されている。修正前の原稿では、「.ip6.int」を逆引き用ドメイン名としていたが、お詫びして訂正させていただく。arpaTLDは、システマティックな目的で利用するためにIABによって予約されている特殊なTLDで、例えばIP電話などの電話番号を保持する予定になっている「e164.arpa」ドメインなども、すでに定義されている。「ip6.arpa」のゾーン情報も、すでにAPNIC（アジア／パシフィック地域を統括するネットワーク機関）のDNSサーバなどに反映されつつあるが、Windows 2000（IPv6 Technology Preview適用時）やXPのリゾルバでは、まだ「ip6.int」ドメインへの検索しか行えないようだ。流動的な面もあるが、今後アプリケーション（およびプロトコル・スタック）の対応とともに、しばらくは共存状態が続くものと考えられる

　特にAAAAレコードなど、IPv6アドレスを明示的に示すレコードによって、IPv4ネットワークとIPv6ネットワークの共存環境が構築できる。

図8　IPv4とIPv6の共存の一例。フルサービス・リゾルバをデュアル・スタックにすることで、DNSはIPv4のままでも使用可能になる

　IPv6アドレスを入手したいクライアントは、当然IPv6ネットワーク対応クライアントだ。しかし、クライアントやクライアントが利用するリゾルバがIPv4にも対応していれば、取りあえずIPv4ネットワーク上のDNSサーバも利用できる。AAAAレコードとAレコードを区別することで、IPバージョンの差異は吸収可能になるからだ。今後IPv6への移行時には、このような混在環境が数多く見られることになるだろう。

その他のDNS機能その他のDNS機能

　そのほかのDNSにかかわる機能についても触れておこう。

●ラウンド・ロビンと負荷分散

　ラウンド・ロビンは「循環型総当たり方式」などと訳されるが、DNSサーバで同じホスト名を持つ複数のIPアドレスを登録しておくことで、問い合わせには順に（あるいはランダムに）それぞれのIPアドレスを回答する。

図9　ラウンド・ロビンによる振り分けの例

　こうすることで、Webサーバへのアクセスなどを複数のホストに簡易に分散することができる。負荷分散手法としてはDNSサーバ側の対応だけなので、非常に容易に導入できるのがメリットだ。多くのDNSサーバでは、単に同じホスト名のAレコードを登録するだけでラウンド・ロビン機能を適用してくれる。だがあくまで簡易機能であるので、もし厳密なマシン負荷などを考慮した負荷分散を行いたいのなら、Web専用の負荷分散装置の導入を検討した方がよい。

　なお、メール・サーバの負荷分散のためには、一般的には本連載の第1回「DNSの仕組みの基本を理解しよう」で説明した複数のMXレコードの登録を行う方が一般的だ。ただしその場合は、メール・アドレスの右辺がドメイン名だった場合に限られる。右辺がホスト名の場合には、対処できないことになる。DNSラウンド・ロビン機能を用いるか、ホスト名での運用をドメイン名によるものに移行して、複数のMXレコードによる分散を行うほうがよいだろう。

●DNSリレー

　最近のブロードバンド・ルータなどでよく見かける機能で、外部（WAN側）のDNSサーバ（フルサービス・リゾルバ）と内部のDNSクライアントとの仲介を行う。一般には「スレーブ・サーバ」と同等の機能を提供する。

　内部のDNSクライアント（PCなど）では、このルータ自身を「DNSサーバ」として指定すれば、ルータからフルサービス・リゾルバへ問い合わせた結果をそのまま返してくれる。こうした代理機能の面から「Proxy DNS」などとも呼ばれる。この機能をルータが提供することで、DNSパケットのルーティングを禁止でき、セキュリティ・レベルを向上することができる。

　DNSはまさしくインターネットのベース・サービスだ。いうなれば、インターネットの「羅針盤」である。これなくして、メールもWebもこれだけの広がりは見せなかったはずだ。またドメイン名紛争にも見られるように、先端的なインターネット・サービスの常に矢面にも立たされることになる。今後も新たなTLD、多言語ドメインの出現やIPv6への移行など、DNSの先行きは決して簡単なものではないだろう。

　また同時に、ベース・サービスであるがゆえに、さまざまなインターネット技術とも連携し、それぞれ違った側面を見せることにも気付いていただけただろうか。ぜひともうまく使いこなして、「名船頭」として読者が活躍されることをお祈りしている。

「DNSの仕組みと運用」バックナンバー