メインコンテンツへスキップ
未使用のDNSレコード:使用されていないCNAMEレコードの削除

未使用のDNSレコード:使用されていないCNAMEレコードの削除

セキュリティに関する洞察技術ガイダンス

当社のサポートチームは最近、ドメインのDNSに未使用の、あるいは「ダングリング」CNAMEレコードを残してしまうという、よくあるDNSのセキュリティ上の脆弱性について調査を行いました。本記事では、サポートスペシャリストのスティーブン・イアコヴィエロが中心となり、CNAMEレコードの管理に関するベストプラクティスについて解説します。  

CNAME(正規名)レコードとは何ですか?

CNAMEレコードは、エイリアスドメインを正規のドメイン名に紐付けるために使用されるDNSレコードの一種です。多くの場合、CNAMEレコードは、認証の一致確認において表示されるポリシーを自社のドメインと一致させたまま、SPFやDKIMレコードをメールサービスプロバイダーなどのサードパーティベンダーに委任するために使用されます。この方法の利点は、サードパーティがSPFやDKIMレコードをリモートで管理できるため、レポート作成が簡素化され、DNSレコードを編集することなく更新が可能になる点にあります。

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

CNAMEレコードは、SPFレコードと組み合わせて使用され、送信元IPアドレスの認証を別のドメインのSPFポリシーに委任するために用いられます。

たとえば、subdomain.example-some-group.com がCNAME レコードによってsubdomain.example.com を指しているとします。 

すると、サブドメイン `subdomain.example.com` は、以下のSPFレコードを指すようになります:
v=spf1 include:myownpersonaldomain.com include:example-pet-store.com -allSPFレコード。 

デフォルトでは、CNAME「subdomain.example.com」の所有者は、そのCNAMEで指定されたドメインを管理しているため、SPFに任意のIPアドレスを追加することができます。

使用されていないCNAMEレコードがもたらす潜在的な危険

「ダングリングCNAMEレコード」とは、組織が、もはや使用していない、あるいは必要としないドメイン、サードパーティのサービス、またはクラウドリソースに対して、CNAMEレコードを引き続き設定し続けている状態を指します。 

CNAMEのドメイン所有者が、悪意のある活動のためにそのドメインを購入した新たな所有者に変更された場合、これらのレコードが悪用される可能性があります。

例えば、前述のケースにおいて、組織が当該サービスの利用を中止したにもかかわらず、DNSからCNAMEレコード「subdomain.example.com」を削除しなかったとします。このCNAMEレコードは存在しないリソースを指し示したままとなり、未解決の状態となります。その後、このCNAMEドメインが悪意のある第三者に売却されると、その第三者はこれを悪用して不正な活動を行うことが可能になります。攻撃者はこうしたDNSレコードを操作することで、悪意のあるサイトをホストしたり、フィッシング攻撃を仕掛けたり、マルウェアを拡散させたりすることができるようになります。

私たちが確認したところ、CNAMEの新しいドメイン所有者が、自身が作成したSPFレコードを指す設定を行い、そのIPアドレスから不正なメールを送信していることが判明しました。当該組織がCNAMEで指定されているため、それらのIPアドレスはすべて、その組織に代わってメールを送信する権限が与えられていることになります。 

たとえ組織のDMARCポリシーが p=rejectであっても、送信されるこれらの悪意のあるメールはDMARCに準拠しており、悪意のある送信者が自ら選択したIPアドレスからメールを送信しているため、SPFによる照合によりDMARCを通過してしまいます。

DNSの健全性を保つためのCNAMEのベストプラクティス

CNAMEがセキュリティ上の脆弱性とならないよう、日常的なDNS管理を徹底することは重要です。以下に、未解決のCNAMEによるリスクを最小限に抑えるための対策をご紹介します:

  1. 自社ドメインを利用しているサードパーティベンダーについて、定期的に確認を行い、それらのサービスが現在も使用されているかを確認してください。サービスを廃止する際は、悪用されないよう、関連するDNSレコードを削除してください。
  2. CNAMEレコードを確認し、正当なドメインを指しているか確認してください。そうでない場合は、不要なCNAMEレコードを削除できます。
  3. SPFレコードを確認し、不要なものを削除してください
  4. 重要なセキュリティ対策として、DMARCおよびDKIMによるメール認証を導入してください。まずは当社のDMARCドメインチェッカーをご利用ください。

また、MAIL FROMサブドメインが CNAME 経由で SPF レコードを取得していないか確認しておくのも良いでしょう。もし SPF レコードが CNAME 経由であることが判明した場合、その CNAME を確認し、組織が当該サービスを利用しなくなったことが確認できれば、DNS からその CNAME を削除する必要があります。 

DMARCとdmarcianで可視性を高める 

DMARCは、新しいメール送信元や送信元からのデータ傾向を特定し、実用的な知見を得るのに役立ちます。当社のDMARC管理プラットフォームを活用して、未知の送信元を特定しましょう。ダングリングDNSの悪用が発生すると、詳細ビューアに複数のPTR/サーバー名や未知の送信元が表示され、SPF整合性は100%、DKIM整合性は0%、MAIL FROMサブドメインが確認できるようになります。さらに、当社のプラットフォームは新しいサブドメインを自動的に検知・監視し、完全な可視性を確保するとともに、フィッシング攻撃や設定ミスのある正規サービスなどのリスクを特定します。

アラートセンター

アラート送信のトリガーとなるドメインイベントに基づき、カスタマイズ可能な「Alert Central」機能を利用すれば、dmarcianアカウントにログインすることなくドメインを監視できます。イベントには、DNSレコードの新規登録や変更、ドメインごとのトラフィックカテゴリにおけるトラフィック量の変動などが含まれます。また、見慣れないサブドメインを監視するためのアラートを作成することも重要です。これは、CNAMEの悪用を示唆する可能性があるためです。    

アラート用の一般的な通知手段として、メール、Slack、Teams、Webhookなどが利用可能です。アラートにはイベントの詳細と、さらに詳しい情報を確認できるdmarcianのタイムラインへのリンクが表示されます。

Alert Central を設定することで、ダングリング CNAME やその他のセキュリティ上の脆弱性によって引き起こされる可能性のあるドメインの不正利用を検知できるようになります。アラートの種類にかかわらず、変更を迅速に発見し、必要に応じて是正措置を講じることが重要です。

私たちは、皆様がDMARCを理解し、安全に導入できるようサポートいたします。CNAMEや当社のサポートサービスについてご質問がございましたら、お気軽にお問い合わせください


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