2026年6月8日

AAAAレコードを検証する方法｜DNSの応答からIPv6での接続・HTTPSまで順に確かめる

DNS・名前解決

AAAAレコードの検証は、「DNSが正しいIPv6アドレスを返しているか」と「そのアドレスで実際にサイトが表示できるか」の2つに分けて確かめるのが近道です。この記事では、権威DNSサーバーへの問い合わせから、サーバー側のアドレスとの照合、IPv6での接続、HTTPSとWordPressの応答までを順に検証する手順を説明します。手元にIPv6回線が無い場合の確かめ方にも触れます。

なぜAAAAレコードは検証が必要なのか

AAAAレコードに誤りがあっても、多くの利用者は気付きません。最近のブラウザやOSは、IPv6とIPv4の両方に同時に近い形で接続を試し、早くつながった方を使う仕組み（Happy Eyeballs）を備えています。IPv6側がつながらなくても、少し遅れてIPv4で表示されるため、「なんとなく表示が遅い」程度で済んでしまうのです。

一方で、IPv6だけで接続する環境や、IPv6を優先する仕組みでは問題が表に出ます。たとえば、IPv6のみのモバイル回線の一部や、証明書の発行時にドメインへアクセスしてくる認証局の検証、外部の監視サービスなどです。「自分のパソコンでは表示される」は検証になりません。以下の4段階を順に確かめてください。

権威DNSサーバーが意図したAAAAを返しているか
その値がサーバーに実際に割り当てられたIPv6アドレスと一致するか
そのアドレスに、IPv6で接続できるか
HTTPSの証明書とWordPressの応答が、IPv4のときと同じか

手順1：権威DNSサーバーが返すAAAAを確かめる

最初に、ドメインのネームサーバー（NS）を調べ、そのサーバーに直接問い合わせます。キャッシュDNS（プロバイダや公開DNS）を経由すると、古い値が返ってくることがあるため、「今の設定」を見るには権威サーバーへ聞くのが確かです。

# ドメインのネームサーバーを調べる
dig NS example.com +short

# 表示されたネームサーバーに直接問い合わせる（+norecurse で再帰を求めない）
dig @ns1.example-dns.net example.com AAAA +norecurse +noall +answer
dig @ns1.example-dns.net www.example.com AAAA +norecurse +noall +answer

応答の行は「名前・TTL・クラス・タイプ・値」の順に並びます。ここで確かめるのは次の点です。

値が、登録したつもりのIPv6アドレスと1文字も違わないか。IPv6は「::」で0の連続を省略できるため、見た目が違っても同じアドレスのことがあります。逆に、似て見えても末尾の数字が違う、ということもあります。
example.com と www.example.com の両方を確かめたか。片方だけAAAAがある、片方が古いアドレスのまま、という状態はよくあります。
ネームサーバーが複数ある場合、すべてが同じ値を返すか。

次に、利用者側から見える値も確かめます。公開DNSに聞くと、キャッシュ込みの応答になります。

dig @1.1.1.1 example.com AAAA +short
dig @8.8.8.8 example.com AAAA +short

権威サーバーと公開DNSで値が違う場合は、キャッシュが残っている途中です。TTLの秒数が経てば入れ替わるので、この段階では「権威サーバーの値が正しい」ことを確かめられれば先へ進めます。

手順2：サーバーのIPv6アドレスと照合する

DNSの値が意図どおりでも、その「意図」自体が間違っていることがあります。サーバーにログインし、実際に割り当てられているグローバルなIPv6アドレスと照合してください。

# サーバーに割り当てられたグローバルIPv6アドレスを表示する
ip -6 addr show scope global

# Webサーバーが IPv6 で 80/443 番を待ち受けているかを見る
sudo ss -ltnp | grep -E ':(80|443)\b'

ss の出力で、[::]:443 やIPv6アドレスでの待ち受けが見えれば、IPv6でも受け付けています。0.0.0.0:443 しか無い場合は、IPv4だけで待ち受けています。nginxであれば listen [::]:443 ssl; のようなIPv6向けの指定がサーバーブロックにあるかを見直します。

照合でよくあるずれは次のとおりです。

サーバー移転後に、旧サーバーのIPv6アドレスがAAAAに残っている
VPSのIPv6アドレスの範囲（プレフィックス）の中から、サーバーに設定していないアドレスをAAAAに書いている
fe80:: で始まるリンクローカルアドレスを登録している（これは外部から届きません）

手順3：IPv6で実際に接続できるか確かめる

アドレスが一致したら、外からIPv6で接続できるかを確かめます。手元にIPv6回線がある場合は、curl で接続先をIPv6に限定するのが簡単です。

# IPv6に限定して接続し、ステータスコードと接続先IPを表示する
curl -6 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.com/

# DNSを経由せず、特定のIPv6アドレスに名前を当てて確かめる
curl -sS -o /dev/null -w '%{http_code}\n' \
  --resolve 'example.com:443:[2001:db8::10]' https://example.com/

--resolve を使うと、DNSの反映を待たずに「そのアドレスで正しく応答するか」を先に確かめられます。応答が返らずタイムアウトする場合は、サーバーのファイアウォール（ip6tables や nftables、クラウドのセキュリティグループ）でIPv6の80/443番が許可されていない可能性が高いです。IPv4のルールだけを開けて、IPv6のルールを忘れている例は少なくありません。

手元にIPv6回線が無い場合は、IPv6が使えるVPSやクラウドの仮想マシンから同じコマンドを実行するか、IPv6での接続を外部から試せるチェックサービスを使います。このとき、自分の環境からIPv6に届かないことを「サイトの不具合」と取り違えないよう、curl -6 https://www.google.com/ のように、IPv6対応が分かっているサイトにつながるかも先に見ておきます。

手順4：HTTPSとWordPressの応答を確かめる

IPv6でつながっても、IPv4と別のサーバーや別の設定に届いていては意味がありません。証明書とページの中身まで見比べます。

# IPv6アドレスに接続して、提示される証明書の名前と有効期限を見る
openssl s_client -connect '[2001:db8::10]:443' -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -enddate

# IPv4とIPv6でレスポンスヘッダーを見比べる
curl -4 -sI https://example.com/ | head -n 5
curl -6 -sI https://example.com/ | head -n 5

証明書の名前がドメインと一致しているか、有効期限が切れていないか、IPv4で見たときと同じ証明書かを確かめます。IPv6側だけ古い証明書が出る場合は、IPv6の待ち受けが別の設定ファイル（デフォルトのサーバーブロックなど）に当たっていることが多いです。

WordPress側では、次の点も見ておくと安心です。

ログイン画面やフォームの送信がIPv6経由でも動くか
セキュリティ系プラグインやサーバーのアクセス制限で、IPアドレスによる許可・拒否を設定している場合、IPv6アドレスも対象に含めているか。IPv6で接続すると、WordPressから見える接続元（REMOTE_ADDR）はIPv6アドレスになります
アクセスログにIPv6の接続元が記録されているか（実際にIPv6の利用者が来ている証拠になります）

検証で見つかりやすい問題と直し方

検証で見つかる問題は、多くが次のどれかです。見つかった順に直し、もう一度手順1から確かめます。

AAAAの値が古い・間違っている：DNSサービスの管理画面で正しいアドレスに直します。変更前にTTLを短くしておくと、直した値が早く行き渡ります。
ファイアウォールでIPv6が閉じている：IPv6向けのルールで80/443番を許可します。クラウドの場合はセキュリティグループやネットワークACLのIPv6ルールも確かめます。
WebサーバーがIPv6で待ち受けていない：設定にIPv6の待ち受けを追加し、設定テストのあとで再読み込みします。
IPv6を正しく運用できる見込みが無い：無理に残すより、AAAAレコードを削除してIPv4だけで運用する方が利用者への影響は小さくなります。

DNSサービスの管理画面の項目名や、IPv6の提供状況はサービスごとに異なり、変わることもあります（2026年10月現在）。作業の前には、使っているDNSサービスとサーバー会社の最新のヘルプを確かめてください。設定を変える前には、現在のゾーンの内容を控えておくと戻すときに困りません。

まとめ

AAAAレコードの不具合は、Happy Eyeballs によってIPv4で救われ、気付かれにくいものです。手元で表示できることは検証になりません。
まず権威DNSサーバーに直接問い合わせ、example.com と www の両方で、意図した値が返るかを確かめます。
その値がサーバーに実際に割り当てられたグローバルIPv6アドレスと一致するか、Webサーバーが IPv6 で待ち受けているかを照合します。
curl -6 や --resolve でIPv6での接続を試し、証明書とレスポンスがIPv4と同じかを見比べます。
IPv6を運用できないなら、AAAAを削除してIPv4だけで運用するのも妥当な選択です。