SOAレコードとALIASレコードは、ゾーンの頂点（example.com）に並べて設定できます。頂点にはSOAとNSが必須で、CNAMEはそれらと共存できませんが、ALIASはDNSサービスが向け先を解決してA・AAAAレコードとして返すため、SOAと矛盾しません。ただし、SOAの値はALIASの挙動にも影響します。この記事では、併用できる理由、SOAのネガティブキャッシュやゾーン転送がALIASにどう関わるか、設定と確認の手順を説明します。
頂点にCNAMEを置けない理由とALIASの位置づけ
DNSの決まりでは、CNAMEを置いた名前には他のレコードを置けません（RFC 1034、RFC 2181）。一方、ゾーンの頂点には、そのゾーンの管理情報であるSOAと、ネームサーバーを示すNSが置かれている必要があります。このため、頂点にCNAMEを置くことは規格上できません。
ALIASは、この制約を避けるためにDNSサービスが用意している機能です。サービスが向け先のホスト名を解決し、得たIPアドレスを頂点のA・AAAAレコードとして応答します。問い合わせた側から見えるのはふつうのAレコードなので、同じ名前にSOA、NS、MX、TXTが並んでいても問題になりません。
ALIASは標準のレコード型ではなく、同じ考え方の機能がサービスによってANAME、CNAMEフラット化、エイリアスレコード（Amazon Route 53）などの名前で提供されています。動きの細部はサービスごとに異なり、変わることもあります（2026年10月現在）。
併用したゾーンの例
管理画面上では、頂点に次のようなレコードが並ぶ形になります。ALIASの行は説明用の書き方で、BINDなどの標準のゾーンファイルにはこの書式はありません。
example.com. 3600 IN SOA ns1.dns-provider.example. hostmaster.example.com. 2026101801 7200 3600 1209600 3600
example.com. 3600 IN NS ns1.dns-provider.example.
example.com. 3600 IN NS ns2.dns-provider.example.
example.com. 300 ALIAS site.hosting.example. ; サービス独自の機能（標準の書式ではない）
example.com. 3600 IN MX 10 mail.example.com.
example.com. 3600 IN TXT "v=spf1 include:_spf.mail-provider.example ~all"SOAの値は左から、プライマリのネームサーバー（MNAME）、管理者のアドレス（RNAME、@ を . に置き換えた形）、シリアル番号、REFRESH、RETRY、EXPIRE、MINIMUMです。マネージドDNSではSOAを自動で管理していることが多く、どの値を編集できるかはサービスによって異なります。
SOAの値がALIASの挙動に関わる場面
ネガティブキャッシュとAAAA
ALIASの向け先にAAAAレコードが無い場合、頂点へのAAAAの問い合わせには「その名前はあるが、AAAAは無い」という答え（NODATA）が返ります。この答えにはSOAが添えられ、キャッシュDNSは、SOAレコード自体のTTLとSOAのMINIMUMのうち短いほうの時間だけ、「AAAAは無い」という結果を覚えます（RFC 2308）。
困るのは、ホスティングやCDNがあとからIPv6に対応し、向け先にAAAAが増えたときです。ALIASは新しいAAAAを返し始めますが、すでに「無い」と覚えたキャッシュDNSは、ネガティブキャッシュの時間が切れるまでIPv6のアドレスを使いません。MINIMUMが1日などの長い値だと、反映に1日かかります。
ALIASを使う頂点では、MINIMUMを長くしすぎないほうが変化に追従しやすくなります。一般的には数分から1時間程度に収めることが多く、編集できないサービスではその値を前提に作業の予定を立てます。現在の値は次のように確かめます。
# AAAAが無い場合、AUTHORITY セクションに SOA が返り、その TTL がネガティブキャッシュの時間
dig example.com AAAA +noall +authorityシリアル番号とゾーン転送
SOAのシリアル番号は、ゾーンの内容を変えたときに上げる番号で、セカンダリのネームサーバーはこれを見てゾーン転送（AXFR・IXFR）を行います。ALIASを使う場合、ここに2つの落とし穴があります。
- 向け先のIPアドレスが変わっても、ゾーン自体は変わらないので、シリアル番号は上がらないのが一般的です。ALIASが返すIPは応答のたびに（またはサービスの内部で定期的に）計算されるもので、ゾーンに書かれているわけではありません
- ALIASは標準のレコード型ではないため、他社のDNSをセカンダリにしてゾーン転送しても、セカンダリ側は頂点のA・AAAAを返せないことがあります。サービスによっては、転送時に解決済みのAレコードへ置き換えるなどの扱いをしますが、その場合も向け先の変化には追従しにくくなります
他社のセカンダリDNSと組み合わせている場合、ALIASを頂点に置くと、セカンダリに当たった問い合わせだけ頂点が解決できない、という不定期な障害になります。この構成では、頂点にはAレコードを置くか、セカンダリも同じサービスの機能でまかなうか、www を正規のURLにして頂点はリダイレクトだけにするといった選択肢を検討します。
SOAのMNAMEとRNAME
ALIASとは直接関係しませんが、頂点のレコードを触る機会に、SOAのMNAMEが実際のプライマリを指しているか、RNAMEが届くアドレスになっているかもあわせて確認しておくと、のちの切り分けが楽になります。
Route 53 のエイリアスを使う場合
Amazon Route 53 のエイリアスレコードは、ALIASと似た役割を持ちますが、向け先が CloudFront、ロードバランサー、S3のWebサイトエンドポイントなどのAWSリソースや、同じホストゾーン内のレコードに限られます。外部のホスティングのホスト名には向けられません。また、エイリアスレコードには自分でTTLを指定できず、向け先側のTTLが使われる仕組みです。ホストゾーンのSOAは、Route 53 の管理画面から値を編集できます。編集する場合は、変更前の値を控えてから行います。
設定と確認の手順
- 管理画面のエクスポートなどで、現在のゾーンの内容を保存する
dig example.com SOA +shortでSOAの値を確かめ、MINIMUMが長すぎないかを見る- 頂点にCNAMEや古いA・AAAAが残っていれば整理し、ALIASを追加する
- すべての権威サーバーに直接問い合わせ、頂点のA・AAAAが向け先と一致しているかを確かめる
- セカンダリDNSを使っているなら、セカンダリ側の応答も同じように確かめる
# NS ごとに頂点の A と AAAA を比べる
for ns in $(dig +short NS example.com); do
echo "== $ns"
dig @"$ns" +norecurse +short example.com A
dig @"$ns" +norecurse +short example.com AAAA
done
# 向け先が実際に持つアドレス
dig +short site.hosting.example A
dig +short site.hosting.example AAAANSのうち1つでも空の応答があれば、そのサーバーはALIASを解決できていません。5のセカンダリの問題を疑います。
WordPressサイトでの注意
頂点をALIASで新しいホスティングに向けたら、WordPressの「サイトアドレス（URL）」が頂点と www 付きのどちらかを確かめ、もう一方からリダイレクトされるようにします。IPv6の対応状況が変わったときに、一部の利用者だけ接続できないという報告があれば、先に説明したネガティブキャッシュの時間を確認します。
まとめ
- 頂点にはSOAとNSが必須で、CNAMEは共存できない。ALIASはA・AAAAとして応答するので共存できる
- 向け先にAAAAが無いと、SOAのTTLとMINIMUMの短いほうだけ「無い」とキャッシュされる。MINIMUMは長くしすぎない
- ALIASの応答はゾーンに書かれていないので、シリアル番号は上がらず、他社のセカンダリには正しく転送されないことがある
- Route 53 のエイリアスは向け先がAWSリソースなどに限られ、TTLは向け先側のものが使われる
- 作業後はすべての権威サーバーで頂点のA・AAAAを比べる