DNS64 は、IPv4アドレスしか持たない宛先について、NAT64 用のIPv6アドレス（AAAAレコード）を合成して返すDNSの機能です。DNS64 だけでは通信できず、合成したアドレスを実際にIPv4へ変換する NAT64 とセットで動かすことが前提になります。この記事では、仕組みの要点、BIND・Unbound・AWS での設定例、動作確認の方法、導入時に起きやすい問題を説明します。
DNS64 とNAT64の役割
IPv6だけを持つサーバー（IPv6シングルスタック）から、IPv4しか持たない外部サービスに接続したい場面を考えます。たとえば WordPress を IPv6専用のサブネットに置いたとき、プラグインの更新や外部API呼び出しの接続先がIPv4だけだと、そのままでは通信できません。
ここで次の2つが協力します。
- DNS64: 接続先のAAAAレコードが存在しない場合、Aレコードの値（IPv4アドレス）を NAT64 プレフィックスの中に埋め込み、合成したAAAAとして返します。標準のプレフィックスは
64:ff9b::/96で、192.0.2.1は64:ff9b::c000:201になります。 - NAT64:
64:ff9b::/96宛てのIPv6パケットを受け取り、埋め込まれたIPv4アドレスに向けて変換して送り出します。
つまり、DNS64 は「宛先を教える係」、NAT64 は「実際に運ぶ係」です。DNS64 を設定してもNAT64へのルートがなければ、名前解決は成功するのに接続はタイムアウトする、という状態になります。
設定前に決めること
使うプレフィックス
多くの環境では標準の 64:ff9b::/96 を使います。独自のプレフィックス（ネットワーク固有プレフィックス）を使う場合は、DNS64 と NAT64 の両方で同じ値を設定します。標準プレフィックスはグローバルなIPv4アドレスの表現に使うものとされているため、社内のプライベートIPv4アドレスを合成の対象にしない設定にしておきます。
DNS64 を使うクライアントの範囲
DNS64 の結果は、デュアルスタック（IPv4とIPv6の両方を持つ）の端末にとっては遠回りになります。IPv4で直接つながる宛先まで NAT64 経由になってしまうためです。DNS64 のリゾルバーは、IPv6専用のネットワークのクライアントだけが使うように範囲を絞ります。
BIND での設定例
BIND では options に dns64 ブロックを書きます。設定を変更する前に、現在の named.conf を控えておいてください。
options {
// 既存の設定はそのまま
dns64 64:ff9b::/96 {
clients { 2001:db8:100::/48; };
mapped { !10.0.0.0/8; !172.16.0.0/12; !192.168.0.0/16; any; };
exclude { ::ffff:0:0/96; };
};
};clients は DNS64 を適用する問い合わせ元、mapped は合成の対象にするIPv4アドレス、exclude は「このAAAAが返ってきても無視して合成する」範囲です。IPv6アドレスのブロック 2001:db8:100::/48 は例なので、実際のIPv6専用サブネットに置き換えます。
sudo named-checkconf
sudo systemctl reload namednamed-checkconf が何も出力しなければ構文は正しく読み込めています。
Unbound での設定例
Unbound では、モジュールの並びに dns64 を加え、プレフィックスを指定します。
server:
module-config: "dns64 validator iterator"
dns64-prefix: 64:ff9b::/96module-config の順番は意味を持ちます。dns64 を先頭に置く書き方が Unbound の説明書きに沿った形です。変更後は unbound-checkconf で確認してから再起動します。
sudo unbound-checkconf
sudo systemctl restart unboundAWS での設定例
AWS の VPC では、サブネット単位で DNS64 を有効にでき、NAT64 は NAT ゲートウェイが担います（2026年10月現在の機能です。対応リージョンや細かな条件は AWS のドキュメントで確認してください）。
# サブネットで DNS64 を有効にする
aws ec2 modify-subnet-attribute --subnet-id subnet-0123456789abcdef0 --enable-dns64
# 64:ff9b::/96 宛てを NAT ゲートウェイへ向けるルートを追加する
aws ec2 create-route --route-table-id rtb-0123456789abcdef0 \
--destination-ipv6-cidr-block 64:ff9b::/96 \
--nat-gateway-id nat-0123456789abcdef0NATゲートウェイは、IPv4のインターネット接続を持つパブリックサブネットに置く必要があります。セキュリティグループやネットワークACLで、64:ff9b::/96 宛ての送信と戻りの通信を止めていないかも確認します。
動作確認の方法
合成されたAAAAが返るか
ipv4only.arpa は、DNS64 の確認用に用意されたIPv4専用の名前です。DNS64 が動いていれば、プレフィックスに 192.0.0.170 と 192.0.0.171 を埋め込んだアドレスが返ります。
dig AAAA ipv4only.arpa @（DNS64リゾルバーのアドレス） +short
# 64:ff9b::c000:aa
# 64:ff9b::c000:ab何も返らない場合は、問い合わせ元が clients の範囲に入っているか、リゾルバーの再読み込みが済んでいるかを確認します。
NAT64 を通って接続できるか
合成アドレスが返っても、通信できるかは別に確認します。IPv6専用のサーバーから次のように試します。
# IPv6で外部のIPv4サイトへ接続できるか
curl -6 -sI https://example.com/ | head -n 1
# 経路がNAT64に向いているか
ip -6 route get 64:ff9b::c000:201名前解決は成功するのに curl がタイムアウトするなら、NAT64 へのルート、NAT64 装置の状態、ファイアウォールの順に確認します。
導入時に起きやすい問題
IPv4アドレスを直接指定した通信は通らない: DNS64 は名前解決を通る通信にしか効きません。設定ファイルやアプリケーションにIPv4アドレスを直書きしている場合は、名前での指定に直すか、端末側でIPv4を扱える仕組み（464XLAT など）を検討します。
DNSSEC の検証と相性が悪い: 合成したAAAAには署名がありません。リゾルバー側の検証は DNS64 と両立するように作られていますが、端末自身が DNSSEC を検証する場合、合成された応答を拒否することがあります。こうした端末がある環境では動作を事前に確かめてください。
ログや制限でIPアドレスが変わって見える: NAT64 を通ると、接続先から見た送信元はNAT64装置のIPv4アドレスになります。外部APIでIP制限を使っている場合は、許可リストの登録先を見直します。
デュアルスタックの端末が遠回りになる: 先に述べたとおり、DNS64 を使う範囲を絞ることで避けられます。
まとめ
- DNS64 はAAAAを合成するだけで、通信の変換は NAT64 が行います。両方を同じプレフィックスで設定します。
- BIND は
dns64ブロック、Unbound はmodule-configとdns64-prefix、AWS はサブネットの DNS64 有効化と NAT ゲートウェイへのルートで設定します。 - DNS64 を使うクライアントはIPv6専用ネットワークに限り、プライベートIPv4を合成の対象から外します。
dig AAAA ipv4only.arpaで合成を、curl -6で実際の接続を、それぞれ分けて確認します。- IPv4アドレスの直書き、端末側の DNSSEC 検証、送信元IPの変化は、導入前に洗い出しておきます。