浸透で誤魔化す事業者たち

レコード修正に伴いプロパゲーション（変更がインターネット全体に浸透するまでの期間）が数時間から2日ほど発生いたします。
通常DNSの変更は数時間で浸透しますが、すべてがインターネットに伝搬するまで最大48時間かかる場合もあります。(GoDaddy)
ドメインの DNS 伝播とは、DNS レコードが変更された後、世界中のネームサーバーを更新するプロセスです。完了までに最大 48時間かかることがあります。
ドメインのDNS変更そのものは24時間～48時間程度で行われますが、実際に新しい情報が世界中に浸透するまで最大で1ヶ月程度が必要となる場合もあります。
DNS の変更がインターネット全体で有効になる（＝浸透という）まで、およそ 1 ヶ月程度を目安にされることをオススメいたします。
これをDNSの浸透期間といい、弊社でも制御ができないものとなります。

そんなものはない

浸透いうなシミュレーション

みんな何を待っているのか?

自分のキャッシュサーバで新しいレコードが引けるのを待っている? (自分が引ければいい?)
世界中のキャッシュサーバが更新されるのを待っている? (永遠に?)
世界中のキャッシュサーバから古いキャッシュが消えるのを待っている? (少しまし)
祈りながら新しいウェブページが見えたりメールが届いたりするのを待っている? (30日キャッシュが消えなかったブラウザも)
権威サーバの応答が設定したゾーンデータに変わるのを待っている? (それ浸透?)

無駄に待つのは適切な設定手順/確認方法を知らないから

無駄に待ってからようやく調べ始める?
世界中のキャッシュなんてどうせ観測できない
待つのは権威サーバ (と委任) の応答だけでいい (時間は仕様があるはず)
どうやって調べてますか?
いきなりブラウザでアクセスしてみる? (アウト!)
dig www.example.com とかやってたりする? (アウト!)

適切な設定の手順と確認方法 (モデルケース)

マスターサーバ (できれば隠れマスター) でゾーン編集
1. ゾーンデータを編集、チェックする (nsd-checkzone など)
2. ゾーンの追加削除があれば conf もチェックする (nsd-checkconf など)
3. ゾーンを reload / conf も変更していれば reconfig
4. マスターサーバの応答を非再帰で確認
```
dig -t a www.example.jp @ns0.example.jp +norec
```
5. ゾーン転送 (nsd-control notify など) とか rsync とか、、、

全ての権威サーバの応答を非再帰で確認 (UDP, TCP)

dig -t a www.example.jp @ns[1234].example.jp +norec +ignore +notcp +bufsize=????

dig -t a www.example.jp @ns[1234].example.jp +norec +tcp

NS 新設や移転なら委任を依頼 (ネームサーバ情報の変更)
委任応答を非再帰で確認 (権威との NS の整合性が重要!)
```
dig example.jp @z.dns.jp +norec +bufsize=???? +dnssec
```
キャッシュサーバの応答を確認 (再帰は最後)
(最後まで我慢! 浸透待ちとなる大きな要因 / SOA minimum TTL は短めに)
NS 移転なら委任の TTL の期間は並行運用

なぜ浸透と言ってはいけないのか?

浸透だろうが伝播だろうが反映だろうが言いたい状況を作るのがいけない
適切な確認をさぼることで時間を浪費したい?
待ち時間は見積れる (リロードだけなら一瞬のはず)
新旧ゾーンの内容を一致させておけば応答がぱたつくことはない
利用者を誤魔化してはいけない
ミスは素直に説明して謝ろう
「浸透待ち」発言をトリガーにドメインが乗っ取られる可能性がある
(キャッシュの有効期間を適切に見積れないとキャッシュを乗っ取られる可能性も)

浸透待ちの乗っ取りパターン

おまけ: GO.JP を保護した話 (AWS Route 53 の例)

1月12日深夜 mext.go.jp (文科省) の権威サーバへ bousai を問い合わせ (SERVFAIL のリスト精査作業)

		;; AUTHORITY SECTION:
		bousai.mext.go.jp.	300 IN NS ns-173.awsdns-21.com.
		bousai.mext.go.jp.	300 IN NS ns-1407.awsdns-47.org.
		bousai.mext.go.jp.	300 IN NS ns-686.awsdns-21.net.
		bousai.mext.go.jp.	300 IN NS ns-1711.awsdns-21.co.uk.

		;; Query time: 19 msec
		;; SERVER: 202.241.4.6#53(dns2.mext.go.jp) (UDP)
		;; WHEN: Sun Jan 12 00:40:10 JST 2025

権威サーバへの問い合わせ

		; <<>> DiG 9.20.3 <<>> bousai.mext.go.jp @ns-173.awsdns-21.com.
		;; global options: +cmd
		;; Got answer:
		;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 2743
		;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
		;; WARNING: recursion requested but not available

		;; Query time: 122 msec
		;; SERVER: 2600:9000:5300:ad00::1#53(ns-173.awsdns-21.com.) (UDP)
		;; WHEN: Sun Jan 12 00:40:18 JST 2025

おまけ: Route 53 Lame Delegation 保護の再現

(AWS Console 画面録画...公開資料から削除)

質疑の補足

再確認しましたが Google Public DNS が TTL を守らないという観測は得られませんでした。ただし GPD は NS 移転のケースだと権威の NS TTL を短くしても委任元の TTL に引きづられます。(参考:権威サーバ引越し実験)

DNS キャッシュサーバ (フルサービスリゾルバ) が TTL を守るかどうかは dig @サーバ a.t.e-ontap.com を観察してみてください。権威サーバ側は以下のように切り替わります。

0-50/10 は 14.192.44.2
5-55/10 は 14.192.44.4

これが 60秒の誤差で切り替われば TTL を無視していません。
(ただし短い TTL の切り上げは設定によってありえます)

そんなに TTL を無視する実装、運用が多かったら CDN や DDNS が機能しませんよね。

DNSのアノ現象、正しく説明できますか?