検索
連載

IPv6対応DNSサーバの実現：実用 BIND 9で作るDNSサーバ（12）（2/2 ページ）

BIND 9でIPv6対応DNSサーバを立ち上げる際に、どのような設定が必要なのか？ アドレスの記述方法から正引き／逆引きの設定までを分かりやすく解説する。（編集局）

Share
Tweet
LINE
Hatena
前のページへ | 　　　　　　

A6レコードとDNAMEレコード

　AAAAやPTRレコードの使用で、既存のDNSに大きな拡張を加えなくとも、比較的容易にIPv6環境へ移行できることが期待できます。しかしその一方で、IPv6のメリットであるアドレス自動構成機能が生かされていません。例えば、AAAAレコードではIPアドレスの指定を128bitで記述しますが、仮に上位ネットワークに変更が加わるとネットワークプレフィックスも変更となり、AAAAリソースすべてを変更する手間が発生します。

　そこで128bitのIPアドレスを適当な個所で分割し、下位64bitのインターフェイスIDだけのリソースレコードと、ネットワークプレフィックスだけのリソースレコードを別々に管理する方式が検討されました。その結果、A6／DNAMEレコードを用いる手法が提案され、RFC 2874（http://www.rfc-editor.org/rfc/rfc2874.txt）／RFC 2672（http://www.rfc-editor.org/rfc/rfc2672.txt）として公開されています。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

　RFC 2874では、正引きに対するリソースをA6レコードで管理する手法が記載されています。A6レコードはリスト1のような書式で使用し、端末構成はリスト2のようになります。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

　リスト2の下位64bitが「3:4:fe8b:5d40」であり、それより上位はparent.example.com.のA6レコードを参照します。ネットワークプレフィックス部位とネットワークインターフェイス部位に分割して、ネットワーク構成がダイナミックに変更されることがあっても、DNSへの修正が最小限で完了するというわけです。

　正引きのA6レコードに対し、逆引きにはDNAMEレコードを使用します。IPアドレスfec0:0:1:2:3:4:fe8b:5d40からpc1v6.example.jp.を見つける過程を見てみましょう。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

　まず検索アドレスをBitstring Formatで用意し、「ip6.arpa.」ドメインを末尾に付加します（1）。（A）のようなレコードを見つけ、検索ドメインを（2）に置き換えます。この際、前方一致した「FEC0」を削り、末尾の「ip6.arpa.」ドメインの代わりに「parent1.example.com.」ドメインを付加します。

　以下同じように前方一致するレコードを検索し、見つけたレコードを基に検索ドメインの前方を削り、後方に新しいドメインを付加していきます。これを繰り返して（4）のような検索ドメインを経て、最終的に（C）レコードにたどり着き、ドメイン「pc1v6.example.jp.」を得ます。

　（A）、（B）のレコードはルートサーバやネットワーク事業者で管理され、末端のサイトは（C）のようなレコードを持つことになります。これにより、ネットワークプレフィックスが変わることがあっても、修正は最小限になります。

　A6、DNAMEともにIPv6のメリットを取り込んだ画期的な手法ではありますが、1つのアドレス解決のために発生するDNS問い合わせの回数が多くなります。また、問い合わせ回数が多くなることで、ミスキャッシュによる問い合わせ失敗の確率も高くなることが懸念されます。Bitstring Formatを使用していることからも分かるとおり、現在のところA6／DNAMEを使った手法はexperimental（実験）とされており、よりシンプルなAAAAを使うことが推奨されています。

参考：
Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)
ftp://ftp.rfc-editor.org/in-notes/rfc3364.txt
JPNIC News & Views vol.1「第51回IETF Meeting」
http://www.nic.ad.jp/ja/mailmagazine/backnumber/2001/vol001.html

EDNS0対応

　DNS問い合わせに使用するUDPパケットは、メッセージのサイズが512bytesに制限されています。アドレス長が4倍になるIPv6アドレスを扱うようになれば、その制限を超えてしまうことは容易に想像できます。

　BIND 9のいままでの実装どおりTCPに切り替える方法も検討されていますが、IPv6を扱う際はEDNS0を使用することで、より大きなサイズのUDPパケットを扱うようにしています。EDNS0を使用する場合、クライアント側が「OPT RR」で受信可能なバッファ長をDNS問い合わせパケットに埋め込みます。クエリーを受け取ったサーバは、クライアントの要求に応じて512bytesを超えたUDPパケットを生成します。

　BIND 9はゾーンサーバおよびキャッシュサーバとしてEDNS0に対応しています。BIND 9によるキャッシュサーバは、再帰問い合わせの過程で発生したエラーを基に、対象のDNSサーバがEDNS0に対応しているかどうかもキャッシュします。またnamed.confで、サーバごとにEDNS0を使わないように指定することも可能です。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

　今回は、BIND 9のIPv6対応について紹介しました。基盤技術が成熟されていても、運用方法が確定していないために、今後も新たな方式が登場しては廃止される可能性も否めません。いったんは推奨されたAAAAも、またA6に取って代わられないとも限らないのです。

　しかし、多くの可能性とそれがもたらす飛躍を含んだIPv6がインターネットの基盤になる日も間近です。IPv6運用エンジニアが希少ないまだからこそ、学び始めるには絶好の機会といえるでしょう。

「次回」へ


「実用 BIND 9で作るDNSサーバ」バックナンバー

Copyright © ITmedia, Inc. All Rights Reserved.

前のページへ | 　　　　　　
ページトップに戻る