DNS 変更後の反映確認、dig だけで大丈夫？
DNS レコードを変更した後、dig コマンドの結果だけでは外部のユーザーに届いている値を正確に把握できません。この記事では、DNS キャッシュの仕組みを整理し、dig の限界を理解した上で、外部視点から反映状況を確認する具体的な手順を解説します。
「DNS の浸透」という言葉が隠す本当の仕組み
DNS レコードを変更した後、「浸透を待ちましょう」というアドバイスを見かけた経験はありませんか。この表現は、情報がじわじわと世界中に広がっていくイメージを与えます。実際の DNS の仕組みはそうではありません。
DNS の名前解決では、再帰リゾルバー（キャッシュサーバー）がレコードを一時的に保持しています。保持期間は TTL（Time To Live）で決まり、TTL が 300 なら 5 分、3600 なら 1 時間でキャッシュが破棄されます。キャッシュが消えたリゾルバーは、次に問い合わせを受けた時点で権威サーバーから最新の値を取得します。
つまり「浸透」ではなく「キャッシュの期限切れ」です。世界中のリゾルバーが一斉に更新されるわけではなく、それぞれの TTL が切れたタイミングで順番に新しい値を取りに行きます。この違いを理解しておくと、反映確認のやり方が変わります。
dig で確認する手順とその死角
手元で DNS レコードを確認するなら dig が定番です。
dig A example.com +short93.184.216.34ローカルのリゾルバーを通すため、まだキャッシュが残っていれば古い値が返ります。Google Public DNS を指定して確認する方法もよく使われます。
dig A example.com @8.8.8.8 +short93.184.216.348.8.8.8 はローカルのリゾルバーとは別のキャッシュを持つため、結果が違うことがあります。ただし Google Public DNS 自体にもキャッシュがあります。ここで新しい値が返ったとしても、他のリゾルバーではまだ古い値が残っている可能性は消えません。
dig にはもう一つ見落としがちな制約があります。確認できるのは「自分が今いるネットワークから見た値」だけです。オフィスの VPN を通していたり、社内 DNS を経由していたりすると、外部のユーザーが実際に受け取る応答とは異なります。レコードを変更した本人の環境では正しく見えているのに、ユーザーからは「まだ古いまま」と言われる状況は、このギャップが原因です。
外部リゾルバーから見た値を取得する
dig の死角を補うには、自分のネットワークの外側からレコードを引く手段が要ります。
Labee Dev Toolbox の DNS API は、DNS over HTTPS を使って外部のリゾルバーからレコードを取得します。ローカルのキャッシュや社内 DNS を一切経由しません。example.com の部分を自分のドメインに置き換えて実行してみてください。
curl "https://labee.dev/api/dns?domain=example.com&type=A"{
"success": true,
"data": {
"domain": "example.com",
"records": {
"A": [
{ "address": "93.184.216.34", "ttl": 3600 }
]
}
},
"error": null,
"meta": { "responseTime": 45 }
}records.A の address フィールドが現在の A レコードの値です。手元の dig と見比べて、値が一致していれば外部からも同じレコードが見えている状態です。一致しない場合は、ローカルのキャッシュにまだ古い値が残っています。
type パラメーターを省略すると、A, AAAA, MX, TXT, NS, CNAME, SOA, CAA の 8 種類 を一括で取得できます。レコード変更後に「他のレコードが巻き添えで壊れていないか」をざっと確認したい場面で便利です。
curl "https://labee.dev/api/dns?domain=example.com"{
"success": true,
"data": {
"domain": "example.com",
"records": {
"A": [{ "address": "93.184.216.34", "ttl": 3600 }],
"AAAA": null,
"MX": [{ "priority": 10, "exchange": "mail.example.com" }],
"TXT": [["v=spf1 -all"]],
"NS": ["a.iana-servers.net", "b.iana-servers.net"],
"CNAME": null,
"SOA": [{ "mname": "ns1.example.com", "rname": "admin.example.com", "serial": 2026040101, "refresh": 7200, "retry": 3600, "expire": 1209600, "minimum": 86400 }],
"CAA": null
}
},
"error": null,
"meta": { "responseTime": 120 }
}レコードが存在しない種類は null で返ります。MX や TXT が意図せず消えていないかを、この一覧で確認できます。
TTL を意識した変更の段取り
DNS レコードの変更は、TTL を事前に下げておくと反映確認までの待ち時間を短くできます。
変更の 24 時間以上前に TTL を下げる
現在の TTL が 3600（1 時間）であれば、300（5 分）程度に変更します。この変更自体が反映されるまでに旧 TTL 分の時間がかかるため、24 時間以上前に 実施しておきます。
旧 TTL が切れるのを待つ
旧 TTL が 3600 なら、1 時間待てば世界中のリゾルバーが新しい TTL 値を取得しています。
レコードの値を変更する
TTL が短くなった状態で A レコードや MX レコードの値を変更します。
外部から反映を確認する
TTL を 300 に設定済みであれば、変更後 5 分 で外部リゾルバーのキャッシュが入れ替わります。
curl "https://labee.dev/api/dns?domain=example.com&type=A"{
"success": true,
"data": {
"domain": "example.com",
"records": {
"A": [
{ "address": "203.0.113.50", "ttl": 300 }
]
}
},
"error": null,
"meta": { "responseTime": 38 }
}address が新しい IP アドレスに変わっていれば反映完了です。dig で @8.8.8.8 を指定した結果とも突き合わせると、複数の視点から確認できます。
TTL を元に戻す
反映を確認したら、TTL を元の値（3600 など）に戻します。TTL を短いまま放置すると、リゾルバーが権威サーバーへ問い合わせる頻度が上がり、応答速度に影響が出ます。
定期的な外部チェックを自動化する
開発チームでドメインを管理している場合は、手動での確認に頼らず定期的な自動チェックを組み込むと安心です。
dig をスクリプトで回す方法がもっとも手軽です。
current=$(dig +short A example.com @8.8.8.8)
if [ "$current" != "93.184.216.34" ]; then
echo "A record changed: $current"
exit 1
fiこの方法は CI 環境から 8.8.8.8 への UDP 53 が通る前提です。ファイアウォールで DNS の外部問い合わせがブロックされている環境では動作しません。
HTTPS 経由で確認したい場合は、Labee Dev Toolbox の API を使う方法もあります。
result=$(curl -fsS "https://labee.dev/api/dns?domain=example.com&type=A")
address=$(echo "$result" | jq -r '.data.records.A[0].address')
if [ "$address" != "93.184.216.34" ]; then
echo "A record changed: $address"
exit 1
fiAPI キーは不要なので、Secrets の設定なしで動きます。GitHub Actions の cron: '0 9 * * *' で毎日実行しておけば、DNS の変更が検出された時点で通知を受け取れます。