先に結論
『反映待ち』で片付けず、レジストリの委任、権威DNS、DNSSEC検証、再帰リゾルバー、端末キャッシュのどこに差があるかを確認します。
安全な確認順
- 対象FQDN、レコード種別、旧値、新値、変更時刻、変更前TTLを記録する。
- レジストラ側のネームサーバー委任と、実際の権威DNSを確認する。
- 各権威DNSへ直接問い合わせ、同じ値と署名を返すか比較する。
- Google Public DNSやCloudflareなど複数の再帰リゾルバーを比較する。
- SERVFAILなら、DNSSEC検証あり・なしを分け、DS、DNSKEY、RRSIG、署名期限を確認する。
- 外部では新値、自端末だけ旧値なら端末・ルーター・VPNのキャッシュを確認する。
ポイント：TTLは旧応答をキャッシュできる時間です。変更後にTTLだけ短くしても、すでに保存された旧応答の期限は短くなりません。
結果の読み方
| 比較結果 | 可能性 | 次の一手 |
|---|---|---|
| 権威DNSも旧値 | ゾーン未更新・別ゾーンを編集 | 実際の権威DNS事業者とゾーンを確認 |
| 権威DNSは新、再帰DNSは旧 | TTLキャッシュ | 旧TTL満了を待ち、変更を重ねない |
| 一部権威DNSだけ違う | ゾーン同期不良 | 対象NSと時刻をDNS事業者へ連絡 |
| SERVFAIL、検証なしでは応答 | DNSSEC検証失敗 | 親DSと子DNSKEY、RRSIG期限を突合 |
| SERVFAIL、検証なしでも失敗 | 権威・委任・到達性 | NS、Glue、UDP/TCP 53、権威ログを確認 |
| NXDOMAIN | レコードなし・誤FQDN | 末尾ドット、サブドメイン、CNAME競合を確認 |
名前解決後に5xxやタイムアウトになる場合はサイト停止の切り分けへ進みます。
SERVFAILをDNSSEC障害と断定する前に
JPRSはDNSSEC検証に失敗した場合、キャッシュDNSが「Server failure」を返すと説明しています。ただし同じ応答は権威DNS停止や委任不備でも起きるため、SERVFAILだけでは原因を確定できません。
- 親ゾーンにDSがあるか、現在のKSKから生成した値と一致するか確認する。
- 権威DNSがDNSKEYと対象レコードのRRSIGを全サーバーで返すか確認する。
- RRSIGの有効期間と、署名更新ジョブの失敗を確認する。
- KSKロールオーバー中なら、新旧鍵・DSの公開順序と反映時刻を確認する。
- DNS事業者移行中なら、旧新両ゾーンが同じレコードと有効な署名を返すか確認する。
停止：障害中にDS・DNSKEY・ネームサーバーを同時変更すると、どの変更で戻ったか判別できません。現状を保存し、一度に一層だけ直します。
DNS事業者を移行した直後の復旧順
- 現在レジストリが委任しているNSと、旧・新ゾーンの内容を保存する。
- DNSSEC有効なら、新事業者が要求するDS更新順序を確認する。
- 旧新双方でWeb、MX、TXT、CAAを含む同一ゾーンを提供する。
- 委任変更後も旧側を少なくとも旧TTL以上維持する。
- 複数の検証リゾルバーで正常化してから、旧ゾーンや旧鍵を廃止する。
避ける操作
- 原因未確定のままA/AAAA/CNAMEを何度も書き換える。
- 委任先を変えた直後に旧DNSゾーンを削除する。
- DSレコードを残したままDNSSEC非対応のDNSへ移す。
- Web復旧のためにMX/SPF/DKIMまで同時変更する。
公式情報
よくある質問
DNSは最大72時間待てば必ず直りますか？
待ち時間だけで直るとは限りません。旧レコードのTTLによるキャッシュと、権威DNS・委任・DNSSECの設定不整合を分けて確認します。
SERVFAILはレコードがないという意味ですか？
違います。DNSSEC検証失敗、権威DNSの応答異常、委任不備などで回答を完成できない状態です。NXDOMAINとは分けて、DNSSEC検証あり・なしの応答を比較します。
DNSSECをすぐ無効化すれば直りますか？
レジストラ側のDSだけ、または権威DNS側の署名だけを先に変えると障害が続くことがあります。現在のDS・DNSKEY・RRSIGと移行先の手順を保存し、DNS事業者の公式手順に沿って一層ずつ変更します。