直したのに、まだ古いほうが表示される｜TTLは先に下げる、解約と削除は別の作業

梟〜GLEANINGS〜

2026年9月17日 08:48

サイトの引っ越しが終わりました。

ドメイン名の設定を書き換えて、保存します。
自分のパソコンで開くと、新しいサイトが出ます。

ところが、隣の席では古いままです。
社長のスマートフォンでも古いままでした。

「反映に時間がかかります」と言われて、どれくらいですかと聞くと、はっきりした答えが返ってきません。

実は、はっきりした数字が設定の中に書いてあります。
自分で決められます。

この記事では、その数字の話と、使い終わった設定を消し忘れたときに何が起きるかを、JPRSの用語辞典から並べます。
どちらも、切り替える前と、閉じるときにやることが決まる話です。

この記事は、株式会社日本レジストリサービス（JPRS）が公開している用語辞典をもとに、2026年9月時点の内容にしています。用語の解説は改訂されます。実際の設定は、お使いの事業者の説明とあわせて確認してください。

DNSの答えには、覚えてよい時間が付いている

毎回いちばん元まで聞きに行くわけではない

名前を行き先に変換する問い合わせは、毎回いちばん元まで聞きに行くわけではありません。
途中の機械が答えを覚えていて、それを返します。

そして、覚えてよい時間が、答えと一緒に渡されています。
これをTTLといいます。

DNSにおいて、リソースレコードをキャッシュに保持してもよい時間を秒単位で示す31ビットに符号化された整数で、ゼロまたは正の値（0から2147483647の値）を取ります。

秒単位です。

書いてある場所

書いてある場所も示されています。
同じ解説の例では、次のような1行が挙げられています。

www.example.jp. 3600 IN A 192.0.2.1

2番目の3600がTTLです。

この例では、このリソースレコードを受信した側では最大で3600秒（1時間）キャッシュしてよいということを示します。TTLはキャッシュに保持されたのち減少していき、ゼロになると当該リソースレコードがキャッシュから削除されます。

つまり「反映まで時間がかかる」の正体は、この秒数です。
1時間と書いてあれば最大1時間、1日と書いてあれば最大1日、古い答えが各所に残ります。

ゼロという値も取れます。

TTLをゼロに設定した場合には、キャッシュしてはならないことを意味します。

「見つかりません」も、同じように覚えられる

もう1つ、知っておくと混乱しないことがあります。

「見つかりませんでした」という答えも、覚えられます。

DNSにおいて、検索対象が存在しなかったことを示す不在応答のキャッシュです。

DNSでは、通常応答と同様に不在応答もキャッシュし、同じドメイン名やリソースレコードに対する問い合わせを抑制するように作られています。このキャッシュを「ネガティブキャッシュ」と呼びます。

これが効くのは、設定する前に確認してしまった場合です。
新しい名前を作る前に開いてみて、当然ながら見つからない。
そのあと設定しても、しばらく見つからないままになります。

「設定したのに出ない」と言われたとき、その人が設定前に一度開いていないかを聞くと、原因が分かることがあります。

この時間も、自分の側の設定で決まっています。
SOAレコードの解説に、時間を指定する項目の1つとして挙げられています。

Minimum：ネガティブキャッシュのTTLを指定

見に行く場所が分かっていれば、「しばらく」が何秒なのかは調べられます。

切り替えは、先にTTLを下げてから

段取り

ここからが実務です。
TTLは自分で変えられるので、切り替えの前に短くしておきます。

1つ目、切り替えの数日前に、TTLを短くする。

たとえば普段が1日なら、5分程度に下げます。

ここで大事なのは、下げたこと自体が広まるのにも、元のTTLぶんの時間がかかるという点です。
1日と書いてあったなら、短くしたことが行き渡るまでに最大1日かかります。
だから数日前です。

2つ目、切り替える。

TTLが5分になっていれば、古い答えが残るのも最大5分です。

3つ目、落ち着いてから、TTLを元に戻す。

短いままにしておくと、問い合わせが増えます。
切り替えが安定したら戻します。

4つ目、当日の作業は、影響の少ない時間帯に。

5分でも、その5分のあいだは人によって見えるものが違います。

この段取りを知らないまま当日にTTLを短くしても、間に合いません。
効いてくるのは、前に下げておいた場合だけです。

この引っ越しの手順を、1章ぶんを使って通しで書いている本があります。
この記事で引いている用語辞典を出しているJPRSの技術者が書き、監修も同社です。
発行はSBクリエイティブで、424ページのうち第12章が権威サーバーの移行にあてられています。

元に戻すときも、同じ時間がかかる

見落とされがちなところを1つ。

切り替えて、問題が出たので元に戻す、という場面があります。
このとき、戻す操作も同じ仕組みを通ります。
すぐには戻りません。

TTLを下げずに切り替えてしまった場合、戻すのにも同じだけ待つことになります。
「すぐ戻せる」と思っていると、その前提が崩れます。

だから、前もって短くしておく作業は、切り替えのためというより、やり直すための準備です。

切り戻しの判断をいつまでにするかも、先に決めておきます。
決めていないと、待つのか戻すのかが決まらないまま時間が過ぎます。

当日の確認は、3か所で見る

自分のパソコンで見えたかどうかは、あまり当てになりません。
自分の端末は、直した本人がいちばん先に新しい答えを取りに行きます。

確認したいのは、社内の別の端末、社外の回線、携帯回線の3つです。
この3つは、それぞれ別のところで答えを覚えています。

メールも試します。
サイトの行き先とメールの行き先は別のレコードなので、片方だけ確かめても、もう片方は分かりません。

そして、全部が同時に切り替わることはありません。
時間差が出るのが正常です。
「あの人にはまだ古いのが見えている」は、失敗ではなく途中経過です。

自分の画面では正常に見えるのに、ほかの人の側では違う、という形は、ファイルの共有でも起きます。

自分の画面だけでは分からない状態の見分け方は、別の記事で扱っています。
https://note.com/yunta_fukurou/n/n42a8fbd13b62

解約しても、こちらのDNS設定は残る

ここから、閉じるときの話です。

3年前に、期間限定のキャンペーンサイトを作ったとします。
外部のサービスを借りて、自社のドメイン名の下に名前を1つ作って公開しました。

この「名前を1つ作る」が、DNSのどの行にあたるのかは、別の記事で扱っています。
サイトとメールで行き先が別であることと、いちばん外側の名前には別名を置けない決まりをまとめています。
https://note.com/yunta_fukurou/n/n88dd0248f0bc

キャンペーンが終わり、サービスは解約しました。
サイトは開かなくなり、それで終わったつもりでいます。

ある日、そのアドレスを開いた人から連絡が来ます。
知らないページが表示されている、と。

宙ぶらりんになった設定

何が残っていたのか。
用語辞典に、この状態を指す言葉があります。

CNAMEリソースレコードの指定先にWebサーバーが存在しない、親ゾーンの委任情報（NSリソースレコード）の指定先の権威サーバーにゾーンが存在せずlame delegationになっているなど、指定された名前の実体が無効になっているリソースレコードを示す用語として使われることがあります

danglingは「宙ぶらりんの」を意味しています。

指している先が、もう無い。
矢印だけが残っている状態です。

どういうときに生まれるかも書かれています。

リソースレコードがdangling recordsになる例として、外部のCDNサービスやDNSサービスの利用開始時に設定したCNAMEリソースレコードやNSリソースレコードが、利用終了後も残ったままになっている場合が挙げられます。

解約はしたが、自社側の設定は消していない。
これがそのまま当てはまります。

残った行が、他人の看板になる

矢印だけが残っていて、なぜ他人のものになるのか。

用語辞典に、Subdomain Takeoverという項目があります。

CDN（Content Delivery Network）サービスやWebサービスの利用開始時に設定したサブドメインのDNS設定がサービスの利用終了後も残ったままになっていることを利用し、ドメイン名の管理権限を持たない第三者が、そのサブドメインの乗っ取り（テイクオーバー）を図る攻撃手法です。

順番はこうです。

まず、外部サービスを使うときに「この名前を、こちらへ向けてください」と言われ、こちらは別名の行を書きます。
向こうのサービスの側では、その名前を受け付ける設定が作られます。

解約すると、向こう側の設定は消えます。
こちらの行は残ります。
矢印は、受付が無くなった窓口を指したままです。

ここで、そのサービスに誰でも登録できて、同じ名前で受付を作れる状態だった場合、第三者が同じ名前で登録します。
すると、残っていた矢印が、その第三者の作った場所を指します。

解説では、こう書かれています。

事業者側で、解約されたサーバーのドメイン名と同じドメイン名（campaign.example.jp）のサーバーを第三者がCDNサービス上に再設定できるようになっていた場合、Subdomain Takeoverによりドメイン名を乗っ取られる危険性があります。

なぜこれが困るか。
表示されるページは、自社のドメイン名で出ます。
見る人は、自社が出しているものだと思います。

古い手口ではありません。

Subdomain Takeoverは以前から存在する攻撃手法ですが、CDNサービスの普及により、発生事例が増加傾向にあります。

閉じるときは、解約と削除の2つをやる

対策は、解説に直接書かれています。

Subdomain Takeoverを防ぐための根本的な対策として、Webサイトの公開を終了する際、利用していたCDNサービスの解約に加え、Webサイトの公開時に設定したCNAMEリソースレコードやA/AAAAリソースレコードも忘れずに削除することが挙げられます。

解約と、設定の削除は別の作業である、ということです。

外部のDNSサービスを使っていた場合にも、同じことが書かれています。

dangling recordsはSubdomain TakeoverやNS Takeoverに悪用され得るため、利用していた外部サービスを解約する際、設定したCNAMEリソースレコードやNSリソースレコードも削除する必要があります。

実務の手順にすると、こうなります。

外部サービスを解約すると決めたら、解約の前に、そのサービスのために作った行を書き出す。
解約する。
自社側の行を消す。
消したことを確かめる。

順番として、解約より先に「何を作ったか」を思い出せるようにしておくのが要点です。
3年前に誰が何を設定したかは、たいてい誰も覚えていません。

事業者の側の対策についても書かれています。

なお、最近では、外部のCDNサービスやWebサービスを利用する際、利用者が設定するドメイン名に関する管理権限の確認を必須とするなど、事業者側でSubdomain Takeoverの危険性を軽減する対策を実施している場合もあります。

「している場合もあります」であって、全部ではありません。
こちら側で消すのがいちばん確実です。

解約したのに残る、という形は、DNSだけの話ではありません。

消したつもりで残るものが4か所ある、という話は、別の記事で扱っています。
https://note.com/yunta_fukurou/n/n08277ce46aef

ドメイン名の台帳に何を書くか

そこで、台帳の話になります。

1つ目、名前ごとに1行。

www付き、www無し、メール、社内用、期間限定で作ったもの。
全部並べます。

2つ目、その行が何のためにあるか。

用途を日本語で書きます。
「2023年の展示会サイト」のように、時期まで書いておきます。

3つ目、行き先はどこか。
どの会社の、どのサービスか。

ここが空欄の行が、いちばん危ないものです。

4つ目、誰が設定したか。

社内の担当者名と、頼んだ会社名です。
担当者が辞めていれば、そこも書きます。

5つ目、いつまで使うか。

期間限定のものは、終了予定を書きます。
ここを書いておかないと、終わったことに誰も気づきません。

6つ目、ドメイン名そのものの更新期限と、支払っている会社。

名前ごとの話とは別に、ドメイン名自体にも期限があります。
ここが切れると、全部まとめて止まります。

この6つが埋まっていれば、閉じるときに何を消せばよいかが分かります。

まとめ

DNSの答えには、キャッシュに保持してもよい時間が秒単位で付いています。
これをTTLといい、ゼロから2147483647までの値を取ると説明されています。

例として挙げられている3600は、受信した側が最大で1時間まで保持してよいという意味です。
TTLは減っていき、ゼロになるとキャッシュから削除されるとされています。

「見つかりません」という答えも同じように保持されます。
これをネガティブキャッシュといい、その時間はSOAレコードのMinimumで指定されます。
設定前に一度開いてしまうと、しばらく見つからないままになります。

切り替えは、数日前にTTLを短くしてから行います。
短くしたこと自体が行き渡るのにも、元のTTLぶんの時間がかかるためです。

元に戻す操作も同じ時間がかかります。
TTLを下げておく作業は、やり直すための準備でもあります。

当日は、社内の別の端末、社外の回線、携帯回線の3つで見ます。
自分のパソコンは当てになりません。

外部サービスの解約後に残ったDNSの設定は、dangling recordsと呼ばれます。
指定された名前の実体が無効になっている行のことで、danglingは宙ぶらりんを意味すると説明されています。

残った行を利用して、ドメイン名の管理権限を持たない第三者がそのサブドメインの乗っ取りを図る手法が、Subdomain Takeoverです。
CDNサービスの普及により、発生事例が増加傾向にあるとされています。

根本的な対策は、サービスの解約に加えて、公開時に設定した行も忘れずに削除することだと明記されています。
解約と削除は別の作業です。

名前ごとに、用途、行き先、設定した人、いつまで使うか、そしてドメイン名自体の更新期限。
この台帳が、閉じるときの手順書になります。

皆さんの会社のドメイン名は、いまTTLが何秒に設定されているでしょうか。
もう使っていない名前は、残っていないでしょうか。

参考・引用元

キャッシュと時間

JPRS用語辞典「TTL（ティーティーエル）」（株式会社日本レジストリサービス） https://jprs.jp/glossary/index.php?ID=0136
JPRS用語辞典「ネガティブキャッシュ（negative cache）」（同上） https://jprs.jp/glossary/index.php?ID=0177
JPRS用語辞典「SOAリソースレコード」（同上） https://jprs.jp/glossary/index.php?ID=0194

使い終わった設定

JPRS用語辞典「dangling records（ダングリングレコード）」（同上） https://jprs.jp/glossary/index.php?ID=0274
JPRS用語辞典「Subdomain Takeover（サブドメインテイクオーバー）」（同上） https://jprs.jp/glossary/index.php?ID=0267

実務で使う書式について

この連載の内容を、社内でそのまま使える書式にまとめたものを、別のマガジンで公開しています。規程のひな形、対応フロー、チェックシート、報告書式などです。

実務で使う書式・キット
https://note.com/yunta_fukurou/m/mfc25857fab40