DNSの設定をしていて、ALIASレコードやCNAME Flatting、ANAMEレコードというものを見かけたことはありませんか？
本記事では、ALIASレコード、CNAME Flattening(CNAMEフラッテニング)、ANAMEレコード についてできるだけわかりやすく解説します。それぞれの意味や目的、従来のDNSレコードではなぜ不十分だったのか、そして各DNSプロバイダーでの対応状況について見ていきます。
ALIASレコードとは？
ALIASレコードとは、一言でいうと「ルートドメインでCNAMEのような動作を実現するための仮想的なDNSレコード」です。DNSの標準レコードではなく、特定のDNSホスティング事業者が独自に実装して提供している便利な機能です。
通常、ルートドメインを別のホスト名に向けたい場合、直接CNAMEレコードを使うことはできません。
example.com --❌CNAME--> myapp.hosting-service.test
しかしALIASレコードを使えばそれが可能になります。ALIASレコードは名前解決の際に、その参照先ホスト名を自動で解決し、対応するAレコード(IPv4アドレス)やAAAAレコード(IPv6アドレス)として振る舞います。つまり、見かけ上はCNAMEのように別のドメイン名を指定しておき、DNSサーバー側でそのドメイン名のIPアドレスを引いて返してくれるのです。
例えば、example.com のALIASレコードを myapp.hosting-service.test に設定すると、DNSクエリが来たときにDNS提供者側が myapp.hosting-service.test を解決して得たIPアドレス群を返します。ブラウザなどのクライアントから見ると、あたかも example.com に最初からAレコードが設定されていたかのように見えるわけですね。(実際には、キャッシュやローカルリゾルバーなどがあったりと細かい複雑な振る舞いがあったりもします)
DNSimple社が2012年頃にこのALIASレコードを提案・実装したことで広まりました。現在ではDNSimple以外にも複数のDNSプロバイダーが独自のALIASレコード機能を提供しています。
CNAME Flatteningとは？
CNAME Flattening(CNAMEフラッテニング)とは、主にCloudflare社が提供している仕組みで、ルートドメインにおけるCNAMEレコードの制約を回避する方法です。Flatteningは「平坦化」という意味で、その名の通りCNAMEの参照先をフラットにしてしまいます。
具体的には、ルートドメインに対して見た目上はCNAMEレコードを設定できるようにしつつ、実際の応答ではDNSサーバーがそのCNAME先のIPアドレスを直接返すように動作します。CloudflareではユーザーがルートドメインにCNAMEを設定すると、CloudflareのDNSが問い合わせに応じてその別名先を再帰的に解決し、得られたIPアドレスをAレコードとしてクライアントに返すのです。さらにCloudflare側でその結果をキャッシュすることで、高速化も図っています。
つまり、CloudflareのCNAME FlatteningはALIASレコードと同じ効果を実現する機能と言えます。ユーザーから見ると単にCNAMEを書いているだけですが、裏側でプロバイダー(Cloudflare)が「いい感じに」処理をしてくれているイメージですね。
ANAMEレコードとは？
ANAMEレコードもALIASレコードとほぼ同義の概念です。呼び方が異なるだけで、ルートドメインでCNAMEのように使えるエイリアスレコードと考えてください。こちらもDNSの標準規格に存在しないカスタムレコードですが、特定のDNSプロバイダーによって提供されています。
例えば、DNSサービスのDNS Made Easyやその関連サービスConstellixではANAMEレコードという名前で提供されています。ANAMEレコードは「まるでAレコードがCNAMEに変身したようなもの」だと説明されています。要するに、ALIASと同様に指定したホスト名をDNSサーバー側で解決し、そのIPを返す仕組みです。
ANAMEという名称はDNS Made Easy社が自社の機能に付けた名前ですが、本質的には前述のALIASレコードと同じ課題を解決するためのものです。実際、他社のサービスではALIASやANAMEといった名前でほぼ同等の機能が実装されています。
まとめると、ALIASレコードもANAMEレコードも、呼び名と実装がサービスによって違うだけで、「ルートドメインを別のホスト名に委譲するエイリアス」を実現する仕組みです。CloudflareのCNAME Flatteningも含め、目指すところは同じと言えるでしょう。
では、これらのレコード(機能)は何のために生まれ、どんな課題を解決するのでしょうか？次のセクションで見てみましょう。
これらのレコードの目的と解決する課題
そもそもALIASやANAME、CNAMEフラッテニングといった仕組みが登場した背景には、DNSの従来の仕様上の制約を克服して利便性を向上させたいという目的がありました。
具体的に解決したい課題は次のようなものです。
-
ルートドメインを他のホスト名に向けたい
たとえばウェブサイトをHerokuやNetlify、GitHub Pages、各種CDNサービスなどで運用するとき、サービス提供側から「このCNAME先を設定してください」とホスト名が指定されることがあります。しかし多くの場合、そのサービスは固定IPアドレスをユーザーに提供しません。IPは変動する可能性があるか、複数地域で異なるためです。
サブドメインならCNAMEで対応できますが、ネイキッドドメイン(APEXドメイン)にはCNAMEが使えないため、そのままでは
example.comを直接そのサービスに向けられない問題が発生します。 -
手動でのIPアドレス管理を避けたい
ルートドメインを外部サービスに向けるために無理やり対応する方法として、ルートにAレコードを設定しCDNがIPを提供してくれるIPアドレスを書いてしまうといった手段もあります。しかし、サービス側のIPアドレスが変更されるたびにDNSのAレコードを手動更新するのは現実的ではありません。また複数地域のCDNエッジのような複数のIPアドレスを使った冗長構成にも対応しづらいです。
-
DNSのパフォーマンスと可用性の問題
上記のような手動対応ではなく、常に最新のIPアドレスに追従するには動的DNSのような仕組みが欲しいところですが、一般的なクラウドサービス提供者は利用者にそこまで細かい情報(IPの都度通知など)をしてくれません。ALIAS/ANAMEの仕組みなら、DNSプロバイダー側が自動で該当ホスト名を解決し続けてくれるため、利用者は気にせずルートドメインを運用できます。これにより常に正しいIPが返答され、ダウンタイムや古いキャッシュによる不達を防ぎます。
また、名前解決のチェイン(CNAMEがさらにCNAMEを指す...と辿る処理)をフラット化することで、クライアントから見たDNS応答の応答時間も短縮される効果もあります。
要するに、「ルートドメインでも別名(CNAME)のように柔軟に他のサービスに向けたい」というニーズに応えるのがALIASレコードやANAMEレコード、そしてCNAMEフラッテニングの目的です。これらはルートドメインと外部サービスの橋渡しをスムーズにし、DNS管理の手間や制約を取り除くために考案されたものなのです。
CNAMEが使えない理由・既存のレコードではなぜ不十分なのか？
では、なぜそもそもルートドメイン(APEX)にCNAMEが使えないのでしょうか？既存のAレコードやCNAMEレコードでは何が問題だったのか、技術的な理由を掘り下げてみましょう。
CNAMEレコードがルートドメインに使えない理由
結論から言えば、DNSの仕様(RFC規約)上、ある名前にCNAMEレコードを設定すると他の種類のレコードを同居させることが禁じられているためです。ルートドメイン(APEXドメイン)はゾーンの頂点であり、そこには必ず権威DNSサーバーの情報であるNSレコードやゾーンの管理情報を扱うSOAレコード、場合によってはメールのMXレコードや各種検証に用いることがあるTXTレコードなどが存在します。もしルートにCNAMEを置いてしまうと、それら必要なレコードと共存できず、DNSの整合性が崩れてしまうのです。
実際、RFC規約には以下のように明記されています:
If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different. This rule also insures that a cached CNAME can be used without checking with an authoritative server for other RR types.
CNAMEリソースレコードがノードに存在する場合、他のデータは共存できません。これは正規名（正式名）とそのエイリアス（別名）のデータに矛盾が生じないようにするための仕組みです。また、このルールによって、キャッシュされたCNAMEレコードを使用する際に、他のタイプのリソースレコードについて権威サーバーへの確認が不要となり、効率的な運用が可能になります。
https://www.rfc-editor.org/rfc/rfc1034
Don't use CNAMEs in combination with RRs which point to other names like MX, CNAME, PTR and NS.
CNAMEを、MX、CNAME、PTR、NSなど他の名前を指すRRと組み合わせて使用しないでください。
https://datatracker.ietf.org/doc/html/rfc1912
ルートドメイン example.com をCNAMEにすると、同じexample.comに本来必要なNSやSOA、MX等が設定できなくなるためゾーン運用上致命的なのです。そのため多くの権威DNSサーバーソフトやDNSサービスは、ルートにCNAMEを設定しようとするとエラーを出して受け付けません。
Aレコード・AAAAレコードだけでは不十分な理由
「ルートにCNAMEが無理なら、最初からAレコード(IPアドレス)を直接書いておけばいいのでは？」と思われるかもしれません。確かに、もし向け先のサービスが単一もしくは固定のIPアドレスを教えてくれるなら、example.com にそのIPでAレコードを設定するだけで済みます。しかし現代の多くのクラウドサービスやCDNは内部でIPアドレスが変動したり、複数のIPや地域分散を行っています。
例えば、あるCDNサービスでは世界中にエッジサーバーを持っており、利用者には単一のホスト名だけが提供され、そのDNSを引くと地域に応じた複数のIPアドレスが返ってくる、といった構成が一般的です。この場合、利用者が自分のDNSにAレコードとしてIPを設定してしまうと、CDN側でIPを増減・変更したときに対応できません。最悪、古いIPを引き続き指してしまいサービスに繋がらなくなる恐れもあります。
要するに、Aレコードに固定のIPを書く方法は変化に弱く、手動対応が必要なので現実的ではありません。もちろん、サービス側が「このIPを使ってください」と公式に固定IPを提示している場合はAレコードで問題ありません。しかし昨今のクラウド環境ではそのようなケースは少なく、ホスト名ベースでの委譲 (CNAME的な方法) が推奨されることが多いのです。
以上のように、従来のDNSレコードだけでは対応できない場面が増えたため、ALIASレコードやANAMEレコードといった新しい仕組みが各社で考案・導入されるに至ったわけです。
DNSプロバイダーごとに共通する点・異なる点
さて、ALIASレコードやANAMEレコード、CNAMEフラッテニングの概念を一通り見たので、利用できるかどうかはDNS提供会社次第という点にも触れておきましょう。残念ながらこれらはDNSの公式標準ではなく各社独自の拡張機能なので、サービスによってサポート状況が異なります。
共通するポイントとしては、
-
最終的な効果は同じ
どの呼び名であっても「ルートドメインで他のホスト名へのエイリアスを実現する」点は共通です。技術的には各DNSサービスの権威DNSサーバーがその処理(他のホスト名の名前解決→IP応答)を肩代わりしてくれているだけで、クライアントから見れば普通にAレコードが返ってくるだけです。 -
非標準ゆえの非互換性
RFC標準のレコードタイプではないため、ゾーンファイルのエクスポート/インポートや他社乗り換え時には注意が必要です。他社では通用しないので、ALIAS/ANAMEを使っていた場合は移行先で手動設定し直す必要があります。 -
設定方法
プロバイダーによって、設定画面上で「ALIAS」や「ANAME」といったレコード種別を選べる場合と、特別な書き方不要で通常のCNAME設定時に自動的にFlatteningされる場合があります。例えばCloudflareは後者で、ユーザーは特に意識せずルートにCNAMEを書くとFlattening動作しますが、DNSimpleやDNS Made Easyでは前者で、明示的にALIASやANAMEレコードとして追加します。
では、主要なDNSプロバイダーでの対応状況を見てみましょう。できるだけ多くの例を挙げて比較します。
| DNSプロバイダー | ルートドメインのエイリアス対応状況 | 備考(呼称や制限など) |
|---|---|---|
| Cloudflare | 対応あり (自動CNAME Flattening) | ルートにCNAME設定するとFlattening適用。全プラン対応(無料はルートのみ) |
| AWS Route 53 | 対応あり (Aliasレコード) | ホストゾーン内の特定リソースにエイリアス可能(CloudFrontやELB等AWSサービス向けが主。任意の外部ドメインは不可) |
| Google Cloud DNS | 対応あり (ALIASレコード) | 2023年にALIAS相当機能を追加。※BIND形式エクスポート非対応 |
| Microsoft Azure DNS | 対応あり (Aliasレコード) | Azureリソースに対してエイリアス可(例: Azure CDN) |
| DNSimple | 対応あり (ALIASレコード) | ALIASレコードを独自実装。任意のホスト名を指定可能 |
| Namecheap (BasicDNS等) | 対応あり (ALIASレコード) | 2019年頃より提供開始。管理画面でALIAS(ANAME)選択 |
| GoDaddy | 未対応 | (対応なし。代替策: サブドメイン運用や別DNSサービス利用) |
| ムームードメイン | 対応あり (ALIASレコード) | 2018年から提供。国内サービスとしては珍しい |
| お名前.com | 未対応 | (対応なし。ALIAS機能なし) |
ご覧のように、かなり多くのDNSプロバイダーがALIAS/ANAME/CNAME flattening相当の機能を提供しています。一方で、未対応のサービスも依然存在します。特に従来型のドメイン登録業者付属のDNS(GoDaddyやお名前.comなど)では未対応としている傾向が見られます。
各社で呼び名が違うため混乱しがちですが、本質的な機能は同じと考えて良いです。自分の使っているDNSサービスがどの名称でこの機能を提供しているか、事前にドキュメントを確認すると良いでしょう。また、設定手順や細かな制約(例えばAWS Route 53のAliasはAWS内リソースに限定、といったルール)にも違いがあるため、公式のサポート資料を読むことをおすすめします。
まとめ
今回はALIASレコード、CNAMEフラッテニング、ANAMEレコードという3種類の名前が登場しましたが、ポイントはどれも「ルートドメインを他のホスト名に柔軟にポイントする」ための仕組みだということです。
従来のDNSではルートにCNAMEを置けない制約がありました。しかしウェブやクラウドの発展に伴い、その制約はユーザーに不便を強いるものとなってしまいました。そこで各DNSプロバイダーが工夫を凝らし、独自拡張のレコードや機能(ALIAS/ANAMEやFlattening)を作り出してこの問題を解決したわけです。
技術的には細かな実装の違いはあれど、「DNSサーバー側が代理で名前解決する」という原理は共通しています。これにより私たち利用者はルートドメインでもサブドメイン同様に気軽に他サービスへ向けることが可能になりました。例えば、NetlifyやHerokuでホスティングしているサイトを www なしの独自ドメインでも運用したい、といったケースでも、対応するDNSサービスを使えばスムーズに実現できます。
DNS周りは少しとっつきにくい話題ですが、本記事が「なぜルートドメインにCNAMEが使えないの？」「ALIASやANAMEって何をしてくれるの？」という疑問の解消に役立てば幸いです。それでは、最後までお読みいただきありがとうございました！