同じ名前に CNAME と A レコード（や MX・TXT など、ほかのレコード）を一緒に置いてはいけないのは、CNAME が「この名前は別名で、すべての種類の情報は向き先の名前にある」という意味を持ち、ほかのレコードと同居すると答えが矛盾するためです。DNS の規格（RFC 1034・RFC 2181）でも禁止されており、多くの DNS サービスは登録を拒否し、BIND はゾーンの読み込み自体を失敗させます。この記事では、禁止されている理由、混在させたときに起きる不具合、衝突しやすい場面と正しい置き換え方、既存のゾーンから衝突を見つける方法を解説します。
何が禁止されているのか
禁止されているのは、同じ名前に CNAME とほかのデータを置くことです。
; NG：同じ www に CNAME と A
www.example.com. 3600 IN CNAME site.example-cdn.net.
www.example.com. 3600 IN A 192.0.2.10
; NG：同じ shop に CNAME と TXT
shop.example.com. 3600 IN CNAME shops.example-saas.net.
shop.example.com. 3600 IN TXT "verification=your-token"
; OK：名前が違えば問題ない
example.com. 3600 IN A 192.0.2.10
www.example.com. 3600 IN CNAME example.com.RFC 1034 は、CNAME がある名前にはほかのデータを置かないと定め、RFC 2181 もこれを改めて確認しています。また、1つの名前に置ける CNAME は1つだけです。例外は DNSSEC の署名などに使う RRSIG・NSEC レコードで、これは DNSSEC の規格（RFC 4035）が CNAME との同居を認めています。利用者が自分で登録するレコードについては「CNAME を置いた名前には、ほかに何も置かない」と覚えておけば十分です。
なぜ一緒に置けないのか
キャッシュ DNS が www.example.com の A レコードを探していて CNAME を見つけると、www.example.com について調べるのをやめ、向き先の site.example-cdn.net について最初から問い合わせ直します。これは A に限らず、MX でも TXT でも同じです。CNAME は特定の種類だけの転送ではなく、名前そのものの付け替えだからです。
もし同じ名前に A レコードもあると、「www の情報は CDN 側の名前にある」と「www の IP アドレスはここにある」という2つの答えが同時に存在することになります。どちらを使うかはソフトウェアやキャッシュの状態で変わり、次のような食い違いが起こります。
- CNAME をキャッシュしたリゾルバーは、A の問い合わせにも CNAME をたどった答えを返す
- 先に A をキャッシュしたリゾルバーは、同じ名前で A をそのまま返す
- MX や TXT の問い合わせでは、CNAME の向き先にある MX・TXT が使われ、自分で置いたレコードが無視される
利用者によって接続先が変わる、メールやドメイン認証がときどきだけ失敗する、といった再現しにくい不具合になるため、規格で禁止されています。
混在させると実際に起きること
登録できない：Cloudflare、Amazon Route 53、レンタルサーバーの DNS 画面の多くは、CNAME がある名前にほかのレコードを追加しようとするとエラーを表示します。画面の表記はサービスごとに異なります（2026年10月現在）。
ゾーンが読み込めない：BIND では、ゾーンファイルに混在があると named-checkzone が「CNAME and other data」というエラーを出し、そのゾーンの読み込みに失敗します。起動時であればそのゾーン全体が応答しなくなり、混在した1行のせいで、関係の無い MX や他のサブドメインまで止まる可能性があります。
受け付けてしまう環境でも不安定：古いソフトウェアや一部のサービスは登録を受け付けることがありますが、前の節のとおり答えが一定しません。
ドメインの頂点にCNAMEを置けない理由
example.com のようなドメインの頂点（ゾーンエイペックス）には、ゾーンの基本情報である SOA と NS レコードが欠かせない要素として存在します。そこに CNAME を置くと SOA・NS との混在になるため、頂点には CNAME を置けません。頂点には MX や、各種サービスの所有権確認用の TXT も置かれることが多いので、二重の意味で衝突します。
「サイトの頂点を、ホスト名で案内された CDN やホスティングに向けたい」という場面で、この制約がよく問題になります。
衝突しやすい場面と正しい置き換え方
ドメインの頂点をCDNやホスティングに向けたい
次のどちらかで対応します。
- A／AAAA レコードを直接書く：サービス側が頂点用の固定 IP アドレスを案内している場合は、それを A（と AAAA）に登録します
- DNS サービス独自の機能を使う：Cloudflare の CNAME フラット化、Route 53 のエイリアスレコード、ALIAS・ANAME などの名前で提供される機能です。権威 DNS が向き先の IP アドレスを調べ、A／AAAA として返すため、規格上の衝突を起こしません。ただし、標準のレコードではないので DNS サービスを移るときに同じ設定ができるとは限らず、地域ごとに最適な IP アドレスを返す CDN では精度が変わる場合があります。仕様は各サービスのドキュメントで確認してください
WordPress サイトでは、頂点と www のどちらを正規の URL にするかを先に決め、もう一方からリダイレクトする構成にすると、DNS の設定も単純になります。www を正規にすれば、www は CDN への CNAME、頂点はリダイレクト用の A レコード、という分け方ができます。
CNAMEを置いた名前にTXTやMXが必要になった
ドメイン認証の TXT やメール用の MX を、CNAME と同じ名前に求められた場合は、CNAME をやめて A レコードにするか、サービスに別の名前（_verify.shop のような専用の名前など）で認証できないかを確認します。
サーバー移行でCNAMEをAレコードに変えたい
多くの管理画面では、レコードの種類をその場で変えられず、CNAME を削除してから A を追加することになります。削除から追加までの間は名前が引けなくなり、その間に問い合わせたリゾルバーには「存在しない」という答えがキャッシュされます。
- 数日前に CNAME の TTL を300秒程度まで下げておく
- 追加する A レコードの値を手元に用意してから作業を始める
- CNAME の削除と A の追加を続けて行う
- 権威 DNS に直接問い合わせて、A が返ることを確認する
作業前に、変更するレコードの内容を控えておくと、問題があったときにすぐ戻せます。
既存のゾーンから衝突を見つける
自分の管理するゾーンに混在が無いかは、次の方法で確かめられます。
# 名前ごとに CNAME と他の種類を権威DNSに直接聞く
NS=ns1.example-dns.net
for name in example.com www.example.com shop.example.com; do
for t in CNAME A AAAA MX TXT; do
printf '%-20s %-6s ' "$name" "$t"
dig @"$NS" "$name" "$t" +norec +noall +answer | awk -v n="$name." -v t="$t" '$1==n && $4==t {$1=$2=$3=$4=""; printf "%s ", $0}'
echo
done
done
# BIND形式のゾーンファイルがあれば、まとめて検査
named-checkzone example.com db.example.com1つの名前で CNAME の行に値があり、ほかの種類にも値が出ていれば混在しています。DNS サービスの中には、ゾーンを BIND 形式で書き出す機能や API を持つものがあり、書き出したファイルを named-checkzone にかければ、全レコードをまとめて検査できます。
まとめ
- CNAME は名前そのものの付け替えなので、同じ名前にほかのレコードがあると答えが矛盾する
- RFC 1034・RFC 2181 で禁止されており、DNS サービスは登録を拒否し、BIND はゾーンの読み込みに失敗する
- ドメインの頂点には SOA・NS があるため CNAME を置けない。A／AAAA か、CNAME フラット化・エイリアスなどの独自機能を使う
- CNAME から A への切り替えは、TTL を下げてから削除と追加を続けて行う
digで種類ごとに権威 DNS へ問い合わせるか、named-checkzoneで既存の衝突を見つける