ALIASレコードとDNSKEYレコードは、どちらもゾーンの頂点（example.com）に置けます。ALIASは応答の時点でAレコード・AAAAレコードに置き換えて返されるため、DNSKEY・SOA・NSと衝突しないからです。ただし、ALIASの答えは向け先に合わせてその場で作られるので、DNSSECの署名も応答のたびに作れる構成（オンライン署名）でないと成り立ちません。この記事では、ALIASとDNSKEYが同居できる理由、使える署名方式と使えない署名方式、セカンダリDNSや複数のDNSサービスを組み合わせるときの注意、鍵の更新時に確かめることを説明します。
頂点でALIASとDNSKEYが同居できる理由
頂点にCNAMEを置けないのは、CNAMEが同じ名前に他のレコードを置くことを許さない一方で、頂点にはSOA・NS・DNSKEYが必要だからです。ALIAS（サービスによってはANAMEやCNAMEフラット化と呼びます）は、この制約を避けるためのDNSサービス独自の機能です。標準の規格ではなく、動きはサービスごとに異なります（2026年10月現在）。
利用者から見える応答は、ふつうのA・AAAAレコードです。
example.comのAを問い合わせると、DNSサービスが向け先を引いて得たIPアドレスと、それに付けた署名（RRSIG）が返るexample.comのDNSKEYを問い合わせると、鍵の一覧とその署名が返る
応答の上ではALIASという種類は現れないので、DNSKEYと並んでも規格上の問題はありません。
署名方式で、使えるかどうかが決まる
DNSSECの署名には、大きく2つの方式があります。
- 事前署名: ゾーン全体をあらかじめ署名しておき、署名済みのデータをそのまま配る。BINDの自動署名などがこの方式
- オンライン署名: 問い合わせのたびに、権威DNSがその場で署名を作る。多くのクラウドDNSや、PowerDNSのように鍵を権威DNSが持つ構成がこの方式
ALIASの答えは向け先のIPが変わるたびに変わるため、事前署名では古い署名と新しいIPが食い違います。ALIASとDNSSECを両立させるには、オンライン署名に対応したDNSサービスかソフトウェアを選ぶ必要があります。
選ぶときは、次の点をドキュメントで確かめます。
- ALIAS（またはそれに当たる機能）を、DNSSEC有効のゾーンで使えると明記しているか
- 向け先にAAAAが無いときなど「その種類は無い」という答えにも、署名付きの否定応答（NSECやNSEC3）を返すか
- 頂点のALIASを使うと、DNSSECの有効化が拒否される制限が無いか
Route 53のエイリアスレコードや、ALIAS機能を持つ他のDNSサービスでも、DNSSECとの組み合わせ方や制限はサービスごとに違い、更新もされます。最新のドキュメントを確認してから構成を決めてください。BINDのように、ALIASという種類そのものを持たないソフトウェアもあります。
セカンダリDNSを足すときの注意
ALIASはDNSサービス独自の種類なので、ゾーン転送（AXFR）で別のDNSに渡すと、受け取った側が理解できないことがあります。よくある失敗は次の2つです。
- セカンダリが頂点のAを返さない: ALIASを理解できず、頂点にA・AAAAが無い状態になる
- セカンダリが古いIPを返し続ける: 転送の時点でALIASを固定のAレコードに展開して渡したが、その後の向け先の変化に追いつかない
DNSSECを使う場合はさらに、セカンダリ側の答えにも有効な署名が必要です。事前署名したゾーンを転送する構成では、展開したAレコードの署名が、向け先のIPが変わった時点で食い違います。PowerDNSには、ゾーン転送時にALIASを展開する設定があるなど、対応の仕方はソフトウェアによって異なります。設定名や既定値はバージョンで変わるため、使っているバージョンのドキュメントで確認してください。
確認には、すべての権威DNSに同じ問い合わせをして結果を比べます。
for ns in ns1.example-dns.net ns2.example-dns.net ns1.secondary.example; do
echo "== $ns"
dig @"$ns" example.com A +dnssec +noall +answer
doneどのサーバーも同じIPと、期限内のRRSIGを返していれば揃っています。1台だけ違う場合は、そのサーバーがALIASを扱えていないか、署名の更新が止まっています。
複数のDNSサービスで署名する場合
2つのDNSサービスにそれぞれ頂点のALIASを置き、両方でオンライン署名する構成は、複数署名者（マルチサイナー）モデルと呼ばれ、RFC 8901で整理されています。この構成では、両方のサービスの鍵をお互いのDNSKEYに含め、親ゾーンのDSにも両方の鍵を登録する必要があります。どちらのサービスに問い合わせても、相手の署名を検証できる状態にするためです。
対応しているDNSサービスは限られ、手作業での鍵の交換が必要なことも多いため、冗長化だけが目的なら、1つのサービスの中の複数拠点で十分かを先に検討するのが現実的です。
鍵を更新するときに確かめること
DNSサービスが鍵を自動で更新する場合でも、親ゾーンのDSを手で登録している構成では、鍵署名鍵（KSK）の更新時にDSの差し替えが必要になることがあります。更新の前後で、次を確かめます。
dig example.com DNSKEY +multi # 現在の鍵と鍵タグ
dig example.com DS +short # 親に登録したDSの鍵タグ
dig @1.1.1.1 example.com A +dnssec # ad フラグが付くか
dig @8.8.8.8 example.com A +cd # 検証を外した結果と比べるDSの鍵タグが現在のDNSKEYのどれとも合わない状態になると、検証するキャッシュDNSではSERVFAILになります。+cd を付けたときだけ引ける場合は、この食い違いを疑います。ALIASの頂点は、サイトとメールの両方に関わる名前なので、作業前にゾーンのバックアップを取り、検証ツール（DNSVizなど）でも鎖のつながりを確かめます。
WordPressサイトでの注意
頂点をALIASでCDNやホスティングに向けている場合、WordPressのサイトアドレスは頂点のドメインになっていることが多く、DNSSECの不具合はそのままサイト全体の停止につながります。DNSサービスを替える、署名方式を変える、といった作業は、アクセスの少ない時間帯に行い、旧構成に戻す手順を事前に書き出しておきます。
まとめ
- ALIASは応答の時点でA・AAAAになるため、頂点のDNSKEYと同居できる
- ALIASとDNSSECを両立させるには、オンライン署名に対応したDNSサービスかソフトウェアが必要
- セカンダリDNSや複数のDNSサービスを足すと、ALIASの展開と署名がずれやすい。全台に同じ問い合わせをして比べる
- 鍵の更新では、DNSKEYと親のDSの鍵タグが合っているかを
digと検証ツールで確かめる