別商品がサブドメインを足しただけで、他のAレコードが消えた（お名前.com／01.dnsv.jp はゾーン全体を送信）

結論

お名前.comのDNSレコード設定画面は、編集した1件だけでなく、その時点で画面が持っているゾーン全体をまとめて送信します。 自社が運用する複数の小さなWebサービスが同じレジストラの同じゾーンを共有しているとき、片方の担当作業がもう片方のサブドメインのAレコードを黙って消しました。しかもHTTP監視はDNSリゾルバのキャッシュに守られて数分は200を返し続けたため、その場では気づけませんでした。

症状

2026-08-14、自社の複数のWebサービスが同居している rebounder.jp のゾーンに、あるサービス用のサブドメインを新規に追加する作業をしていました。作業自体は成功し、追加したサブドメインは正常に名前解決できるようになりました。

ところが、その少し後になって、追加とは無関係の別サービスのサブドメインのAレコードが消えていることに気づきました。該当サブドメインは以前から使われていたもので、その日に誰かが意図して触った記録はありません。

厄介だったのは、Aレコードが実際に消えたあとも、しばらくの間はHTTPでの死活監視が200を返し続けていたことです。ブラウザやCIランナーが使うDNSリゾルバは、TTLが切れるまで直前まで有効だった古いAレコードをキャッシュしたまま応答するため、権威DNSサーバへ直接問い合わせない限り、レコードが消えたこと自体を検知できませんでした。

原因

お名前.comのDNSレコード設定画面は、レコードを1件追加・削除するための操作画面に見えますが、実際に送信されるリクエストはその時点で画面が保持しているゾーン全体の一覧です。つまり、画面を開いた時点のゾーンの控えをもとに1件を書き足して送信すると、サーバ側はその控え全体で既存のゾーンを置き換えます。

この挙動が事故につながる条件は次の2つが重なることです。

1. 同じゾーンを、複数の担当者・複数の商品の運用担当が別々のタイミングで編集する。
2. どちらかの担当が、もう一方の変更が反映される前の古い控えの状態で画面を開いたまま、自分の変更だけを足して送信する。

このとき、後から送信された側の控えには、先に追加されていたはずのレコード（あるいは先に存在していた別サービスのレコード）が載っていません。送信するとその控えがゾーンの新しい全体像として扱われるため、控えに載っていなかったレコードは結果的に消えます。 悪意や誤操作ではなく、「画面を開いていた時点」と「送信した時点」のあいだにズレがあれば起こりうる仕様上の挙動です。

さらに、この挙動を見つけにくくしているのがHTTP監視とDNSキャッシュの組み合わせです。Aレコードが権威DNSサーバ上では既に消えていても、各所のリゾルバがTTLの範囲内で古い値をキャッシュしていれば、HTTPの死活監視は変わらず200を返します。「監視は緑のまま、権威DNSだけが変わっている」という状態が、TTLが切れるまで続きます。

直す

権威DNSサーバに対して直接問い合わせ、期待するAレコードと一致するかどうかをHTTP監視の前段に加えました。

A=$(dig +short <サブドメイン> @01.dnsv.jp | head -1)
[ "$A" = "<期待するIPアドレス>" ] || echo "🔴 Aレコードが消えたか変わった"

01.dnsv.jp はお名前.comの標準DNSが使う権威DNSサーバの1つです。dig にリゾルバではなくこの権威DNSサーバを明示的に指定するのがポイントです。手元やCIランナーのデフォルトリゾルバに問い合わせると、レコードが消えた直後もキャッシュ経由で古い値が返ってきてしまい、検知が遅れます。権威DNSサーバへ直接聞くことで、リゾルバのキャッシュに隠れている間の遅延なしに、ゾーンの現在の状態を確認できます。

再発防止

このチェックを追加した時点のコミットログには、追加の理由として「ゾーンの相乗り編集で消える事故が実際に起きた」と明記されています。恒久対応として選んだのは、レジストラ側の画面の仕様を変えることではなく、自分たちの監視の側に権威DNSへの直接確認を1行加えることでした。同じゾーンを複数の担当・複数の商品が編集する構成そのものは変えていません。ゾーンを分離する、あるいは編集を一本化するといった構成変更までは踏み込んでおらず、次に同じ画面で誰かが古い控えのまま送信すれば、この監視が検知するまでの間は再び同じ形でレコードが消えます。