DNS 伝播

DNS伝播とは?

DNS伝播とは、DNS変更がDNSレコード更新後、インターネット全体のDNSサーバーに認識されるまでの時間を指します。nameserverを変更したり、Aレコードを更新したり、MXレコードを変更すると、その変更は即座には有効になりません。キャッシュの有効期限が切れて、権威サーバーから新しい情報が取得されるまで待つ必要があります。

「伝播」の理解

「伝播」という用語は少し誤解を招きます。DNS変更が積極的に「伝播」または「拡がる」わけではなく、以下のようなことが起きます:

1. レコードを更新 権威nameserverで

2. キャッシュされたコピーの有効期限切れ TTLに基づいて

3. 新しいクエリが権威サーバーから更新されたレコードを取得

4. 古いキャッシュされたコピーは有効期限が切れるまで提供され続けます

DNS伝播ではなく「DNSキャッシュの有効期限切れ」と言う方が正確ですが、伝播という用語は広く使われています。

DNS変更の仕組み

更新プロセス

ステップ1: DNSレコードを更新
        example.com Aレコード: 203.0.113.50 → 203.0.113.51

ステップ2: 権威nameserverが即座に新しいレコードを提供

ステップ3: 既存のキャッシュされたコピーはTTLの有効期限まで有効

ステップ4: TTL有効期限後の新しいクエリで更新されたレコードを受け取ります

ステップ5: すべてのキャッシュが最終的に有効期限が切れて更新されます
        → 「伝播完了」

タイムラインの例

時刻: 10:00 - DNS更新（TTL: 300秒／5分）

リゾルバーA（09:58にキャッシュ）:
  09:58 - 古いIPをキャッシュ、10:03で有効期限切れ
  10:03 - キャッシュ有効期限切れ、再度クエリ、新しいIPを取得

リゾルバーB（10:01にキャッシュ）:
  10:01 - 古いIPをキャッシュ、10:06で有効期限切れ
  10:06 - キャッシュ有効期限切れ、再度クエリ、新しいIPを取得

リゾルバーC（10:05にクエリ）:
  10:05 - キャッシュなし、即座にクエリ、新しいIPを取得

すべてのリゾルバーが新しいIPを持つまで: 10:06
伝播時間: 6分（TTLに基づいた最悪のケース）

伝播時間に影響する要因

TTL（Time To Live）

最も重要な要因:

nameserver変更

nameserverの変更は他のDNS変更より時間がかかります:

レジストリレベル: 24～48時間（TLDのnameserverキャッシュ）
リゾルバーレベル: NSレコードTTLに基づく
合計時間: 最悪48時間

ISPとリゾルバーの動作

すべてのDNSリゾルバーがTTL値を尊重するわけではありません:

• TTLを厳密に尊重
• 高速伝播

• 低いTTLを無視する可能性
• 指定より長くキャッシュ
• 伝播時間を数時間遅延させられます

地理的分布

異なる地域がローカルリゾルバーキャッシュに基づいて異なる時刻に更新:

北米: 10:05 - 更新
ヨーロッパ: 10:08 - 更新
アジア: 10:12 - 更新

クライアント側キャッシュ

DNSサーバーが更新された後も、ローカルキャッシュは古い値を保持することがあります:

• ブラウザキャッシュ: 通常60秒
• OSキャッシュ: 分～時間単位
• アプリケーションキャッシュ: アプリによって異なる

DNS伝播のチェック

オンライン伝播チェッカー

curl "https://domscan.net/v1/health?domain=example.com"
# 現在のDNS設定を表示

コマンドラインチェック

# Google DNS
dig @8.8.8.8 example.com

# Cloudflare DNS
dig @1.1.1.1 example.com

# ISP（サーバーを指定しない）
dig example.com

# 結果を比較

# nameserverを探す
dig example.com NS

# 権威NSに直接クエリ
dig @ns1.example.com example.com

「真実」を即座に表示します。キャッシュは関係ありません。

複数の場所からチェック

# DNSover HTTPSを使用したcurl
curl -H 'accept: application/dns-json'   'https://cloudflare-dns.com/dns-query?name=example.com&type=A'

伝播時間の最小化

変更前に

古い: example.com.    3600    IN    A    203.0.113.50
新い: example.com.    300     IN    A    203.0.113.50
                     ^^^
                     5分に削減

古いTTLの全期間を待機（3600秒 = 1時間）

example.com.    300    IN    A    203.0.113.51

グローバルリゾルバーをチェック

example.com.    3600    IN    A    203.0.113.51

変更中に

DNS伝播シナリオ

Aレコードの変更

# 変更前
example.com → 203.0.113.50

# 変更後
example.com → 203.0.113.51

# 伝播: 1x TTL期間

MXレコードの変更

nameserver変更

なぜこんなに長いのか?
TLDレジストリがNSレコードをキャッシュ
レジストリTTLは通常24～48時間
レジストリキャッシュの制御はできない

新しいサブドメインを追加

サブドメインがクエリされ、存在しなかった場合:
→ NXDOMAINがキャッシュされます（SOA最小TTL）
→ 新しいサブドメインは、キャッシュが有効期限切れになるまで解決しません

伝播の問題をトラブルシューティング

変更が伝播していない

dig @ns1.example.com example.com
# 新しい値を表示するはずです

dig example.com | grep -i ttl

dig example.com SOA
# 最小TTLフィールドを確認

ブラウザ、OS、アプリケーションキャッシュをクリア

部分的な伝播

伝播が停止している

1. 権威nameserverが正しいことを確認

2. 持続的な場合、ISPに連絡

3. ユーザーはパブリックDNS（8.8.8.8、1.1.1.1）に切り替え

DNS伝播 vs キャッシュTTL

ベストプラクティス

1. 変更前にTTLを削減: DNS更新の24～48時間前にTTLを低下

2. 適切なTTLを使用: パフォーマンス（高TTL） vs 柔軟性（低TTL）のバランス

3. グローバルに監視: 複数の地域からDNSをチェック

4. 古いサービスを実行し続ける: 伝播完了まで前のサーバーをメインテナンス

5. 変更を文書化: トラブルシューティングのため何が変わったかを記録

6. 徹底的にテスト: 切り替え前に新しいDNSレコードが動作することを確認

7. ユーザーに通知: 中断の可能性について警告

8. マネージドDNSを使用: anycastネットワークを持つプロバイダーは伝播時間を最小化

9. 監視を自動化: DNS変更と伝播ステータスについてアラートを設定

10. ロールバック計画: 問題が発生した場合の変更方法を理解

伝播チェックリスト

☐ 変更の24～48時間前にTTLを削減
☐ 古いTTLが有効期限切れになるまで待機
☐ DNS変更を実施
☐ 権威nameserverで確認
☐ 複数のパブリックリゾルバーをチェック
☐ 複数の地域からテスト
☐ 2x TTL期間の監視
☐ エラーレポートが報告されていないことを確認
☐ 望む場合はより高いTTLに復元
☐ 変更完了を文書化

DNS伝播はDNSキャッシュの自然な結果です。TTL動作を理解し、変更を適切に計画することで、スムーズで予測可能な更新と最小限の中断を確保できます。