2026年8月29日
自前の Unbound と Cloudflare の 1.1.1.1 は、それぞれ別々にキャッシュを持っているため、DNS レコードを変えた直後には「Unbound では新しい値、1.1.1.1 では古い値」のように応答がずれることがあります。二つのキャッシュを直接つなげて同期する仕組みは無いので、整合性を取るには、ずれる幅を小さくする設定にしておき、変更のあとに両方のキャッシュを消す、という二つの手を組み合わせます。この記事では、ずれが起きる理由、差の確かめ方、Unbound を 1.1.1.1 への転送役にする構成、TTL に関わる設定の見直し、変更作業のときの手順を説明します。
なぜ応答がずれるのか
キャッシュDNS は、権威DNS から受け取った応答を TTL の秒数だけ保存し、その間は同じ答えを返します。Unbound と 1.1.1.1 は、権威DNS に問い合わせた時刻がそれぞれ違うため、レコードの変更の前に取得した側は TTL が切れるまで古い値を返し続けます。これが、ずれのいちばん多い原因です。
ほかに、次の原因もあります。
- 存在しない名前の記録（ネガティブキャッシュ）：レコードを作る前にその名前を問い合わせると、「存在しない」という答えがしばらく保存されます。保存の時間は、ゾーンの SOA レコードの値をもとに決まります。
- Unbound の設定が TTL を変えている：
cache-min-ttlで最低の保存時間を延ばしている、serve-expiredで期限切れの応答を返している、などの場合です。 - 1.1.1.1 側が一つのキャッシュではない：1.1.1.1 は世界中の拠点で応答しており、拠点ごとにキャッシュの状態が違うことがあります。場所によって結果が違って見えるのはこのためです。
- DNSSEC の検証の違い：署名に問題があるゾーンでは、検証する側だけが SERVFAIL を返します。Unbound で検証を有効にしているかどうかで、結果が変わります。
まず差を確かめる
Unbound、1.1.1.1、権威DNS の三者に同じ質問をして、答えと TTL を比べます。
# Unbound（同じサーバー上で動いている場合）
dig @127.0.0.1 www.example.com A
# 1.1.1.1
dig @1.1.1.1 www.example.com A
# 権威DNS に直接（キャッシュを通さない正解）
NS=$(dig +short NS example.com | head -n 1)
dig @"$NS" www.example.com A +norecurseANSWER SECTION の値と、その左の数字（残りの TTL）を見ます。権威DNS と同じ値を返している側が新しく、違う値の側は、表示されている残り秒数が過ぎるまで古い値を返します。status: NXDOMAIN が出ている場合は、ネガティブキャッシュが残っています。
Unbound の中身は unbound-control で確かめられます。
# キャッシュにある該当の記録を探す
sudo unbound-control dump_cache | grep 'www.example.com'
# その名前をどのサーバーに問い合わせるか
sudo unbound-control lookup www.example.comunbound-control を使うには、設定の remote-control: で control-enable: yes にしておく必要があります。配布形態によっては、鍵の作成（unbound-control-setup）も必要です。
方法1：Unbound を 1.1.1.1 への転送役にする
Unbound が自分で権威DNS をたどる（フルリゾルバーとして動く）と、1.1.1.1 とは別に権威DNS へ問い合わせるため、二つのキャッシュは独立して動きます。社内や自宅の Unbound の応答を 1.1.1.1 に寄せたいなら、問い合わせをすべて 1.1.1.1 に転送する構成にします。
server:
# 転送先と TLS で通信するための CA 証明書（パスは環境に合わせる）
tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt
forward-zone:
name: "."
forward-tls-upstream: yes
forward-addr: 1.1.1.1@853#cloudflare-dns.com
forward-addr: 1.0.0.1@853#cloudflare-dns.com転送の構成では、Unbound は 1.1.1.1 から受け取った答えを、そのとき残っていた TTL で保存します。そのため Unbound の答えが 1.1.1.1 より長く古いまま残ることは起きにくく、ずれの幅はおおむね元の TTL の範囲に収まります。
一方で、1.1.1.1 が止まると Unbound も答えられなくなります。転送先が応答しないときに自分で権威DNS をたどらせる forward-first: yes もありますが、その場合はまた独立したキャッシュが生まれます。どちらを優先するか（一致させることか、止まらないことか）を決めてから選んでください。設定を変えたら、unbound-checkconf で書式を確かめてから反映します。
方法2：TTL を変える設定を見直す
整合性を優先するなら、Unbound が権威DNS の決めた TTL をそのまま使うようにします。見直す項目は次のとおりです。
- cache-min-ttl：既定は 0 です。これを大きくすると、短い TTL のレコードも長く保存され、変更が反映されるまでの時間が延びます。整合性を取りたい環境では 0 のままにします。
- cache-max-ttl：保存時間の上限です。既定は 1日（86400秒）です。小さくすると、TTL の長いレコードでもずれる時間の上限が短くなります。そのぶん問い合わせは増えます。
- cache-max-negative-ttl：「存在しない」という答えの保存時間の上限です。レコードの追加が多い環境では短めにすると、追加直後の名前が見えない時間を減らせます。
- serve-expired：有効にすると、期限が切れた記録を返しながら裏で更新します。応答は速くなりますが、古い値を返す場面が増えます。使う場合は
serve-expired-ttlで期限切れの記録を返す上限を決めます。 - prefetch：期限が近い記録を早めに取り直します。古い値を返す時間が延びるものではないので、整合性の面では問題になりにくい設定です。
既定値や項目の名前は版によって変わることがあるため、使っている版の man unbound.conf で確かめてください（2026年10月現在）。
方法3：変更のあとに両方のキャッシュを消す
設定でずれを小さくしても、変更の直後は TTL の分だけ古い値が残ります。急ぐときは、両方のキャッシュを消します。
# 名前を指定して消す（A、AAAA、MX などの主なタイプ）
sudo unbound-control flush www.example.com
# タイプを指定して消す
sudo unbound-control flush_type www.example.com TXT
# ゾーンの中をまとめて消す（キャッシュが大きいと時間がかかる）
sudo unbound-control flush_zone example.com
# 「存在しない」の記録をすべて消す
sudo unbound-control flush_negativeunbound-control reload は設定を読み直しますが、キャッシュもすべて消えます。名前を絞って消したいときは flush 系の命令を使います。
1.1.1.1 側は、自分で直接消すことはできませんが、Cloudflare が 1.1.1.1 のキャッシュ削除（Purge Cache）を依頼するページを公開しています。名前とレコードのタイプを指定して依頼します。反映の範囲や仕様は変わることがあるため、Cloudflare の説明で確かめてください。
レコードを変更するときの手順
ずれを小さくするには、変更の前から準備します。
- 変更する予定のレコードの TTL を、短い値（例: 300秒）に下げる
- 元の TTL の時間が過ぎるまで待つ（この間に、両方のキャッシュが短い TTL の記録に入れ替わります）
- レコードを変更する
- 権威DNS に
+norecurseで問い合わせ、新しい値になったことを確かめる - Unbound で
flushを行い、必要なら 1.1.1.1 の削除も依頼する - Unbound と 1.1.1.1 の両方で新しい値が返ることを確かめ、落ち着いたら TTL を元に戻す
新しい名前を追加する場合は、追加する前にその名前を問い合わせないようにすると、ネガティブキャッシュによるずれを避けられます。
端末側のキャッシュも忘れない
Unbound と 1.1.1.1 がそろっても、端末の OS やブラウザがさらにキャッシュを持っていると、古い値が見えることがあります。Linux の systemd-resolved なら resolvectl flush-caches、Windows なら ipconfig /flushdns で消せます。確認のときは、端末のキャッシュを通さない dig @127.0.0.1 のような直接の問い合わせで見ると、どの層が古いのかを切り分けられます。
まとめ
- Unbound と 1.1.1.1 のキャッシュは独立しており、直接同期する方法はありません。ずれの幅を小さくする設定と、変更後のキャッシュ削除を組み合わせます。
- 応答を 1.1.1.1 に寄せたいなら、Unbound を 1.1.1.1 への転送役にします。止まりにくさとの兼ね合いを決めてから選びます。
cache-min-ttlを上げない、serve-expiredの扱いを決めるなど、TTL を変える設定を見直します。- 変更の前に TTL を下げて待ち、変更後に
unbound-control flushと 1.1.1.1 の削除の依頼で揃えます。