IPv6 DNS：AAAAレコード、デュアルスタック解決、ベストプラクティス

DNSはIPv6の展開が成功するか失敗するかの鍵です。IPv6接続が機能する前にAAAAレコードを公開すると、ユーザーはタイムアウトを待つことになります。逆引きDNSをスキップすると、メールサーバーがトラフィックを拒否します。デュアルスタック解決を誤って設定すると、ネットワークが速くなるのではなく遅くなります。

このガイドでは、DNSがIPv6とどのように連携するか、何が壊れるか、問題になる前にそれを修正する方法について説明します。

TL;DR - 要点まとめ

重要ポイント：

AAAAレコードはAレコードのIPv6版（quad-A = 128ビットアドレス用の4つのA）
Happy Eyeballs（RFC 8305）はIPv6を先に試すが50-250ms以内にIPv4にフォールバック
DNS64はIPv6のみのネットワーク用にAレコードからAAAAレコードを合成するがDNSSECを破壊

ジャンプ： AAAAレコードで基本、デュアルスタック解決でパフォーマンス、またはよくあるミスでトラブルシューティング。

AAAAレコード：IPv6のAレコード相当 #

AAAAレコード（「quad-A」と発音）は、ホスト名をIPv6アドレスにマッピングします。これはAレコードのIPv6相当ですが、32ビットではなく128ビットアドレスを保持します。

形式と構造 #

example.com.    3600    IN    AAAA    2001:db8::1

構造はAレコードと一致します：名前、TTL、クラス、タイプ、アドレス。アドレスは、コロンと16進数を使用した標準IPv6表記を使用します。

各グループの先行ゼロは省略でき、連続するゼログループは::に折りたたむことができます。これらはどちらも有効で同一です：

example.com.    IN    AAAA    2001:0db8:0000:0000:0000:0000:0000:0001
example.com.    IN    AAAA    2001:db8::1

圧縮形式を使用してください。読みやすく、入力時のエラーも少なくなります。

AAAAレコードのクエリ #

AAAAレコードのクエリは、Aレコードのクエリと同じ方法で行い、タイプを指定するだけです。

digを使用：

dig AAAA example.com
dig AAAA @2001:4860:4860::8888 example.com

nslookupを使用：

nslookup -type=AAAA example.com
nslookup -type=AAAA example.com 2001:4860:4860::8888

hostを使用：

host -t AAAA example.com

DNSルックアップツールを使用して、AレコードとAAAAレコードを同時にクエリし、結果を比較することもできます。

AAAAとAレコードの比較 #

どちらも同じ目的を果たします——名前をアドレスに変換します——が、重要な点で異なります：

機能	Aレコード	AAAAレコード
アドレス長	32ビット	128ビット
アドレス形式	ドット10進数（192.0.2.1）	コロン16進数（2001:db8::1）
レコードタイプ	1	28
クエリサイズ	小さい	大きい（UDPフラグメンテーションに影響）
キャッシュ動作	独立したTTL	独立したTTL

AレコードとAAAAレコードは完全に独立しています。異なるTTLを持つことができ、異なるサーバーを指すことができ、または他方なしで存在できます。この柔軟性は便利ですが、誤設定の機会を生み出します。

公開前にテスト

サービスが実際にIPv6経由で到達可能な場合にのみAAAAレコードを公開してください。壊れたAAAAレコードを公開すると、クライアントが最初にIPv6を試み、IPv4にフォールバックする前にタイムアウトを待つため、接続遅延が発生します。

デュアルスタックDNS解決 #

ほとんどのネットワークはデュアルスタックで実行されます：IPv4とIPv6が同時に機能します。クライアントがホスト名を検索すると、AレコードとAAAAレコードの両方を受け取ります。次にオペレーティングシステムがどちらを使用するかを決定します。

Happy Eyeballs（RFC 8305）#

最新のオペレーティングシステムは、IPv4とIPv6の両方を試行するがIPv6が機能する場合はそれを優先するHappy Eyeballsアルゴリズムを実装しています。アルゴリズムは次のとおりです：

AレコードとAAAAレコードの両方についてDNSをクエリ
最初にIPv6アドレスへの接続を開始
50-250ms待機（実装による）
IPv6がまだ接続されていない場合、IPv4接続を並行して開始
最初に完了した接続を使用

このアプローチは、パフォーマンスと信頼性のバランスを取ります。IPv6が優先されますが、壊れたIPv6は長時間接続を停止しません。

解決順序 #

クライアントがレコードをクエリし、接続を試行する順序は、OSと設定によって異なります。

ほとんどのUnix/Linuxシステム：

AとAAAAを同時にクエリするか、AAAAを最初にクエリ
IPv6アドレスが存在する場合は優先
/etc/gai.conf（getaddrinfo設定）によって制御

macOS：

両方のレコードタイプを並行してクエリ
Happy Eyeballsを厳密に実装
利用可能な場合、IPv6を強く優先

Windows：

両方のレコードタイプをクエリ
デフォルトでIPv6を優先（レジストリで設定可能）
Windows 8からHappy Eyeballsを実装

ブラウザ：

ChromeとFirefoxは独自のHappy Eyeballsを実装
OSの動作のみに依存しない
解決結果を積極的にキャッシュする可能性がある

IPv6が勝つ（または負ける）とき #

IPv6は通常、次の場合に勝ちます：

IPv6接続がネイティブ（トンネルではない）
IPv6ルーティングが追加のホップなしで直接的
宛先がIPv6経由で適切に接続されている

IPv6は次の場合に負けます：

トンネル化されている（6to4、Teredo）追加の遅延がある
ルーティングがIPv4よりも長いパスを取る
サーバーのIPv6接続が不良
ファイアウォールまたはミドルボックスの問題により接続が遅くなる

FacebookのIPv6パフォーマンス

Facebookは、ネイティブIPv6接続を使用しているユーザーが、IPv4と比較して10〜15％速いページロードを経験していることを発見しました。パフォーマンスの向上は、ネットワークホップの削減、キャリアグレードNATなし、より直接的なルーティングから来ています。

デュアルスタック動作のテスト #

IPv4またはIPv6を強制して動作をテスト：

# IPv4を強制
curl -4 https://example.com
 
# IPv6を強制
curl -6 https://example.com
 
# OSに選択させる
curl https://example.com

応答時間を比較します。IPv6が大幅に遅い場合は、AAAAレコードを広く公開する前に、ルーティングまたは接続の問題を調査してください。

DNS64とNAT64 #

DNS64は、AレコードからAAAAレコードを合成し、IPv6のみのネットワークがIPv4のみのサービスにアクセスできるようにします。これは、IPv6とIPv4の間でパケットを変換するNAT64と組み合わせて使用されます。

DNS64の仕組み #

IPv6のみのクライアントがホスト名をクエリすると：

DNS64サーバーがクエリを受信
AAAAレコードをチェック
AAAAが存在する場合、通常どおり返す
Aレコードのみが存在する場合、特別なプレフィックスを使用してAAAAレコードを合成
クライアントが合成されたIPv6アドレスに接続
NAT64ゲートウェイが接続をIPv4に変換

既知のプレフィックス：64:ff9b::/96 #

最も一般的なDNS64プレフィックスは、RFC 6052で定義されている64:ff9b::/96です。アドレスの最後の32ビットはIPv4アドレスを埋め込みます。

合成の例：

Aレコード：    192.0.2.1
プレフィックス：  64:ff9b::/96
AAAAレコード：  64:ff9b::192.0.2.1
              または64:ff9b::c000:201（16進数）

一部のネットワークは、2001:db8::/96やカスタム範囲などの他のプレフィックスを使用します。プレフィックスは、DNS64とNAT64の両方で一貫して設定する必要があります。

DNS64/NAT64が必要な場合 #

DNS64は次の場合に不可欠です：

IPv6のみのモバイルネットワーク（T-Mobile、AT&Tで一般的）
レガシーIPv4サービスにアクセスするIPv6のみのデータセンター
IPv6のみのクライアント動作のテスト

次の場合はDNS64は必要ありません：

ネットワークがデュアルスタック
アクセスするすべてのサービスがネイティブIPv6を持っている
すべてのバックエンドサービスでIPv6を義務付けることができる

制限と注意点 #

DNS64はいくつかのことを壊します：

DNSSEC検証が失敗する - 合成されたAAAAレコードは署名されたゾーンと一致しません。DNS64サーバーはDNSSEC署名を削除する必要があり、セキュリティが低下します。

IPアドレスを埋め込むアプリケーションが壊れる - アプリケーションがJSON、XML、または他のデータ形式でIPv4アドレスを受信する場合、DNS64はそれを変換しません。アプリはIPv6のみのスタックからIPv4アドレスに接続しようとして失敗します。

ロードバランサーとCDNが混乱する - DNS64により、すべてのクライアントがNAT64ゲートウェイのアドレスから来ているように見えます。ジオロケーション、レート制限、クライアント識別が壊れます。

参照とリダイレクトが失敗する - DNS応答が追加セクションにIPv4アドレスを含む場合（NSグルーレコードなど）、クライアントはそれらに到達できません。

DNS64なしでテスト

IPv6でネイティブに動作するようにサービスを設計してください。DNS64/NAT64は移行ツールであり、恒久的な解決策ではありません。遅延、複雑さを追加し、エッジケースを壊します。

逆引きDNS（PTRレコード）#

逆引きDNSは、IPv6アドレスをホスト名にマッピングします。接続には必須ではありませんが、メールサーバーには必要であり、ログ記録とセキュリティツールにも役立ちます。

ip6.arpaゾーン #

IPv6逆引きDNSはip6.arpaドメインを使用します。アドレスの各ニブル（4ビット、または1つの16進数）がドメイン名のラベルになり、逆順で書かれます。

アドレスをPTR形式に変換 #

完全な、圧縮されていないIPv6アドレスを取り、ニブルごとに逆にし、ip6.arpaを追加します。

例：2001:db8::1

ステップ1： 完全な形式に展開：

2001:0db8:0000:0000:0000:0000:0000:0001

ステップ2： すべてのニブルを書き出す：

2 0 0 1 0 d b 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1

ステップ3： 順序を逆にする：

1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 8 b d 0 1 0 0 2

ステップ4： ドットで区切り、ip6.arpaを追加：

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

これがPTRレコード名です。ホスト名を指します。

逆引きDNSのクエリ #

自動変換でdigを使用：

dig -x 2001:db8::1

PTRレコードを直接クエリ：

dig PTR 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

hostを使用：

host 2001:db8::1

逆引きDNSの委任 #

逆引きDNSゾーンは、ISPまたはRIRによって委任されます。/48を持っている場合、/48分の逆引きDNS空間を制御します。ほとんどのプロバイダーは、Webインターフェイスを通じて管理できるようにするか、逆引きゾーン用に独自のDNSサーバーを実行できるようにします。

より小さな割り当て（/64など）の場合、一部のISPは個々のPTRレコードを処理します。アドレスとホスト名を提供してください。

メールサーバーの逆引きDNS

メールサーバーは、スパムを減らすために逆引きDNSをチェックします。メールサーバーのIPv6アドレスにPTRレコードがない場合、または正引き検索と一致しない場合、多くのメールシステムはメッセージを拒否するか、スパムとしてスコア付けします。

IPv6の一般的なDNSミス #

機能するIPv6なしでAAAAを公開 #

これが第一のミスです。サーバーでIPv6を有効にし、AAAAレコードを作成し、機能すると仮定します。しかし、ファイアウォールがIPv6をブロックしているか、ルーティングが壊れているか、サーバーが実際にIPv6でリスニングしていない場合、クライアントはタイムアウトします。

症状： Webサイトの読み込みが遅い、特にIPv6を優先するモバイルネットワークで。

修正： AAAAレコードを公開する前に、複数の外部IPv6ネットワークから接続性をテストします。Pingツールを使用して到達可能性を確認します。

逆引きDNSを忘れる #

正引きDNSは正常に機能しますが、逆引きDNSをスキップします。これによりメール配信が壊れ、ログ分析が混乱し、プロフェッショナルではありません。

症状： メール拒否、「逆引きDNS検索失敗」エラー。

修正： すべてのサーバーアドレスにPTRレコードを設定します。複数の場所からdig -xで確認します。

AとAAAA間のTTL不一致 #

Aレコードに3600秒のTTLがありますが、AAAAに300があります。DNSを更新すると、クライアントは何時間も不一致な結果を取得します。

症状： 一部のクライアントは古いアドレスに解決し、他のクライアントは新しいアドレスに解決します。トラブルシューティングが困難。

修正： AレコードとAAAAレコードのTTLを一致させます。それらは同一である必要があります。変更を行う前に両方を下げ、その後再び上げます。

IPv6経由のDNSをブロックするファイアウォール #

DNSサーバーにIPv6アドレスとAAAAレコードがありますが、ファイアウォールがIPv6経由のUDPおよびTCPポート53をブロックしています。クライアントはそれをクエリできません。

症状： IPv6のみのクライアントまたはネットワークからのDNSクエリが失敗する。

修正： IPv4とIPv6の両方でUDPとTCPポート53を許可します。IPv6のみのホストからテストします。TCP経由のDNSは必須であり、オプションではないことを覚えておいてください。

不完全なデュアルスタック設定 #

WebサイトのAAAAレコードを設定しましたが、CDN、メールサーバー、またはAPIエンドポイントには設定していません。ユーザーは混合結果を取得します。

症状： メインサイトはIPv6経由で機能しますが、埋め込みコンテンツ、API呼び出し、またはメールはIPv4にフォールバックし、パフォーマンスの利点が失われます。

修正： フロントエンドだけでなく、チェーン内のすべてのサービスでIPv6を有効にします。IPv6のみのクライアントから完全なワークフローをテストします。

設定ファイルのハードコードされたIPv4アドレス #

DNSは正常に解決しますが、アプリケーション設定ファイルにハードコードされたIPv4アドレスが含まれています。IPv6のみのクライアントが接続しようとすると、サービスが壊れます。

症状： IPv6のみのネットワークでアプリケーションが接続エラーで失敗する。

修正： 設定ファイルでIPアドレスではなくホスト名を使用します。DNSが適切なアドレスファミリに解決するようにします。

ベストプラクティス #

公開前に徹底的にテスト #

本番DNSにAAAAレコードを追加する前に：

サービスがIPv6でリスニングしていることを確認：netstat -an | grep :80（またはポート）
外部IPv6アドレスからテスト：curl -6 https://[2001:db8::1]/
ファイアウォールルールがIPv6トラフィックを許可することを確認
traceroute6でルーティングが正しいことを確認
複数のIPv6ネットワーク（モバイル、ブロードバンド、データセンター）からテスト

OSにIPv6アドレスがあるからといって機能すると仮定しないでください。

AレコードとAAAAレコードのTTLを一致させる #

同一のTTLを設定します。これにより、キャッシュ動作が一貫し、DNS更新が簡素化されます。

example.com.    3600    IN    A       192.0.2.1
example.com.    3600    IN    AAAA    2001:db8::1

アドレスを変更する必要がある場合は、変更の24〜48時間前にTTLを下げ、更新を行い、その後再び上げます。

逆引きDNSを設定 #

すべての公開ルーティング可能なIPv6アドレスにPTRレコードを設定します。メールサーバーには必須であり、他のすべてに役立ちます。

ISPまたはRIRと協力して逆引きゾーンを委任します。PTRレコードを正引きDNSと同期させます——それらは一致する必要があります。

両方のプロトコルを監視 #

AレコードとAAAAレコードのDNSクエリ量、応答時間、エラー率を個別に追跡します。IPv4とIPv6トランスポートの両方での解決を監視します。

次のアラートを設定：

Aクエリが成功するときにAAAAクエリが失敗
IPv4とIPv6間の応答時間の違い
IPv6クエリ量の突然の減少

個別の監視は、ユーザーが不満を言う前に問題をキャッチします。

IPv6対応DNSサーバーを使用 #

DNSサーバーは、IPv4とIPv6の両方でクエリに応答する必要があります。ネットワークがまだ完全にデュアルスタックでない場合でも、両方のアドレスファミリを設定します。

IPv6のみのクライアントからテストします。驚くほど多くのDNSサーバーがAAAAレコードを持っていますが、実際にはIPv6経由でクエリを受け入れません。

DNSSECを慎重に実装 #

DNSSECはIPv6で機能しますが、DNS64はそれを壊します。ネットワークでDNS64を使用している場合、合成されたレコードでDNSSECを検証できません。

本番展開の場合、ネイティブデュアルスタックを設計し、可能な限りDNS64を避けてください。

よくある質問 #

デュアルスタックサービスにはAレコードとAAAAレコードの両方が必要ですか？

はい。デュアルスタックサービスには両方のレコードタイプを公開します。IPv6をサポートするクライアントはAAAAを使用し、IPv4のみのクライアントはAを使用します。サービスが実際にIPv6経由で機能しない限り、AAAAを公開しないでください——壊れたAAAAレコードはタイムアウト遅延を引き起こします。

IPv4とIPv6に異なるサーバーを使用できますか？

はい。AレコードとAAAAレコードは独立しており、異なるサーバーを指すことができます。これは、段階的なIPv6展開や、プロトコルごとに異なる方法でトラフィックをルーティングしたい場合に便利です。両方のサーバーが同一のコンテンツと機能を提供することを確認してください。

なぜ私のWebサイトはモバイルでは遅いのにWiFiでは速いのですか？

モバイルネットワークはしばしばIPv6を優先または要求します。AAAAレコードが存在するがIPv6接続が壊れているか遅い場合、モバイルユーザーはタイムアウトを待つか、高い遅延を経験します。複数のモバイルキャリアからIPv6経由でサイトをテストしてください。IPv6が適切に機能しない場合は、AAAAレコードを削除してください。

すべてに逆引きDNSが必要ですか？

逆引きDNSはメールサーバーには必須であり、すべての公開サーバーに強く推奨されます。クライアントアドレスや内部サーバーには必要ありませんが、トラブルシューティング、ログ記録、セキュリティ分析に役立ちます。

DNS64が機能しているかどうかをテストする方法は？

IPv6のみのクライアントからIPv4のみのホスト名をクエリします。DNS64が機能している場合、設定されたプレフィックス（通常は64:ff9b::/96）を使用して合成されたAAAAレコードを受け取ります。dig AAAA ipv4only.arpaをテストとして使用します——これはDNS64テスト用に設計されたIPv4のみのドメインです。