DNS PROPAGATIONProxy
DNS 伝播チェック
Cloudflare / Google / Quad9 / OpenDNS や中国・韓国・台湾のリゾルバから同じレコードを並列照会し、DNS 変更の伝搬状況と応答差分を可視化します。
入力値は InfraLab の proxy を経由して外部へ問い合わせます。リクエスト内容をログとして長期保存しません。通信方式について
DNS 伝播チェックでできること
複数の公開再帰リゾルバへ同じ DNS レコードを照会し、変更後の値がどこまで観測されているかを比較します。 RFC 1035 の DNS は分散データベースとキャッシュを前提にしているため、変更は瞬時に全利用者へ届くのではなく、 キャッシュの期限切れと権威 DNS の応答更新によって見え方が変わります。
TTL/伝播時間の用語表
用語
TTL
意味
Resource Record をキャッシュしてよい秒数
確認ポイント
短いほど切替は速いが問い合わせは増える
用語
権威 DNS
意味
ゾーンの正本を返す DNS サーバー
確認ポイント
ここが新値を返していなければ伝播以前の問題
用語
再帰リゾルバ
意味
利用者の代わりに名前解決してキャッシュするサーバー
確認ポイント
Google / Cloudflare / ISP などで差が出る
用語
否定キャッシュ
意味
NXDOMAIN / NODATA など存在しない応答のキャッシュ
確認ポイント
新規追加直後に古い不在応答が残る原因になる
dig との違い
dig は 1 つのリゾルバまたは権威 DNS へ深く問い合わせる調査に向きます。DNS 伝播チェックは複数リゾルバの 観測差を横並びで見る用途です。権威 DNS の正本確認は dig、利用者側の見え方の差分確認は伝播チェック、 委任や DNSSEC を含む構成点検は DNS Health Check と使い分けます。
なぜ伝播しないように見えるのか
- 古い TTL がまだ切れておらず、再帰リゾルバが旧値を返している。
- 権威 DNS の一部だけが更新され、NS ごとに新旧の応答が混在している。
- 新規レコード追加前の NXDOMAIN / NODATA が否定キャッシュとして残っている。
- 親ゾーンの NS 委任や DNSSEC DS が古いままで、別の権威へ問い合わせている。
結果の読み方／次の一手
- 全リゾルバで新値なら、一般利用者からも新設定が見える可能性が高い状態です。
- 一部だけ旧値なら、古い TTL の期限切れを待つか、そのリゾルバのキャッシュ挙動を確認します。
- すべて旧値なら、権威 DNS、ゾーン反映、NS 委任を dig と DNS Health Check で確認します。
- NXDOMAIN が混じる場合は、SOA と否定キャッシュ TTL を見て、追加直後の不在応答が残っていないか確認します。
よくある質問
- DNS 伝播には何時間かかりますか？
- 一律の時間はありません。DNS は変更を全世界へ押し出す仕組みではなく、リゾルバのキャッシュが TTL に従って期限切れになることで新しい応答へ移ります。古い TTL が長いほど、古い値が残る時間も長くなります。
- TTL を短くしてもすぐ反映しないのはなぜですか？
- TTL を短くする前に取得された古いレコードは、元の長い TTL が切れるまでキャッシュに残り得ます。変更直前ではなく、余裕を持って TTL を下げてから切り替える必要があります。
- NXDOMAIN が残ることはありますか？
- あります。RFC 2308 は否定応答のキャッシュを定義しており、存在しないという応答も SOA 由来の TTL でキャッシュされ得ます。新規レコード追加直後に NXDOMAIN が残る場合は否定キャッシュを疑います。
- リゾルバごとに結果が違う場合は何を見ますか？
- TTL、権威 DNS の応答、NS 委任、DNSSEC、古いレコードを返しているリゾルバの地域や事業者を見ます。権威 DNS 側が新旧で揺れていないかも DNS Health Check で確認してください。
関連仕様