書き換えは一斉には届かない。棚ごとに、期限が切れてから取り直す 古い番号が出るのは、期限内の写しが残るから DNS の答えには TTL (使い回してよい秒数) が付く ブラウザの棚 残り 135 秒。聞き直さず、古い番号を出す 古い番号 帯は残りの秒数 (TTL 300 秒) OS の棚 期限が切れて、取り直した。残り 240 秒 新しい番号 リゾルバの棚 期限が切れて、取り直した。残り 285 秒 新しい番号 対応表 (元の帳面) 書き換え済み 新しい番号 切れたら 下へ聞く 書き換えは一斉には届かない。棚ごとに、期限が切れてから取り直す
書き換えは一斉には届かない。棚ごとに、期限が切れてから取り直す 古い番号が出るのは、 期限内の写しが残るから DNS の答えには TTL (使い回してよい秒数) が付く ブラウザの棚 残り 135 秒。聞き直さず、 古い番号を出す 古い番号 帯は残りの秒数 (TTL 300 秒) OS の棚 期限が切れて、取り直した。 残り 240 秒 新しい番号 リゾルバの棚 期限が切れて、取り直した。 残り 285 秒 新しい番号 対応表 (元の帳面) 書き換え済み 新しい番号 切れたら 下へ聞く 書き換えは一斉には届かない。棚ごとに、 期限が切れてから取り直す
切り替えたのに、自分のパソコンだけ古い画面が出る
サーバー を移し、対応表も書き換えました。同僚の画面は新しくなっているのに、自分の ブラウザ だけ古いほうにつながります。設定が間違っているわけではありません。手元に古い答えが残っているだけです。
え、書き換えたなら全員に一瞬で反映されるはずじゃないの?
答えは「何秒使い回してよいか」と一緒に配られる
DNS の答えには、必ず秒数が付いてきます。TTL と 呼ばれる値で、この答えはあと何秒そのまま使ってよい、という有効期限です。
受け取った側は、その秒数の間は同じ質問が来ても聞き直しません。しかも残る場所は 1 か所ではありません。 ブラウザ の中、パソコンの OS 、そして途中のリゾルバと、経路上のあちこちに同じ答えの写しができます。書き換えが効いていないように見えるのは、このどれかがまだ期限内だからです。
DNS が 浸透するまで待つ、という言い方をよく聞きますが、変更が波のように広がっているわけではありません。実際に起きているのは、各所の写しが順に期限切れになって、そのたびに新しい答えを取り直している、それだけです。だから待つべき時間の上限は最初から決まっています。書き換える前に設定してあった TTL の 秒数です。
切り替えの前日に、秒数を下げておく
ここから運用の話です。TTL は 自分で決められるので、切り替えが分かっているなら次の順で動かします。
切り替えの数日前に TTL を 60 に下げる。元の長い秒数の写しが世の中から消えるまで待つ
対応表を書き換える。ここからは最大 1 分 で全員が新しい値を引き直す
数日様子を見て、問題なければ TTL を 元の値に戻す
普段から短くしておけばよいと思うかもしれませんが、短い TTL は 問い合わせの回数をそのまま増やします。落ち着いている レコード は 1 時間 、動かす予定があるときだけ 1 分 、と使い分けるのが現実的です。
TTL を 60 にしたら、必ずぴったり 60 秒 で切り替わるんだよね?
ふむ、そこは違う。リゾルバが指定より長く抱え込むことがあり、60にしても必ずしもぴったり切り替わるとは限らない。
もう 1 つ 、TTL は 必ず守られるとは限りません。リゾルバによっては、短すぎる値を勝手に切り上げて、自分で決めた下限まで持ち続けます。60 にしたのに 5 分 たっても切り替わらない環境がある、というのはこれが理由です。TTL は 「これ以上は残さない」 という上限ではなく、あくまで発行側からの希望だと思っておくと、見積もりを外しません。
手元だけ先に新しくしたいなら、写しを消せます。 ブラウザ の中の写しは、Chrome なら chrome:// net-internals/ #dns の画面で「Clear host cache」を押して消せます。 OS の写しは、macOS なら sudo dscacheutil -flushcache に続けて sudo killall -HUP mDNSResponder を打つと消えます。ただし消えるのは自分のパソコンの中だけで、他の人には何の影響もありません。これで直ったからといって、全員に届いた証拠にはなりません。
「まだ無い」もキャッシュされる
「無い」も、期限つきの答えとして手元に残る。作ったあとでも、期限が切れるまで引けない。だから、先に作ってから引く 作る前に引くと、「無い」が残る レコードを作る前に、名前を引いてしまった場合。上から下へ、時間の順 手元の写し 対応表 名前を引く レコードを作る前に、うっかり この名前の番号は? まだ行が無い 対応表にその名前が無い 「無い」 (期限の秒数つき) 「無い」を写す 期限が切れるまで、聞き直さない 「無い」も答えの写し レコードを作る 対応表に行が入る もう一度引く 対応表を見に行かず、写しにある 「無い」を返す 作ったのに引けない 期限が切れて、聞き直す やっと新しい番号 期限が切れるまで、「無い」のまま この期限は、そのレコードの TTL ではなく、ドメイン全体の管理用の行に書かれた秒数。 短くできないことが多い 作業の順で、待ち時間が変わる 順 起きること 先に引いてから作る 「無い」の写しが期限切れになるまで、引けない 先に作ってから引く 最初から新しい答えが返る。余計な待ち時間を作らない 「無い」も、期限つきの答えとして手元に残る。作ったあとでも、期限が切れるまで 引けない。だから、先に作ってから引く
「無い」も、期限つきの答えとして手元に残る。作ったあとでも、期限が切れるまで引けない。だから、先に作ってから引く 作る前に引くと、「無い」が残る レコードを作る前に、名前を引いてしまった場合。 上から下へ、時間の順 手元の写し 対応表 名前を引く レコードを 作る前に、うっかり この名前の番号は? まだ行が無い 対応表に その名前が無い 「無い」 (期限の秒数つき) 「無い」を写す 期限が切れるまで、 聞き直さない 「無い」も 答えの写し レコードを作る 対応表に行が入る もう一度引く 対応表を 見に行かず、 写しにある 「無い」を返す 作ったのに 引けない 期限が切れて、聞き直す やっと新しい番号 期限が切れるまで、「無い」のまま この期限は、そのレコードの TTL ではなく、 ドメイン全体の管理用の行に書かれた秒数。 短くできないことが多い 作業の順で、待ち時間が変わる 順 起きること 先に引いてから作る 「無い」の写しが 期限切れになるまで、引けない 先に作ってから引く 最初から新しい答えが返る。 余計な待ち時間を作らない 「無い」も、期限つきの答えとして手元に残る。 作ったあとでも、期限が切れるまで引けない。 だから、先に作ってから引く
見落としやすいのが、そんな名前は無い、という答えも残ることです。
レコード を作る前にうっかりその名前を引いてしまうと、無いという答えがしばらく手元に居座ります。その後で正しくレコードを作っても、期限が切れるまでは無いままです。作業の手順としては、先に引いて確認してから作るのではなく、先に作ってから引くほうが、余計な待ち時間を作りません。
この場合の秒数は、個々のレコードの TTL ではなく、そのドメイン全体の管理用の行に書かれた値が使われます。うっかり引いてしまってから慌てても、こちらは短くできないことが多い部類です。
つまり、無いって答えも他のレコードと同じで キャッシュ されるってことか
よく気づいた、無いも答えの一種としてキャッシュされる。ただし、その秒数を短くできるかまでは、ここでは触れていない。