AレコードのTTLは、「権威DNSが返す設定値」と「キャッシュDNSが持っている残り時間」を分けて確かめると正しく検証できます。管理画面の表示だけでは、変更が配信されているか、利用者側のキャッシュがいつ切れるかは分かりません。この記事では、dig を使って設定値と残りTTLを読み分ける方法、複数の権威DNSやCNAMEを経由する場合の確かめ方、サーバー移転の前に「下げたTTLが本当に効いているか」を判断する手順を説明します。
検証で見るべき2種類のTTL
TTL（Time To Live）は、キャッシュDNSがその答えを保持してよい秒数です。検証では次の2つを区別します。
- 設定値（権威DNSの値）: ゾーンに書かれた値です。権威DNSに直接問い合わせると、何度聞いても同じ数字が返ります
- 残りTTL（キャッシュDNSの値）: 公開DNSやプロバイダのDNSに問い合わせると、キャッシュした時点からの経過分が引かれた数字が返ります。問い合わせるたびに減っていき、0になると権威DNSに聞き直します
管理画面でTTLを3600から300に変えても、すでに3600でキャッシュした公開DNSは、残り時間がなくなるまで古い答えを返し続けます。「設定値が300になった」ことと「利用者が300秒ごとに新しい答えを受け取る状態になった」ことの間には、古いTTLの分だけ時間差があります。検証はこの差を把握するために行います。
手順1：権威DNSで設定値を確かめる
まずドメインのネームサーバーを調べ、そのサーバーに直接Aレコードを問い合わせます。
# ネームサーバーを調べる
dig example.com NS +short
# 権威DNSに直接問い合わせる（再帰なし）
dig @ns1.example-dns.net www.example.com A +norecurse +noall +answer +comments出力の答えの行は次のような形です。
www.example.com. 300 IN A 203.0.113.102列目の 300 が設定値です。あわせてヘッダーの flags: に aa（権威ある答え）が含まれているかを見ます。aa が無い場合は、問い合わせ先が権威DNSではないか、そのゾーンを持っていません。管理画面で編集しているDNSサービスと、実際にドメインが使っているネームサーバーが違うときによく起こります。
権威DNSが複数あるとき
ネームサーバーは通常2台以上あり、利用者はどれに問い合わせるか選べません。すべての権威DNSで同じTTLと値が返るかを確かめます。
for ns in $(dig example.com NS +short); do
echo "== $ns"
dig @"$ns" www.example.com A +norecurse +noall +answer
done1台だけ古いTTLや古いIPを返す場合は、セカンダリDNSへの転送が止まっている可能性があります。自分でBINDなどを運用しているなら、各サーバーの dig @サーバー example.com SOA +short でシリアル番号を比べ、プライマリより小さいサーバーを探します。
管理画面の「自動」表示に注意する
DNSサービスによっては、TTLの欄が「自動」のように表示され、具体的な秒数が画面に出ないことがあります。Cloudflare でプロキシを有効にしたレコードはこの扱いで、返るアドレスも自分のサーバーではなくCloudflareのものになります。AWS Route 53 のエイリアスレコードもTTLを自分で指定できず、向け先側の値が使われます。こうした場合も、権威DNSに問い合わせて返ってきた数字を正としてください。画面や仕様はサービスごとに変わることがあります（2026年10月現在）。
手順2：公開DNSで残りTTLを確かめる
次に、利用者が使う公開DNSに問い合わせます。
dig @8.8.8.8 www.example.com A +noall +answer
dig @1.1.1.1 www.example.com A +noall +answer数秒あけて同じ問い合わせを繰り返し、2列目の数字が減っていけば、それが残りTTLです。設定値より大きい数字が出ることは通常ありません。もし設定値より大きな数字が出るなら、それは変更前の古い設定値でキャッシュされた答えが残っているということです。
公開DNSは内部に多数のキャッシュを持っているため、問い合わせのたびに残りTTLが飛んだり、元に戻ったりすることがあります。1回の結果で判断せず、何回か問い合わせて最大値を見るのが目安になります。Windows では PowerShell の Resolve-DnsName でも確かめられます。
Resolve-DnsName www.example.com -Type A -Server 8.8.8.8 | Format-Table Name, Type, TTL, IPAddress手順3：CNAMEを経由する名前のTTLを確かめる
www がCNAMEで別の名前を指し、その先にAレコードがある構成では、TTLが2つあります。
dig @8.8.8.8 www.example.com A +noall +answerwww.example.com. 3600 IN CNAME example.hosting-service.net.
example.hosting-service.net. 60 IN A 203.0.113.10キャッシュDNSはCNAMEの行と向け先のAの行を別々に保持します。自分のゾーンで変えられるのは1行目のCNAMEのTTLだけで、2行目は向け先のサービスが決めています。移転でCNAMEの向け先を変える計画なら、下げるべきなのは1行目のTTLです。
手順4：移転前に下げたTTLが効いているかを判断する
サーバー移転でAレコードを書き換える前には、TTLを下げて待つのが一般的です。このときの判断は次の順で行います。
- 変更前の設定値（例: 3600秒）をメモしてから、TTLを300秒などに下げる
- 権威DNSに問い合わせ、すべてのサーバーで新しい設定値が返ることを確かめる
- その時刻から、変更前の設定値の秒数以上待つ
- 公開DNSで残りTTLを何回か確かめ、新しい設定値以下の数字しか出ないことを確かめる
4まで確かめられれば、Aレコードを書き換えたときに古い答えが残る時間は、おおむね新しいTTLの範囲に収まります。ただし、キャッシュDNSの中には独自に上限や下限を設けているものや、TTLを守らない古い機器もあり、すべての利用者で同じになるとは限りません。旧サーバーは書き換え後もしばらく動かしておくと安心です。
移転が終わったら、TTLを元の値か運用に合った値に戻します。短いままにすると、権威DNSへの問い合わせが増え、DNSサービス側の障害の影響も受けやすくなります。
検証でよく見つかる問題
- 同じ名前のAレコードが複数あり、TTLがばらばら: 同じ名前・同じ種類のレコードの集まりはTTLをそろえることが規格（RFC 2181）で求められています。値をそろえて登録し直します
- 権威DNSの1台だけ値が古い: セカンダリへの転送やシリアル番号の更新漏れを疑います
- 存在しない名前の答えが長く残る: まだ作っていない名前を先に問い合わせると、「存在しない」という答えがキャッシュされます。保持時間はSOAレコードの値で決まり、Aレコードに設定したTTLとは別です（RFC 2308）
- ブラウザだけ古いサイトが出る: OSやブラウザのDNSキャッシュ、hostsファイルの書き換えが残っていないかを確かめます
まとめ
- TTLの検証は、権威DNSでの「設定値」と公開DNSでの「残りTTL」を分けて読む
- 権威DNSへの問い合わせは
+norecurseを付け、aaフラグとすべてのネームサーバーの一致を確かめる - CNAMEを経由する名前では、自分で変えられるTTLと向け先サービスのTTLを区別する
- 移転前は、TTLを下げてから変更前の設定値以上待ち、公開DNSの残りTTLが新しい値以下になったことを見てから書き換える