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

[鶴長鎮一，＠IT]

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）として公開されています。

ホスト名    IN    A6    Prefix長    Address    Prefix名

リスト1

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

pc1v6.example.jp.    IN    A6    64    ::3:4:fe8b:5d40     parent.example.com.

リスト2

　リスト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.を見つける過程を見てみましょう。

\[xFEC000000001000200030004FE8B5D40].ip6.arpa.を検索（1）

↓

\[xFEC0/16]    IN    DNAME    parent1.example.com.　（A）

↓

FEC0で前方一致した上記のレコード（A）を発見し、検索ドメインを\[x00000001000200030004FE8B5D40].parent1.example.com.に置換して検索を続行（2）

↓

\[x0000/16]    IN    DNAME    parent2.example.com.　（B）

0000が上位一致した上記のレコード（B）を発見し、検索ドメインを\[x0001000200030004FE8B5D40].parent2.example.com.に置換して検索を続行（3）

↓

………

↓

ドメイン\[x00030004FE8B5D40].example.jp.の検索（4）

↓

\[x00030004fe8b5d40/64].example.jp.    IN    PTR    pc1v6.example.jp.　（C）

\[x00030004FE8B5D40].example.jp.に一致したレコード（C）から「pc1v6.example.jp.」を導き出す（5）

IPアドレス「fec0:0:1:2:3:4:fe8b:5d40」の場合

　まず検索アドレスを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を使わないように指定することも可能です。

server IPアドレス {     edns no;　←デフォルトはyes };

named.conf

---

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

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

「次回」へ

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

• BIND 9を徹底活用するためのTips集
• DNSの拡張仕様、SRVレコードとENUM
• 次世代のセキュリティ拡張DNSSECをBIND 9で実現
• IPv6対応DNSサーバの実現
• BIND 9のチューニングと大規模運用
• BIND 9の運用情報収集と分析方法
• BIND 9のセキュリティ対策
• DHCPとDynamic DNSの連携システム
• Dynamic DNSの基礎とnsupdateコマンド
• サブドメインの運用と委任
• スレーブ・サーバのゾーン転送とセキュリティ
• キャッシュ／逆引きDNSの構築と運用
• メール／Webサーバを効率的に動かすゾーン設定
• すべての基礎、マスター・ゾーンサーバの設定
• BIND 9の改ざんチェックとインストール