DNS の浸透待ち
DNS リソースレコードを管理していると、「DNS には浸透期間があるため、DNS の設定変更後は24時間〜72時間お待ちいただく必要があります」などと書かれた DNS 事業者の注意書きを見かけることがあります。
- ホスティング業者によって「浸透」等が不適切に使われている例 - www.e-ontap.com
- DNS浸透言ってるところと言っていないところ【レンタルサーバ編】 - ohesotori.hateblo.jp
このような記述が蔓延っているために、DNS 利用者の間で「DNS では設定が浸透するまで待たなければならない」という誤解が広まっています。
また、DNS リソースレコードの地理的な伝播状況を可視化するための DNS Propagation Checker なるツールがいくつか存在しています。
しかし、DNS は浸透・伝播するものではありません。
伝搬(でんぱん)という言葉 - 伝播(でんぱ)の誤用
DNS に限らず「伝搬」という言葉が使われることがあります。伝搬という言葉は、一般に伝播の誤用(慣用読み)として広まった言葉とされています。
ただし、特定のコンテキストにおいては正式用語として「伝搬」が採用されているケースがあります。例えば、電波工学分野における「電波伝搬(Radio propagation)」という用語があり、工学分野および電波法のコンテキストにおいては「伝搬」という用語が使われます。工学分野において伝搬という言葉が定着した経緯としては、伝播という言葉を用いると電波と区別が付かないという事情や、伝搬という俗用が広まっていたことから伝播よりも伝搬という言葉が定着したとされています。他にも情報分野のおける「ループ伝搬(Loop carried)」という用語があります。これについてはループ伝播と呼ばれることもありますが、伝搬の方が訳として適切だと主張されることがあります。
とはいえ、一般的なコンテキストにおいては、「伝搬」は「伝播」の誤用であるという認識が正しいでしょう。浸透いうなの前に「伝搬いうな」と言っておくことにします。
では DNS はどのように機能するのか
あるドメイン名に対する DNS リソースレコードへの問い合わせが行われると、問い合わせを受けた DNS 権威サーバ(ゾーンサーバとも呼ばれる)は DNS リソースレコードの情報を応答します。このとき、その情報には TTL(生存期間)が含まれています。これは応答を受け取った DNS キャッシュサーバが再度同一の問い合わせを行う際に、代わりに過去に受け取った情報をキャッシュとして利用してよい期間を表します。
このキャッシュは、いわゆるサーバサイドのリバースプロキシにおけるキャッシュではなく、クライアントサイドのフォワードプロキシにおけるキャッシュとして存在しています。つまり、DNS キャッシュサーバに情報がキャッシュされてしまうと、サーバサイド(DNS リソースレコード管理側)からはキャッシュを削除するといった操作ができないことを意味します。これは、DNS キャッシュサーバがクライアンドサイドに存在していることに因ります。
お使いの端末(パソコンやスマートフォン)で Web ブラウザを開きアドレスバーにドメイン名を入力すると、Web ブラウザはドメイン名の名前解決(対応する IP アドレスを求める処理)をするため端末の OS 内に存在するスタブリゾルバを呼び出します。スタブリゾルバは、OS のネットワーク設定で指定されている DNS キャッシュサーバ(フルリゾルバとも呼ばれる)に名前解決要求を行います。DNS キャッシュサーバは名前解決要求を受けたドメイン名の IP アドレスをキャッシュに持っていなければ、ゾーンサーバへ問い合わせを行います。
このようなプロセスでゾーンサーバへの問い合わせが行われるため、ゾーンサーバ側で DNS リソースレコードの情報を変更したとしても、DNS キャッシュサーバがキャッシュを保持している期間は、スタブリゾルバからの問い合わせに対して DNS キャッシュサーバはゾーンサーバに新しい情報を問い合わせることなくキャッシュしている古い情報を応答します。これは、DNS リソースレコードの情報を変更した利用者にとっては期待しない結果をもたらします。
DNS のモデル - 「浸透・伝播」ではなく「問い合わせ・キャッシュ」
DNS リソースレコードの情報を変更したとき、そのゾーンサーバから別の DNS サーバやインターネット上に情報が浸透・伝播・反映していくような Push 型のモデルは DNS にはありません。
そうではなく、変更されたゾーンサーバに問い合わせが行われるか、それともキャッシュが使われるかという、強いて言えば Pull 型のモデルなのです。
DNS propagation という専門用語の存在
実は DNS には専門用語として propagation(伝播)という概念があります。それは、DNS 権威サーバのプライマリネームサーバのゾーン情報を更新した際に、セカンダリネームサーバにゾーン情報を転送する(ゾーン転送)処理のことを指す用語です。このゾーン転送における動作のことを propagation(伝播)といいます。
letsencrypt.org のドキュメントに「伝播時間 (propagation time)」という記述があるのはこのゾーン転送における動作のことを指しています。
浸透いうな
ゾーン転送以外のコンテキストでは、浸透・伝播という言葉が DNS において不適切であることは理解できたでしょうか。浸透・伝播という言葉を使っていると、「DNS では設定が浸透するまで待たなければならない」という誤解がいつまでたっても解けません。
よく「浸透いうなと言うけれど、じゃあ何て言ったらいいんだ」と反論する人がいます。「浸透いうな」は言葉狩りではないのです。言葉の問題ではなく、概念の理解が間違っていることに気が付かせるためのキャッチフレーズなのです。いつまでも「浸透」と言っていたら概念の理解が間違っていることに気付くきっかけが失われてしまいます。「浸透期間が存在していて、浸透を待っていればよいもの」ではないのです。だからこそ、「浸透いうな」なのです。
……なお、2005年(約20年前)に既に別の領域で同様の議論がされています。「サニタイズ言うな」は、エスケープの必要性に気付く機会を失わせる「サニタイズ」という悪しき概念を撲滅するためのキャンペーンだったのです。「浸透いうな」も同様のキャンペーン(作戦行動)なのです。
海外の状況 - DNS propagation does not exist
「DNS では設定が浸透するまで待たなければならない」という誤解は海外でも同様に広がっています。DNS Propagation Checker なんていうものはほとんどが海外製です(日本製のものがあるのかは知りません)。
海外版の「浸透いうな」は DNS propagation does not exist として啓蒙が行われています。
たまに「海外でも propagation と言われてるのだから、浸透と言って何が悪い?」と憤る人がいます。英語で記述されていれば信用できると考える思想は危険です。何事も懐疑的に、批判的に評価する必要があります。
浸透いうなといわれても
心配する必要はありません。これは気付きのきっかけを与えてくれる言葉なのです。言葉狩りでもなければ、間違いを批判しているわけでもありません。
浸透待ちなんかする必要はないのです。適切な手順を実施すれば、DNS リソースレコードの情報変更は即時反映が可能です。NS レコードの変更(ネームサーバの変更)操作ではどうしても上位ゾーンサーバの TTL がコントロールできないので、TLD によっては 2 日間ほど NS 移転が完了するのに待つ必要はありますが、それは浸透待ちではありません。DNS の仕組みを理解して DNS リソースレコードを変更する際の適切な手順を覚えることで、意図せぬトラブルを生じさせることなくゾーンサーバの情報の更新が可能になります。
「浸透期間」「72時間待て」「インターネット全体に反映されるまで」といった誤った理解に基づく説明に騙されることなく、DNS を利用できるようにいますぐ学習を始めましょう!
DNS 入門 - 非再帰問い合わせ
DNS ルックアップには dig コマンドの「非再帰問い合わせ」またはそれに相当するコマンド(dnsq コマンドなど)を使いましょう。
通常の名前解決要求のプロセスでは「再帰問い合わせ」が使われます。これは DNS キャッシュサーバ向けに問い合わせを行う際に使われるもので、キャッシュ情報が返ってくる可能性があります。ゾーンサーバの DNS リソースレコードを書き換えた際には、ゾーンサーバから期待する情報が取得できるかどうかを確認するべきです。それには dig コマンドであれば +norec オプションを付けると同時に @ns.example.com のようにゾーンサーバの宛先(ドメイン名または IP アドレス)を指定して「非再帰問い合わせ」を行うことで確認することができます。
DNS リソースレコードの変更時には、DNS キャッシュサーバへ問い合わせるべきではないのです。下手に DNS キャッシュサーバに問い合わせると、古い情報がキャッシュされてしまったり、ネガティブキャッシュが生成されてしまったりします。ネガティブキャッシュとは、「情報が存在しなかった」という情報のキャッシュのことです。
非再帰問い合わせを使えるようになって、ゾーンサーバに直接問い合わせる方法を覚えましょう。