ルートドメイン（example.com そのもの）をCDNやロードバランサーに向けるためにALIASレコードを使っている場合、IPv6のAAAAは「自分で書く」ものではなく、多くの場合ALIASが向け先から取ってきて返すものです。同じ名前にALIASと手書きのAAAAを並べると、IPv6の利用者だけ別の宛先につながる原因になります。この記事では、ALIASがAAAAをどう扱うかの仕組み、DNSサービスごとの違い、目的別の正しい設定、設定後の確認方法を説明します。
ALIASがAAAAをどう返すか
ルートドメインには、SOAやNSがあるためCNAMEを置けません。そこで多くのDNSサービスは、ALIAS、ANAME、CNAMEフラット化、エイリアスレコードといった独自の仕組みを用意しています。名前は違っても基本の動きは同じで、DNSサービスが向け先のホスト名を引き、その結果のアドレスをルートドメインのAやAAAAとして答えます。
ALIASはDNSの標準のレコード型ではなく、利用者が受け取るのは普通のAやAAAAです。そのため、ルートドメインにIPv6のアドレスが返るかどうかは次の2点で決まります。
- 使っているDNSサービスが、ALIASからAAAAも作って返す仕組みになっているか
- 向け先のホスト名に、AAAAが登録されているか
どちらかが欠けると、ルートドメインにはAAAAが返りません。逆に両方そろっていれば、AAAAを手で追加しなくてもIPv6に対応します。
DNSサービスごとの違い
細かい挙動や画面の表記はサービスごとに違い、変わることもあります（2026年10月現在）。設定前に各サービスの公式ドキュメントを確認してください。
Route 53 のエイリアスレコード
Route 53 では、エイリアスをレコードの種類ごとに作ります。IPv4用にAのエイリアス、IPv6用にAAAAのエイリアスを、同じ向け先に対して別々に作るのが基本です。Aのエイリアスだけ作った場合、ルートドメインはIPv6に対応しません。
向け先がIPv6に対応しているかも確かめます。CloudFront ならディストリビューションでIPv6が有効になっていること、Application Load Balancer ならIPアドレスの種類がデュアルスタックになっていることが前提です。エイリアスレコードのTTLは自分で設定できず、向け先側の値が使われます。
Cloudflare のCNAMEフラット化
Cloudflare では、ルートドメインにCNAMEを登録すると自動でフラット化され、向け先のAとAAAAが返ります。プロキシを有効にしたレコードでは、返るのは Cloudflare 側のアドレスになり、IPv6のアドレスも Cloudflare が用意します。この場合、元サーバーがIPv6に対応していなくても、利用者とCloudflare の間はIPv6で接続できます。
そのほかのALIAS・ANAME
ALIASやANAMEを提供する多くのDNSサービスは、向け先のAとAAAAの両方を引いて返します。ただし、AAAAを返さない設定やプランがあるサービスもあり得るため、後述の確認手順で実際の応答を見て判断します。
目的別の設定
作業の前に、DNSの管理画面のエクスポートやゾーンファイルのコピーを取っておきます。
ルートドメインをIPv6にも対応させたい
向け先がIPv6に対応しているかを先に確かめます。
dig +short cdn-target.example.net AAAAアドレスが返れば、ALIASだけで足ります（Route 53 ならAAAAのエイリアスも追加）。返らない場合は、向け先のサービス側でIPv6を有効にするのが正しい直し方です。ルートドメインに手書きのAAAAを足して補うのは避けます。手書きのAAAAは向け先のアドレスが変わっても追従しないため、いずれ古いアドレスを指したままになります。
移行前の手書きAAAAが残っている
CDNやロードバランサーに移行したときに、もとのサーバーを指していたAAAAを消し忘れるのが、もっとも多い失敗です。この状態では、IPv4の利用者はALIAS経由でCDNに、IPv6の利用者は手書きのAAAAで元サーバーに直接つながります。キャッシュが効かず、WAFも通らず、元サーバーを廃止した時点でIPv6の利用者だけ表示できなくなります。
DNSサービスによっては、同じ名前にALIASとAAAAを並べること自体を拒否しますが、受け付けてしまう画面もあります。ルートドメインのレコード一覧を見て、ALIASと同じ名前にあるAとAAAAは削除します。
ルートドメインはIPv4だけにしたい
元サーバーへの直接の接続が残る構成で、IPv6の設定をまだ整えていない場合などです。ALIASが向け先のAAAAを自動で返す仕組みでは、AAAAだけを止められないことがあります。その場合は、向け先のサービス側でIPv6を無効にするか、ALIASをやめてAレコードで直接指定するかを選びます。ただし、CDNの多くはIPv6で問題なく動くため、IPv6を止める理由が本当にあるかを先に見直すのが近道です。
wwwとそろえる
www.example.com は通常のCNAMEで向け先に向けられます。ルートドメインとwwwが同じ向け先なら、両方で同じAAAAが返るはずです。片方だけIPv6に対応している状態は、リダイレクトの途中でつながり方が変わる原因になるため、そろえておきます。
設定後の確認
DNSの応答を比べる
ルートドメインと向け先のそれぞれで、AとAAAAを問い合わせます。
dig +noall +answer example.com A
dig +noall +answer example.com AAAA
dig +noall +answer cdn-target.example.net AAAAルートドメインのAAAAが向け先のAAAAと同じ系統のアドレスになっていれば、ALIASがAAAAを返しています。CDNは問い合わせ元の地域によって違うアドレスを返すことがあるため、アドレスが一字一句同じでなくても、同じCDNのアドレス帯であれば問題ありません。ルートドメインにだけ見慣れないアドレスがある場合は、手書きのAAAAが残っています。
権威DNSに直接問い合わせると、キャッシュの影響を除いて今の設定を確認できます。
dig +short NS example.com
dig @ns1.example.net +norecurse +noall +answer example.com AAAAIPv6で実際につながるかを確かめる
DNSが正しくても、向け先がIPv6で正しく応答するかは別に確かめます。IPv6が使えるサーバーや回線から実行します。
curl -6 -sI https://example.com/ | head -n 5
curl -4 -sI https://example.com/ | head -n 5両方で同じCDNやロードバランサーの応答ヘッダーが返れば、IPv4とIPv6で同じ経路を通っています。
WordPressサイトでの注意
WordPressの「サイトアドレス」がルートドメインの場合、IPv6の利用者が元サーバーに直接つながると、キャッシュ系プラグインやCDNの設定と食い違った表示になることがあります。また、Let's Encrypt のHTTP検証はAAAAがあるとIPv6を優先して使うため、手書きのAAAAが古いサーバーを指していると、証明書の発行や更新が失敗する原因になります。ALIASに切り替えたら、証明書の更新が通るかも certbot renew --dry-run などで確かめておきます。
まとめ
- ALIASを使うルートドメインのAAAAは、DNSサービスが向け先から作って返すのが基本
- IPv6に対応させるには、DNSサービスの対応と、向け先のAAAAの両方が必要
- Route 53 ではAとAAAAのエイリアスを別々に作る
- 移行前の手書きAAAAが残ると、IPv6の利用者だけ元サーバーに直接つながる
- 設定後は、ルートドメインと向け先の
dig結果を比べ、curl -6で実際の接続を確かめる