DNS キャッシュと TTL

切り替えたのに、自分のパソコンだけ古い画面が出る

サーバーを移し、対応表も書き換えました。同僚の画面は新しくなっているのに、自分のブラウザだけ古いほうにつながります。設定が間違っているわけではありません。手元に古い答えが残っているだけです。

答えは「何秒使い回してよいか」と一緒に配られる

DNS の答えには、必ず秒数が付いてきます。TTL と呼ばれる値で、この答えはあと何秒そのまま使ってよい、という有効期限です。

受け取った側は、その秒数の間は同じ質問が来ても聞き直しません。しかも残る場所は 1 か所ではありません。ブラウザの中、パソコンの OS、そして途中のリゾルバと、経路上のあちこちに同じ答えの写しができます。書き換えが効いていないように見えるのは、このどれかがまだ期限内だからです。

DNS が浸透するまで待つ、という言い方をよく聞きますが、変更が波のように広がっているわけではありません。実際に起きているのは、各所の写しが順に期限切れになって、そのたびに新しい答えを取り直している、それだけです。だから待つべき時間の上限は最初から決まっています。書き換える前に設定してあった TTL の秒数です。

切り替えの前日に、秒数を下げておく

ここから運用の話です。TTL は自分で決められるので、切り替えが分かっているなら次の順で動かします。

1. 切り替えの数日前に TTL を 60 に下げる。元の長い秒数の写しが世の中から消えるまで待つ
2. 対応表を書き換える。ここからは最大 1 分で全員が新しい値を引き直す
3. 数日様子を見て、問題なければ TTL を元の値に戻す

普段から短くしておけばよいと思うかもしれませんが、短い TTL は問い合わせの回数をそのまま増やします。落ち着いているレコードは 1 時間、動かす予定があるときだけ 1 分、と使い分けるのが現実的です。

もう 1 つ、TTL は必ず守られるとは限りません。リゾルバによっては、短すぎる値を勝手に切り上げて、自分で決めた下限まで持ち続けます。60 にしたのに 5 分たっても切り替わらない環境がある、というのはこれが理由です。TTL は「これ以上は残さない」という上限ではなく、あくまで発行側からの希望だと思っておくと、見積もりを外しません。

手元だけ先に新しくしたいなら、写しを消せます。Chrome なら chrome://net-internals/#dns の画面から、macOS なら sudo dscacheutil -flushcache で消えます。ただし消えるのは自分のパソコンの中だけで、他の人には何の影響もありません。これで直ったからといって、全員に届いた証拠にはなりません。

「まだ無い」もキャッシュされる

見落としやすいのが、そんな名前は無い、という答えも残ることです。

レコードを作る前にうっかりその名前を引いてしまうと、無いという答えがしばらく手元に居座ります。その後で正しくレコードを作っても、期限が切れるまでは無いままです。作業の手順としては、先に引いて確認してから作るのではなく、先に作ってから引くほうが、余計な待ち時間を作りません。

この場合の秒数は、個々のレコードの TTL ではなく、そのドメイン全体の管理用の行に書かれた値が使われます。うっかり引いてしまってから慌てても、こちらは短くできないことが多い部類です。