メインコンテンツへスキップ
CNAMEレコードとは何ですか?

CNAMEレコードとは何ですか?

電子メール技術セキュリティに関する知見技術ガイダンス

CNAME(Canonical Name)レコードとは、あるDNS名を別のDNS名のエイリアスとするドメインネームシステム(DNS)レコードのことです。 

alias.example.comtarget.example.net へ指す CNAME レコードを登録すると、DNS に対して「alias.example.com を検索した際は、代わりに target.example.net を使用するように」と指示することになります。その後、リゾルバーはtarget.example.netを検索し、実際に必要なレコードを取得します。 

CNAMEはどのように使用されますか? 

CNAMEは、主に委任と変更管理に関するものです。 

(変更される可能性のある)データそのものを直接公開するのではなく、第三者が管理する名前へのエイリアスを公開します。その「第三者」とは、SaaSプロバイダー、メールサービスプロバイダー、認証プラットフォーム、あるいはその他の組織や個人を指します。 後でインフラストラクチャ、TXTレコードの内容、またはWebサイトの指向先などを変更する必要が生じた場合、相手側がCNAMEのターゲット側を更新すればよく、ドメインのDNSにあるDNSレコードはそのままにしておくことができます。 

そのため、サービスプロバイダーが、DNSに依存する設定を管理する際、利用者に頻繁にDNSの設定を変更してもらうことなく済むよう、ドメインにCNAMEレコードを追加するよう依頼することはよくあります。 

CNAMEレコードの例

次のような典型的な状況を考えてみましょう:

example.comというドメインを所有していると仮定しましょう。ウェブサイトの内容をホストしてくれるプロバイダーとして、service.example.netがありますそのプロバイダーから www.example.comに対して、値がservice.example.net となるCNAMEレコードを作成するよう依頼されました。 

これにより、ドメイン名をサイトのブランドとして維持しつつ、サイトを支える技術的な管理を、サービスプロバイダーが管理する「service.example.net」に委任することができます。これにより、サービスプロバイダーは、ユーザーが何らかの操作を行う必要なく、サイトの動作に必要なDNS関連の設定変更を行うことが可能になります。この形式のリダイレクトは、しばしば「CNAMEベースの委任」と呼ばれます。 

DMARCとCNAMEレコードの連携方法 

メール認証では、SPF、DKIM、およびDMARCが機能するために、DNSのホストレコードが使用されます。これらのレコードは、送信者が名乗っている人物であるかどうかを確認するために、メール受信側のシステムによって照会されます。特にDMARCでは、検証を通過するために「アラインメント」が必須となります。アラインメントとは、メールの表示される「From:」ヘッダーに記載された ドメインが、SPFまたはDKIM認証によって検証されたドメインと一致していることを 指します。SPFおよびDKIMのレコード値は、TXT DNSリソースレコードタイプを使用して公開する必要があります。 

CNAMEレコードは、そのレコードがホストされている別のドメインを指すためにも使用できます。これは、自社のDNSでそれらのレコードを管理しつつ、DMARCのアラインメント要件に対応したいと考えるサードパーティのサービスプロバイダーによって、よく利用されています。 

Microsoft 365のようなビジネス向けメールプロバイダーから、MailChimpのようなサードパーティのマーケティングサービスプロバイダーに至るまで、多くの組織がメールサービスを提供しています。こうしたサービスでは、変更を直接行えるようにするため、メール認証用のDNSレコードにCNAMEベースの委任を採用するのが一般的です。

DKIMの委任

DKIM(DomainKeys Identified Mail)は、多くの場合、メール送信を担当するサービスプロバイダーに委任されます。DKIMレコードの公開を求められた場合、その内容は次のようなものになります: 

selector._domainkey.example.com

多くのプロバイダでは、上記のような形式のCNAMEレコードを作成し、次のようなプロバイダが管理するドメイン名を指定するよう求めています: 

selector._domainkey.service.example.net 

その後、サービスプロバイダーは実際のDKIM公開鍵レコードを自社のドメインに公開します。これにより、ユーザーが何らかの操作を行う必要なくプロバイダーが鍵を更新できるため、鍵のローテーションが容易になります。 

CNAMEに関するルール

CNAMEレコードは、そのDNS名に対して唯一のレコードでなければなりません

x.example.comに CNAME レコードが存在する場合、DNS 標準(RFC 1034)に従い、x.example.com には他のデータレコードが存在してはなりません。もし存在する場合、この DNS 名を照会するシステムはそれらを無視し、CNAME レコードのみを処理して、その指し示す先を追跡します。 

通常、ルートドメイン(example.com)ではCNAMEは使用できません。 

ドメインのルートには、NSレコードやSOAレコードなどが必要です。CNAMEレコードは他のレコードタイプと共存できないため、通常のDNSホスティングでは、ルートドメインに標準的なCNAMEレコードを設定することはできません。一部のDNSプロバイダでは「アペックスでのエイリアス」(ANAMEと呼ばれることが多い)という機能を提供していますが、これらは別のソリューションであり、標準的なCNAMEレコードではありません。 

CNAMEはIPアドレスを指すことはできません

CNAMEレコードの値は、常にドメイン名でなければなりません。IPアドレスを直接指定する必要がある場合は、A(IPv4)またはAAAA(IPv6)リソースレコードタイプを使用する必要があります。 

CNAMEの連鎖やループは、ルックアップを失敗させる可能性があります

CNAMEは別のCNAMEを指すことができ、エイリアスの連鎖を形成します。連鎖が長すぎたり、ループ(例:2つのCNAMEが互いを指し合っている状態)などの設定ミスが発生したりすると、解決に失敗したり、検証結果が不明確になったり、不安定になったりすることがあります。 

CNAMEに関するよくある問題

CNAMEが誤ったDNS名で公開されています

プロバイダーによって、顧客にドメインへのCNAMEの追加を求める際の対応は異なります。以下に、各プロバイダーが求める可能性のある内容の例を示します:

CNAMEレコードとは - 例 - dmarcian

CNAMEレコードとは - 例 - dmarcian

DNSプロバイダーのコンソールも、その設計は様々です。 DNS名フィールドに完全修飾ドメイン名(つまり、ドメイン名とselector1._domainkey.example.comのようなすべてのサブドメイン名)の入力を求めるものもあります。一方、GoDaddyのようなプロバイダーでは、ルートドメイン名の直前にある部分のみを入力すればよい場合もあります。上記の例で言えば、example.comのレコードを追加する場合、コンソールではDNS名フィールドにselector1._domainkeyのみを入力するよう求められることになります。 

例えば: 

  • お客様のドメインはexample.com です。
  • プロバイダーから、selector1._domainkey.example.com という CNAME を追加するよう求められています。
  • GoDaddyのコンソールにある「DNS名」フィールドに「selector1._domainkey.example.com」を入力します。
  • その結果、「selector1._domainkey.example.com.example.com」という形式になり、これは誤りです。 

未解決のCNAMEレコードを残す

CNAMEは、名前空間の一部をプロバイダーが管理するターゲットに委任するため、そのターゲットが存在しなくなった後もレコードの解決は継続します。たとえば、送信プロバイダーからの移行など、サービスの利用を中止しても、SPF(リターンパス)の委任設定を残したままにすると、エイリアスは依然として、そのプロバイダーがもはやあなたに割り当てていない名前に対して解決されてしまいます。これを「ダングリングCNAME」と呼びます。 

懸念されるのは、未登録のターゲットが他者によって再登録されてしまう可能性があることです。多くのプラットフォームでは、同じ名前でリソースをプロビジョニングした第三者が、あなたのサブドメインが委任したリソースを管理することになり、あなたがレコードを削除または再設定するまで、その管理権限は第三者に留保されます。 

その結果、サブドメインの乗っ取りが発生します。メール認証の文脈において、CNAME レコードを介して無効な SPF 委任の対象となっているドメインを乗っ取った攻撃者は、あなたのドメインのネームスペース下に独自のレコードを公開し、あなたのドメインを偽装して DMARC を通過するメールを送信することが可能になります。 

未解決のCNAMEを解決する方法

解決策は、サービスのライフサイクルに連動したレコードの管理です。サービスの利用を終了する際は、DNSレコードを削除してください。プロバイダーとの契約を終了する際は、CNAMEレコードの削除を必須の手順として扱い、また定期的に既存の委任設定を見直し、その対象が現在使用しているもの、あるいは今後も使用する予定のものかどうかを確認してください。 

CNAMEレコードは、ドメイン所有者やサービスプロバイダーが、DMARC準拠を目的としたSPFやDKIMの整合性をサポートするなど、多くのレコードタイプを一元管理するために使用する、強力かつ一般的なDNSツールです。CNAMEレコードは、ドメインネームスペースの一部を第三者に委任することで管理境界を越えるため、サービスプロバイダーの指示がある場合にのみ、そのレコードを追跡・公開する必要があります。 サービスの提供終了後に残されたレコードは、未解決の委任状態となり、サブドメイン乗っ取りのリスクとなるため、使用されていないCNAMEレコードは速やかにDNSから削除する必要があります。


さらに詳しく議論を続けたい方は、ぜひ dmarcian Forum へお越しください。