なぜ「DNSの浸透」は問題視されるのか (4)

2011/10/27-1

さらに、キャッシュされた各レコードにはTTLと呼ばれる「キャッシュの生存期間」が指定されています。 DNSキャッシュサーバは、各レコードをTTLで示された秒数以上は保持せず、TTL時間が経過したレコードは破棄します。

このような仕組みから、DNSの情報は「浸透」や「伝播」するようなものではありません。 DNS権威サーバーは問い合わせに対してのみ応答します。つまり、問い合わせがない限り、委任情報やレコードをDNSキャッシュサーバに能動的に渡しません。さらに、DNSキャッシュサーバも、自分が保持しているキャッシュが切れた時点で自発的に再問い合わせするわけでもありません(ただしGoogle Public DNSは、それをすることで「高速化」していると宣言しています)。つまり、ルーティングの仕組みなどと異なり、変更した情報そのものが「能動的に」かつ「徐々に」伝わっていくわけではないことから、浸透とか伝搬とか言うのは、技術的に正しいとは思えません。

3. なぜ「DNSの浸透」という表現が問題なのか？

DNSレコードの変更や、DNSの引っ越しを行うときに「古いデータ」が世界中のDNSキャッシュサーバにキャッシュされている状態を表現しているのが「DNSの浸透」ということのようです(RFCとして定義されているわけでも、正式な技術用語というわけでもないので、「これが浸透です」とは言いにくいのが現状です)。

しかし、世界中のDNSキャッシュサーバに保持されている「古いデータ」の生存期間は、DNS権威サーバが制御しています。そのため、自分でDNS権威サーバの設定を変更したのであれば、いつまでに世界中のDNSキャッシュサーバの情報が最新になるのかを知っているはずです。もし、予定通りに反映が行われなければ、何らかの設定ミスや運用ミスが存在しているはずです。

「DNSの浸透」という表現によって、あたかも「DNS権威サーバの設定を変更したけれど、その情報が反映される時期は神のみぞ知る」というようなイメージを持ってしまい、障害発生箇所を特定することを放棄してしまうのが大きな問題です。実際には何かの障害が発生している状況のときに「DNSの浸透」という、それっぽい説明があると、それを聞いて納得してしまい、本質的な仕組みを勉強する意欲(もしくは機会/必要性/意識)を奪ってしまいます。

DNSキャッシュサーバがキャッシュを保持するTTLに関しての知識があれば、あらかじめTTLを短くしたうえで実際のDNSレコード変更を行えば「DNSの浸透」という単語に頼る必要がそもそも必要ない時間以内に世界中で情報が反映されるという事実に多くの人が気がついていなさそうであるというのが、「DNSの浸透」という魔力の一端なのかも知れないと思う事はあります。 (みんなが「DNSの浸透」という言葉で納得してしまうので、TTLを無視するプロトコル違反なDNSキャッシュサーバが存在し続けられるのかも知れません)

もう一つあり得るのが、運用ミスを隠すという意図で「DNSの浸透」が使われる場合です。実際には、自分の設定ミスで反映が遅れていることを誤摩化すために「DNSの浸透には時間がかかります」と回答している場合もあり得そうです。ただ、実際には全体的な構造を理解せずに設定を変更して、いつも良くわからないけどいつの間にか設定情報が反映されているという経験則で語っているだけという可能性もありそうです。

4. まずはAレコードで考える

「DNSの浸透」は、NSレコードの変更に関連して使われることが多いのですが、DNS設定の変更とキャッシュの関係を理解するために、まずはIPv4アドレス情報を表現しているAレコードで考えます。

4.1. Aレコードの変更とTTL

以下の図のように、IPv4アドレスを表すAレコードを2時間前に変更したとします。

しかし、図のように、とあるISPのあるとあるユーザが利用しているDNSキャッシュサーバが、権威サーバに6時間34分15秒前に問い合わせてしまって、キャッシュが残り3時間25分45秒は有効であり続けるという状態になっています。

この例の場合、DNS権威サーバで変更される前のAレコードのキャッシュが世界中から消えるのは8時間後です。これは、前の設定で「www.example.com」のAレコードのTTLが36000秒(10時間)であったためです。変更そのものは2時間前なので、変更直前に駆け込みでDNS権威サーバに問い合わせたDNSキャッシュサーバがいたとしても8時間後には古いAレコードのTTLが切れて、新たな問い合わせが行われます。新たな問い合わせがDNS権威サーバに来れば、新しいAレコードの情報がDNSキャッシュサーバにキャッシュされます。

このように、Aレコードで考えると「DNSが浸透する」というよりも、「古いキャッシュの有効期限が切れる」として理解しやすいと思います。

4.2. Aレコードが反映される時間を制御する方法

先ほどの例では、DNS権威サーバでAレコードの内容を変更してから、古いキャッシュが消えるまで10時間待たなければなりませんでした。しかし、DNS権威サーバでの設定内容変更のために必ず長い時間を待たなければならないわけではありません。

次のような方法をとれば、Aレコード変更の反映を素早く行うことができます。

AレコードのTTLを小さくする。たとえば、当初設定が1日だとすると、1時間に変更するなど。
AレコードのTTLを小さくしてから、当初設定時間まで待つ。当初設定時間が1日だったら、1日待ってから次の作業を行う。こうすれば、設定変更が世界中のキャッシュ内で存在できる時間が短くしたTTL以下になる。
スレーブ(セカンダリ)DNSが運用されている場合には、そちらの情報更新も反映されているか確認する。シリアル番号更新忘れによって設定が更新されていないなどのミスがないことを確認するという意味もあります。
短くしたTTLの時間分だけ待つ
変更が反映されているかいくつかのDNSキャッシュサーバで確認する。変更が反映されていない場合は、原因を究明する。
問題がなさそうであれば、TTLの値を元に戻す。

事前にTTLを短くして待つという意味では、変更作業全体にかかる時間を短くできるわけではありませんが、実際の設定変更を行ってから古いキャッシュが存在できる時間を制御することができます。このような作業を行えば「反映されるまで数日かかります」というような状況は発生しません。

(続く：次へ)

過去記事

過去記事一覧

超凄いIPv6解説書(488ページ)を無料配布します！