DNS伝播とは？影響を最小限に抑える方法

Adresses IP
著者:

DNS伝播（DNS propagation）とは、権威DNSサーバーでレコードを変更した後も、一部のリゾルバーが古い値を返し続ける期間のことです。実際には変更がインターネット上に配信されるわけではなく、各リゾルバーがTTLの期限が切れるまで回答をキャッシュに保持しています。遅延は数分から、ネームサーバーを変更する場合は24〜48時間に及び、変更前のレコードのTTLと、ネームサーバーの場合はレジストリが設定する委任のTTLによって決まります。ここでは、その仕組みと影響を抑える方法を説明します。

要点

  • 変更は権威サーバーではすぐに反映されます。遅延の原因は、古い値をTTLの期限まで保持するリゾルバーのキャッシュだけです。
  • 古い値がどれだけ残るかは、今入力した値ではなく変更前に有効だったTTLで決まります。事前に下げておきましょう。
  • ネームサーバーの変更は最も遅くなります。管理できないレジストリの委任TTLに左右されるためです。
  • 「この名前は存在しない」というエラーもキャッシュされます。レコードを作る前にその名前へアクセスすると、エラーが長引くことがあります。

DNS伝播は配信ではない

この用語は誤解を招きます。どのサーバーも変更を他のサーバーへ送信してはいません。DNSプロバイダーで変更を保存すると、そのゾーンの権威ネームサーバーはすぐに新しい値を返します。遅延が生じるのは別の場所、つまりキャッシュです。

端末がドメイン名のアドレスを調べるとき、問い合わせは複数の層を通り、それぞれが回答を記憶している可能性があります。

  • ブラウザー：キャッシュは通常1分程度で、TTLを必ず守るとは限りません。
  • オペレーティングシステム：最近の回答を保持します。
  • 再帰リゾルバー：インターネットプロバイダーや公開サービス（たとえばGoogleの8.8.8.8、Cloudflareの1.1.1.1）が運営し、DNS階層をたどって結果を保存します。

各リゾルバーは、回答をキャッシュした時点で権威サーバーが伝えたTTLを適用します。全員が同じ瞬間に問い合わせたわけではないため、コピーの期限切れはそれぞれ異なる時刻になります。TTLが3,600秒のレコードを5分前にキャッシュしたリゾルバーは、55分後に更新します。そのため、新しいサイトが見える人、古いサイトが見える人、エラーになる人が混在します。

DNS伝播にかかる時間

所要時間は変更の種類によって異なります。TTLを1日（86,400秒）にするのは一般的で、ネームサーバーのようにあまり変わらないレコードでは、さらに大きな値が使われます。

変更の種類一般的な所要時間何で決まるか
既存レコードの変更（A、AAAA、CNAME、MX、TXT）古いTTLの長さまで。設定により数分から24時間変更前に有効だったTTL
存在しなかったレコードの作成状況により異なるが、通常は長くても数時間ゾーンのSOA（SOAのTTLとMINIMUMフィールド）
レジストラでのネームサーバー変更数時間から48時間レジストリの委任TTL（1〜2日が多い）
独自の制限を持つリゾルバー通知されたTTLを超えることがある設定された上限または下限（既定ではUnboundが86,400秒、BINDが604,800秒）

遅延を決める3つの要因

変更前のTTL

あるレコードのTTLが86,400秒で、今日これを300秒に設定したとします。昨日キャッシュしたリゾルバーは、新しい値がどうであれ最大24時間、古い値を保持します。300秒のTTLが適用されるのは、そのコピーが更新されてからです。CNAMEの場合は、チェーン内の各名前に固有のTTLがあり、最も長いものが全体の遅延を決めます。

レジストリでの委任

ネームサーバーを変更するときは、レジストラで変更し、レジストラがそれをトップレベルドメインのレジストリへ伝えます。古いネームサーバーの一覧をまだ記憶しているリゾルバーは、委任の期限が切れるまでそちらに問い合わせ続けます。このTTLはレジストリのものなので、短縮はできません。

TTLを厳密には守らないリゾルバー

TTLに上限や下限を設けるリゾルバーがあり、ブラウザーにも短期間の独自キャッシュがあります。そのため、どこでも同じ時間になるとは保証できません。TTLは理論上の上限であり、すべてのキャッシュが守る約束ではありません。

ネガティブキャッシュの落とし穴

多くのガイドはレコードのTTLだけを取り上げ、否定的な回答を見落としています。リゾルバーは、名前が存在しない（NXDOMAIN応答）、または要求された種類のレコードがないと知ると、その不在を記憶することがあります。RFC 2308は、ネガティブキャッシュの期間を、ゾーンのSOAのTTLとMINIMUMフィールドのうち小さいほうと定めています。1〜3時間は妥当で、1日を超える値は問題を起こすと注意しています。

典型的な流れは次のとおりです。レコードを作る前に new.example.com を試してエラーになり、その後でレコードを作成します。レコードが公開されて1分たっていても、お使いのリゾルバーにとってその名前はネガティブキャッシュが終わるまで「存在しない」ままです。避ける方法は次のとおりです。

  • 名前を試したり公表したりする前にレコードを作成する。
  • DNSプロバイダーでSOAを調整できる場合は、MINIMUMフィールドを控えめな値にしておく。
  • 「動かない」と判断する前にローカルキャッシュをクリアする。Microsoftは、ipconfig /flushdns がネガティブキャッシュのエントリも破棄すると説明しています。

移行の影響を抑える手順

  1. 現在のTTLを控える：対象となる各レコードについて（コマンドは後述）。遅延を決めるのはこの値です。
  2. TTLを下げる：300秒にします。少なくとも古いTTLの長さだけ前もって行ってください。86,400秒なら、切り替えの24〜48時間前です。プロバイダーが受け付ける下限も確認します。
  3. 新しい移行先を準備する：古い環境と同じ内容を返せるサイト、メールサーバー、CDNを用意します。切り替え期間中は両方が動いている必要があります。
  4. レコードを切り替える：何を確認すべきか分かるよう、1回に1つの変更だけ行います。
  5. 確認する：まず権威サーバー、次に公開リゾルバーです。
  6. 古いサーバーを稼働させ続ける：最も長い古いTTLが過ぎるまで待ち、その後で停止します。
  7. TTLを元に戻す：すべてが安定したら3,600秒以上に戻します。

ネームサーバーを変更する場合は、先に新しいプロバイダーでゾーン全体（A、CNAME、MX、SPFとDKIMを含むTXTなど、すべて）を再作成し、正しく応答することを確認してから、レジストラでネームサーバーを変更します。以前のプロバイダーのゾーンは、48時間は公開したまま同じ内容に保ってください。古い委任をまだ記憶しているリゾルバーが、引き続きそこへ問い合わせるためです。

各リゾルバーに見えている内容を確認する

dig（macOS、Linux）または nslookup（Windows）で、権威サーバーと複数の公開リゾルバーの応答を比較できます。

# 公開リゾルバーが返す値と残りのTTL
dig +noall +answer example.com A @8.8.8.8
dig +noall +answer example.com A @1.1.1.1

# ドメインに設定されているネームサーバー
dig +short NS example.com

# 権威サーバーが返す値（自分のネームサーバーに置き換えてください）
dig +noall +answer example.com A @ns1.dns-provider.example

# SOAのシリアル番号（ネームサーバー間で比較）
dig +short SOA example.com @ns1.dns-provider.example
dig +short SOA example.com @ns2.dns-provider.example
# Windowsでの同等のコマンド
nslookup -type=A example.com 8.8.8.8
nslookup -type=NS example.com

リゾルバーの応答に表示されるTTLは、問い合わせのたびに減っていきます。これはそのコピーの期限が切れるまでの残り時間です。リゾルバーが古い値をカウントダウン中のTTLとともに返し、権威サーバーがすでに新しい値を返しているなら、待つだけで解決します。

ネームサーバー間でSOAのシリアル番号も比較してください。異なる場合は、いずれかのサーバーが古いデータを返しています。問題は伝播ではなく、DNSプロバイダー側にあります。dns.googleのページではSOAを含む特定のレコードタイプを照会でき、Google Public DNSのトラブルシューティングガイドでこの確認方法が説明されています。

自分で管理できるキャッシュをクリアする

自分のキャッシュをクリアしても他の訪問者には何も影響しませんが、自分に実際に何が見えているかを確かめられます。

# Windows（コマンドプロンプト）
ipconfig /flushdns

# 最近のmacOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# systemd-resolvedを使うLinux
resolvectl flush-caches

Microsoftは ipconfig コマンドのページで /flushdns と /displaydns を説明しています。その後、ブラウザーを完全に終了してください。ブラウザーには独自の短期的な記憶があります。

2つの公開リゾルバーにはキャッシュのクリア機能もあり、ネームサーバー変更後や、それらを使っているユーザーに役立ちます。Google Public DNSのFlush Cache（Googleは、登録ドメインと古い回答を返している正確な名前の両方をクリアするよう勧めています）と、Cloudflareの1.1.1.1キャッシュ削除ツール（ドメインとレコードタイプを選択します）です。インターネットプロバイダーのリゾルバーはクリアできないため、コピーの期限切れを待つ必要があります。

よくある間違い

  • 切り替えの時点でTTLを下げる。遅すぎます。リゾルバーは古いTTLで作ったコピーを保持します。
  • レコードを作る前に名前を試す。ネガティブキャッシュでエラーが長引くことがあります。
  • ゾーン全体を再作成する前にネームサーバーを変更する。入れ忘れたメールやサブドメインのレコードが、すでに新しいプロバイダーへ問い合わせているリゾルバーでは機能しなくなります。
  • 古いサーバーを早く止めすぎる。キャッシュが切れていない訪問者が、応答しないサーバーにたどり着きます。
  • 自分のパソコンだけで伝播の完了と判断する。ローカルのキャッシュは他のリゾルバーを代表しません。
  • 非常に短いTTLを恒久的に残す。ネームサーバーへの問い合わせが増えます。移行が終わったら戻してください。

よくある質問

DNS伝播にはどのくらい時間がかかりますか？

レコードを変更する場合は、長くても古いTTLの長さまでです。TTLが3,600秒なら1時間、86,400秒なら24時間です。ネームサーバーを変更する場合は、数時間から48時間かかります。ほとんどのリゾルバーは最大の期間よりかなり前に更新されます。残るのは、少数の更新が遅れたキャッシュだけです。

DNS伝播を早めることはできますか？

インターネット全体に対しては無理です。他人のキャッシュを強制的に更新することはできません。できるのは、変更前にTTLを下げること、GoogleとCloudflareの公開リゾルバーをクリアすること、自分のキャッシュを空にすることです。インターネットプロバイダーのリゾルバーはクリアできません。

移行の前にTTLはいくつにすればよいですか？

300秒（5分）のような短い値にし、切り替えの前に少なくとも古いTTLの長さの間は適用します。移行が安定したら3,600秒以上に戻してください。非常に低いTTLを恒久的に使うと問い合わせが増えます。DNSプロバイダーが受け付ける下限も確認してください。

同僚には新しいサイトが見えるのに、自分には見えないのはなぜですか？

異なるリゾルバーを経由していて、回答をキャッシュした時刻が違うためです。両方のパソコンから同じ公開リゾルバーを照会して比較し、古い版がまだ見えているパソコンのローカルキャッシュをクリアしてください。

伝播の間、メールはどうなりますか？

MXレコードの変更にも同じ規則が当てはまります。遅延の間は、一部の送信者が古いメールサーバーに送り続けます。切り替えが終わるまで、古いサーバーを稼働させておいてください。サーバーが利用できない場合、送信側のサーバーは通常、メッセージを保持して数日間再試行します。

パソコンのキャッシュをクリアする必要はありますか？

自分に何が見えているかを確認するにはクリアしますが、他の訪問者には何も影響しません。お使いのシステムのコマンドを実行し、ブラウザーを完全に終了してください。それでも値が古い場合は、インターネットプロバイダーのリゾルバーがコピーを保持しています。

オンラインの伝播チェックツールで結果が異なるのはなぜですか？

各ツールは国ごとに異なるリゾルバーに問い合わせ、それらは異なる時刻に回答をキャッシュしています。TTLがすべての場所で切れるまでは、結果が混在するのは正常です。権威ネームサーバー自体が異なる応答を返す場合は、SOAのシリアル番号を比較してください。その場合、問題は伝播ではなくゾーンにあります。