DSレコードとALIASレコードは、置かれる場所も役割も違うため、仕組みの上では併用できます。ただし条件が1つあり、ALIASが返すA/AAAAレコードにも、DNSサービスがその場で署名を付けられる（オンライン署名に対応している）必要があります。この記事では、両者の関係、併用できるかの判断方法、設定の順番、署名が正しく付いているかの確認方法を説明します。すでにDSの誤りで名前解決が失敗している場合の直し方は、DSレコードの誤設定の修正手順として別に扱っているため、ここでは「これから両立させる」設計と確認に絞ります。
DSとALIASはどこに置かれ、何をしているか
DSレコードは、自分のゾーンではなく親ゾーン（.com や .jp など）に、レジストラを通じて登録します。中身は「このゾーンはこの鍵で署名されている」という鍵の指紋で、検証するリゾルバはこれを手がかりに、自分のゾーンの応答が改ざんされていないかを確かめます。
ALIASレコードは、自分のゾーンに置く、DNSサービス独自の仕組みです。example.com のようなルートドメイン（ゾーンの頂点）には、SOAやNSと共存できないためCNAMEを置けません。そこでDNSサービスが、問い合わせを受けた時点で別名の先（CDNやロードバランサーのホスト名など）を自分で名前解決し、その結果をA/AAAAレコードとして返します。サービスによって呼び方が異なり、Amazon Route 53 の「エイリアスレコード」、Cloudflare の「CNAMEフラット化」、ほかに ALIAS・ANAME と呼ぶサービスがあります。標準化されたレコード型ではないので、書き方も細かな挙動もサービスごとに違います。
つまり、DSは「親から子への信頼のつなぎ目」、ALIASは「子ゾーンの中での応答の作り方」で、層が異なります。両者が直接ぶつかることはありません。
併用できるかを決める条件：オンライン署名
DNSSECを有効にしたゾーンでは、ALIASが合成したA/AAAAレコードにも署名（RRSIG）が付いていなければなりません。署名が無い、または合わない応答は、DSがある以上「改ざんの疑いあり」と判断され、検証するリゾルバからは SERVFAIL になります。
ALIASの答えは別名の先の状況によって変わるため、あらかじめ署名しておくことができません。応答を作るたびに署名する「オンライン署名」に対応したDNSサービスでなければ、両立はできないということです。判断の目安は次のとおりです。
- DNSサービス自身がDNSSECの署名を行い、そのサービスのALIAS相当の機能と同時に使えるとドキュメントに明記されている: 併用できます。Route 53 や Cloudflare は、それぞれのDNSSEC署名機能とエイリアスレコード／CNAMEフラット化を組み合わせて使えるとされています（2026年10月現在）。対応範囲や条件は変わることがあるので、各サービスの最新ドキュメントで確認してください。
- 自分でゾーンに署名してからDNSサービスへ渡す方式（事前署名）: ALIASは使えないと考えます。
- 複数のDNSサービスを同時に権威サーバーとして使う構成: ALIASの書き方がサービス間で共通ではなく、DNSSECの鍵の管理も複雑になります。この組み合わせは難易度が高いため、まず単一のサービスで運用できないかを検討します。
DNSSECを有効にするとALIASに制限がかかるサービスもあるため、「DNSSEC」と「ALIAS（またはフラット化）」の両方の項目をドキュメントで確認してから進めてください。
設定の順番
作業前に、現在のDNSレコードをエクスポートして控えておきます。DSの登録は親ゾーンへの変更で、誤ると名前解決全体に影響するため、順番を守ることが大切です。
- ALIASを設定して、署名なしの状態で動作を確認する。 まずDNSSECを有効にする前に、ALIASが期待どおりのA/AAAAを返すことを確認します。
- DNSサービスでDNSSECの署名を有効にする。 この時点ではまだ親にDSが無いので、検証するリゾルバも署名を検証せず、利用者への影響は出ません。
- 署名が付いているかを確認する。 次の章のコマンドで、ALIASの応答にRRSIGが付いていることを確認します。
- DNSサービスが表示するDS情報を、レジストラで登録する。 キータグ・アルゴリズム・ダイジェスト種別・ダイジェストを正確に入力します。
- 親ゾーンへの反映後、検証が成功するかを確認する。
すでにDNSSECを有効にしているゾーンにALIASを追加する場合は、手順1と3だけで済みます。追加したら、すぐに署名が付いているかを確認してください。
署名が付いているかを確認する
# ALIAS が返す A レコードに RRSIG が付いているか（権威サーバーに直接聞く）
dig @ns1.your-dns-provider.example example.com A +dnssec
# AAAA も確認（別名の先に IPv6 が無い場合も、署名付きの「無し」応答が返る必要がある）
dig @ns1.your-dns-provider.example example.com AAAA +dnssec
# DS 登録後：検証するリゾルバで ad フラグが付くか
dig @1.1.1.1 example.com A +dnssec権威サーバーへの問い合わせでは、ANSWERセクションにA（またはAAAA）とそのRRSIGが並んでいれば署名されています。見落としやすいのがAAAAです。別名の先にIPv6アドレスが無いと「該当なし（NODATA）」の応答になりますが、DNSSECではこの「無い」ことも、NSECまたはNSEC3レコードと署名で証明する必要があります。ここが正しくないと、IPv6を優先する環境でだけ失敗する、という分かりにくい障害になります。
DS登録後は、検証するリゾルバの応答の flags: に ad が付けば成功です。delv example.com A を使うと、検証の過程も表示されます。DNSViz のような可視化ツールで、親のDSから子のDNSKEY、ALIASの応答の署名までの連鎖を確認しておくと安心です。
運用上の注意点
- 別名の先のDNSSECは別問題です。 CDNやロードバランサー側のゾーンが署名されていなくても、ALIASの応答に署名するのは自分のDNSサービスなので、自分のゾーンの検証には影響しません。ただし、サービスが別名の先をどう名前解決しているか（検証しているかどうか）は、利用者からは見えません。
- TTLはサービスの仕様に従います。 ALIASの応答のTTLは、サービスが決める場合と、別名の先のTTLを引き継ぐ場合があります。CDNの切り替えを予定しているなら、事前にTTLの扱いを確認しておきます。
- サブドメインには普通のCNAMEを使います。
www.example.comのようにゾーンの頂点でない名前は、CNAMEで問題ありません。ALIASが必要なのはルートドメインだけです。 - DNSサービスを移行するときは、ALIASとDSの両方を作り直します。 ALIASは移行先の書き方に置き換える必要があり、DSは移行先の鍵のものに差し替えます。古いDSを残したまま移行すると、ゾーン全体の検証に失敗するので、先にDSを外す、またはDSの差し替え手順を決めてから移行します。
まとめ
- DSは親ゾーンで信頼をつなぐ役割、ALIASは子ゾーンでA/AAAAを合成する仕組みで、層が違うため併用は可能
- 条件は、DNSサービスがALIASの応答にその場で署名できる（オンライン署名）こと。事前署名の構成では使えない
- 設定は「ALIASの動作確認 → 署名を有効化 → RRSIGの確認 → DS登録 → 検証の確認」の順に進める
- AとAAAAの両方で署名を確認する。IPv6が無い場合の「無し」応答の証明も見落とさない
- DNSサービスの移行時は、ALIASの書き換えとDSの差し替えをセットで計画する