DNSSECで署名したゾーンでも、サブドメインのCNAMEはそのまま使えます。ただし、DNSKEYが置かれるゾーンの頂点（example.com）にはCNAMEを置けず、CNAMEの向け先が別のドメインにある場合は、その先の署名状態によって検証結果が変わります。この記事では、DNSKEYとCNAMEの位置関係、署名付きゾーンでCNAMEを追加・変更する手順、検証で失敗したときの切り分け方を説明します。
DNSKEYとCNAMEはどこに置かれるのか
DNSKEYレコードは、ゾーンの署名に使う公開鍵を載せたもので、ゾーンの頂点に置かれます。頂点には他にSOAとNSもあります。一方、CNAMEは「この名前は別の名前の別名」と宣言するレコードで、同じ名前に他の種類のレコードを置けないという決まりがあります（RFC 1034、RFC 2181）。
このため、次の2点が基本になります。
- 頂点にCNAMEは置けない: 頂点にはDNSKEY・SOA・NSがあるので、CNAMEと同居できない。頂点を別名にしたい場合は、DNSサービス独自のALIAS・ANAME・CNAMEフラット化を使う
- サブドメインのCNAMEは問題ない:
www.example.comなどのCNAMEは、頂点のDNSKEYに対応する鍵で署名される
例外として、DNSSECの署名（RRSIG）と、存在しないことの証明に使うNSECは、CNAMEと同じ名前に置けます（RFC 4035）。署名済みゾーンのCNAMEには、DNSサービスや署名ツールがこれらを自動で付けます。手で追加するものではありません。
署名付きゾーンでCNAMEが検証される流れ
検証するキャッシュDNS（Google Public DNSやCloudflareの1.1.1.1など）は、www.example.com を引いたとき次の順に確かめます。
www.example.comのCNAMEに付いたRRSIGを、example.comのDNSKEYで検証するexample.comのDNSKEYを、親ゾーン（.comなど）に登録されたDSと照合する- CNAMEの向け先（例:
xxx.cdn.example.net）を改めて引き、その向け先のゾーンについても同じ検証を行う
向け先のゾーンがDNSSECに対応していない場合、3の段階は「署名なし（insecure）」として扱われ、答えは返ります。エラーにはなりませんが、ブラウザに届く最終的なIPアドレスは署名で保護されていない、という意味です。CDNやSaaSの多くは向け先を署名していないため、これは珍しい状態ではありません。
問題になるのは、向け先のゾーンが署名済みなのに検証に失敗する（bogus）場合です。このときキャッシュDNSはSERVFAILを返し、利用者からはサイトが引けなくなります。
CNAMEを追加・変更する手順
1. 現在の状態を確かめる
作業前に、ゾーンのエクスポートか管理画面の写しで、対象の名前のレコードを控えます。続いて、署名とDSの状態を確認します。
# 頂点のDNSKEYと親のDSを見る
dig example.com DNSKEY +dnssec +multi
dig example.com DS +short
# 対象の名前に他のレコードが無いか、権威DNSに直接聞く
dig @ns1.example-dns.net www.example.com ANY +noall +answer
dig @ns1.example-dns.net www.example.com A +noall +answer
dig @ns1.example-dns.net www.example.com TXT +noall +answerANYは応答を絞るサーバーが多いため、A・TXT・MXなど種類ごとにも問い合わせます。CNAMEを置く予定の名前にTXTやMXが残っていると、管理画面で登録を拒否されるか、サービスによっては片方が無視されます。
2. CNAMEを登録する
DNSサービスの管理画面でCNAMEを追加します。DNSSECをDNSサービス側で署名している場合（多くのクラウドDNSはこの方式です）、署名は保存と同時に自動で作られます。BINDなどで自分で署名している場合は、ゾーンファイルを編集した後に再署名と再読み込みが必要です。自動署名の設定（BINDの dnssec-policy など）をしていれば、変更を読み込むだけで署名されます。
3. 署名付きで返るか確かめる
# CNAMEにRRSIGが付いているか（権威DNSに直接）
dig @ns1.example-dns.net www.example.com CNAME +dnssec +noall +answer
# 検証するキャッシュDNS経由で ad フラグが付くか
dig @1.1.1.1 www.example.com A +dnssec
# 手元で検証する（BIND付属のツール）
delv www.example.com Aad フラグは、キャッシュDNSが検証に成功したことを示します。向け先が署名されていないCNAMEでは、最終的な答えに ad が付かないことがあり、これは上で説明した「署名なし」の状態です。delv は検証結果を「fully validated」「unsigned answer」などと表示するので、どこまで署名が続いているかを読み取りやすくなります。
検証に失敗したときの切り分け
SERVFAILが返る場合は、次の順で原因を絞ります。
検証を外すと引けるか
dig @8.8.8.8 www.example.com A # 通常
dig @8.8.8.8 www.example.com A +cd # 検証を外す+cd を付けると引けて、付けないとSERVFAILなら、DNSSECの検証失敗です。+cd でも引けないなら、DNSSECではなくレコードや委任の問題です。
どちらのゾーンで失敗しているか
自分のゾーン（example.com）と、向け先のゾーンを分けて調べます。DNSVizなどの可視化ツールに両方のドメインを入力すると、鍵と署名のつながりのどこが切れているかが図で分かります。
- 自分のゾーンで失敗: 親のDSと現在のDNSKEYが合っていない例が多い。DNSサービスを移した、DNSSECを一度無効にして有効にし直した、などの後に起きやすい。レジストラに登録したDSを、現在の鍵に合わせて登録し直す
- 向け先のゾーンで失敗: 自分では直せないため、CDNやサービスの提供元に連絡する。急ぐ場合は、向け先をAレコードに一時的に置き換える方法もある（IPが変わる向け先では使えない）
署名の有効期限が切れていないか
自分で署名している場合、RRSIGには有効期限があり、自動の再署名が止まっていると期限切れで検証に失敗します。dig +dnssec の出力でRRSIGの日付を確かめます。
WordPressサイトでの注意
www をCDNに向けるCNAMEを追加した後は、WordPressのサイトアドレスと、CDNに登録したホスト名が一致しているかを確認します。SSL証明書の発行に使う検証用レコード（CNAMEやTXT）を別名で追加する場合も、上と同じ確認で署名付きで返るかを見ておくと、証明書の更新時に検証で止まる事態を防げます。DNSの変更前には、ゾーンのバックアップを取っておきます。多くのDNSサービスはゾーンのエクスポート機能を備えていますが、画面の名称や場所はサービスごとに違い、変わることもあります（2026年10月現在）。
まとめ
- DNSKEYは頂点にあるため、頂点にCNAMEは置けない。サブドメインのCNAMEは署名付きゾーンでも普通に使える
- CNAMEの署名はDNSサービスや署名ツールが自動で付ける。RRSIGとNSECは同じ名前に置ける例外
- 向け先が未署名なら「署名なし」として答えは返る。SERVFAILになるのは検証失敗のとき
+cdの有無で比べ、自分のゾーンか向け先のゾーンかを分けて原因を探す