2026年6月12日

CNAMEレコードを削除する方法｜使われていないCNAMEの洗い出しと、管理画面・API・ゾーンファイルでの消し方

DNS・名前解決

不要になったCNAMEレコードは、向け先がまだ生きているか、誰が何のために作ったかを確かめてから、DNSサービスの管理画面・API・ゾーンファイルのいずれかで削除します。この記事では、ゾーン内のCNAMEを一覧にして「消してよいもの」を見分ける手順と、方式ごとの消し方とつまずきやすい点、削除後の確かめ方までを説明します。1件だけを消す作業というより、長く運用してきたドメインのCNAMEをまとめて整理したい人に向けた内容です。

なぜ不要なCNAMEを整理するのか

CNAMEは「この名前は別の名前の別名」という指示なので、向け先のサービスを解約しても自動では消えません。残ったままのCNAMEには次の問題があります。

サブドメインの乗っ取り: 解約済みのクラウドサービスやホスティングを指したCNAMEが残っていると、第三者がそのサービスで同じ名前を登録し、あなたのサブドメインで別のページを表示できてしまう場合があります。英語では dangling CNAME（宙に浮いたCNAME）、subdomain takeover と呼ばれます
証明書や認証の誤作動: 古い検証用CNAMEが残っていると、どれが現役の設定なのか分からなくなり、更新時の切り分けに時間がかかります
管理コスト: 用途の分からない行が多いゾーンは、移転や障害対応のたびに確認の手間が増えます

整理の目的は「消すこと」ではなく、「今使っているものだけが残っている状態にすること」です。用途が分からない行は、確かめるまで消さないでください。

手順1：ゾーンを控え、CNAMEを一覧にする

最初に、現在のゾーン全体を控えます。誤って現役の行を消したときに同じ値で戻すためです。多くのDNSサービスにはゾーンファイルのエクスポート機能があります。項目名や場所はサービスごとに違い、変わることもあります（2026年10月現在）。

Route 53 を使っている場合は、AWS CLI でCNAMEだけを取り出せます。

# ホストゾーン内のCNAMEだけを表示する
aws route53 list-resource-record-sets \
  --hosted-zone-id ZXXXXXXXXXXXXX \
  --query "ResourceRecordSets[?Type=='CNAME'].[Name,TTL,ResourceRecords[0].Value]" \
  --output text

BINDなどを自分で運用しているなら、ゾーンファイルをコピーしておき、CNAMEの行を抜き出します。

cp /etc/bind/zones/example.com.zone /root/backup/example.com.zone.$(date +%Y%m%d)
grep -E '\sCNAME\s' /etc/bind/zones/example.com.zone

一覧ができたら、表計算ソフトなどに「名前・向け先・用途・担当者・判定」の列を作って書き写します。この表が、後で「なぜ消したか」を説明する記録になります。

手順2：向け先が生きているかを確かめる

次に、各CNAMEの向け先を問い合わせます。dig でCNAMEの名前そのものを引くと、CNAMEをたどった先の結果まで表示されます。

dig old-shop.example.com A +noall +answer +comments

結果の見方は次のとおりです。

CNAMEの行の後にAやAAAAが返る: 向け先は名前として存在しています。ただし、それだけでは「あなたのサービスとして」使われているとは限りません
CNAMEの行だけが返り、ステータスが NXDOMAIN: 向け先の名前がもう存在しません。解約済みのサービスを指している可能性が高く、乗っ取りの危険がある典型的な状態です
ステータスが SERVFAIL: 向け先側のDNSに障害があるか、DNSSECの検証に失敗しています。一時的なものか、時間をおいて確かめます

向け先が名前として存在していても、ブラウザで開くと「このドメインは設定されていません」のようなサービス側の既定ページが出る場合は、契約が残っていない可能性があります。サービスの管理画面で、その独自ドメインが自分のアカウントに登録されているかを確かめます。

手順3：用途ごとに「消してよいか」を判断する

向け先の名前から、用途の見当をつけます。よくあるのは次の種類です。

Webサイトの別名: www や shop などをホスティングやCDNに向けるもの。アクセスログで今もその名前へのアクセスがあるかを見ます
証明書の検証用: 先頭がアンダースコアで始まる名前（例: _xxxxxxxx.example.com）は、証明書サービスのドメイン検証に使われていることが多い名前です。証明書の自動更新に使っている間は消せません
メール送信の認証用: selector._domainkey.example.com のような名前はDKIMの公開鍵をメール配信サービスに向けるためのものです。消すと送信メールの認証が失敗します
社内ツールやSaaSの独自ドメイン: ヘルプデスクやフォームサービスなど。担当部署に確認します

判断に迷うものは、すぐには消さず「保留」にします。どうしても持ち主が分からない場合は、関係者に告知して期限を決め、期限を過ぎてから消すと安全です。消す数日前にTTLを300秒程度に下げておけば、問題が出て同じ値で戻したときも、戻した結果が早く行き渡ります。

手順4：方式ごとに削除する

管理画面で削除する

レコード一覧から対象の行を選んで削除します。表示がドメインを省いた形（old-shop など）になっている画面が多いので、似た名前の行と取り違えないよう、向け先の値も見比べてから操作します。一度に多くの行を消すより、用途の近いものごとに数件ずつ消し、そのたびに確かめるほうが、問題が出たときに原因を絞り込めます。

API・CLIで削除する

Route 53 では、削除（DELETE）の指示に現在のレコードと同じ名前・種類・TTL・値をそろえて書く必要があります。どれか1つでも違うと、削除は拒否されます。手順1で取り出した値をそのまま使うのが確実な方法です。

{
  "Comment": "remove unused CNAME",
  "Changes": [
    {
      "Action": "DELETE",
      "ResourceRecordSet": {
        "Name": "old-shop.example.com.",
        "Type": "CNAME",
        "TTL": 3600,
        "ResourceRecords": [{ "Value": "old-shop.example-saas.net" }]
      }
    }
  ]
}

aws route53 change-resource-record-sets \
  --hosted-zone-id ZXXXXXXXXXXXXX \
  --change-batch file://delete-cname.json

Cloudflare のAPIでは、まずレコードのIDを調べ、そのIDを指定して削除します。トークンはDNSの編集に必要な権限だけを持つものを使い、スクリプトに直接書かず環境変数などから読み込みます。

# レコードIDを調べる
curl -s "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records?type=CNAME&name=old-shop.example.com" \
  -H "Authorization: Bearer $CF_API_TOKEN"

# IDを指定して削除する
curl -s -X DELETE "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/$RECORD_ID" \
  -H "Authorization: Bearer $CF_API_TOKEN"

APIの引数や応答の形式は改訂されることがあるため、実行前に各サービスの公式ドキュメントで確かめてください。

ゾーンファイルで削除する（BINDなど）

該当行を消し、SOAのシリアル番号を上げてから構文を確かめ、再読み込みします。シリアルを上げ忘れるとセカンダリDNSに変更が伝わりません。動的更新（nsupdate）を有効にしているゾーンでは、ファイルを直接書き換える前に rndc freeze で更新を止め、編集後に rndc thaw で戻します。

named-checkzone example.com /etc/bind/zones/example.com.zone
rndc reload example.com

手順5：削除後に確かめ、記録を残す

削除したら、ドメインの権威DNSに直接問い合わせます。

dig example.com NS +short
dig @ns1.example-dns.net old-shop.example.com CNAME +noall +answer +comments

ステータスが NXDOMAIN、または NOERROR で答えが空なら、権威DNSからは消えています。権威DNSが複数ある場合は、すべてで同じ結果になるかを見ます。公開DNS（8.8.8.8 など）では、削除前のTTLが切れるまで古いCNAMEが返ることがありますが、これは時間がたてば解消します。

最後に、手順1の表へ削除日と確かめた結果を書き込みます。半年に1回など時期を決めて同じ手順で見直すと、不要なCNAMEがたまりにくくなります。サービスを解約するときは「CNAMEを先に消し、その後にサービス側の設定を消す」順にすると、乗っ取りの隙が生まれません。

WordPressサイトで確かめること

削除したCNAMEがサイトの別名（www やサブドメインのサイト）だった場合は、その名前へのリンクが記事内やメニューに残っていないか、リダイレクト設定が古い名前を参照していないかを確かめます。マルチサイトでサブドメイン型を使っているなら、削除した名前がサイトのドメインとして登録されていないかも見ておきます。

まとめ

削除の前にゾーンを控え、CNAMEを一覧にして用途・担当・判定を記録する
向け先が NXDOMAIN を返すCNAMEは、解約済みサービスを指している可能性が高く、乗っ取り対策として優先して整理する
先頭がアンダースコアの名前や _domainkey は証明書・メール認証で現役のことが多く、確認なしに消さない
Route 53 のAPIでは名前・種類・TTL・値をそろえて DELETE する。Cloudflare はレコードIDを指定する
削除後は権威DNSで消えたことを確かめ、定期的な見直しの記録を残す