【ITニュース解説】Fintech Mail Hostname Broke After Adding DNS (CNAME Exclusivity at Apex)

DNSレコードの変更が、会社のメールシステムに予期せぬ障害を引き起こすことがある。特に、ウェブサイトのアドレスを設定しようとしたつもりが、メールの送受信ができなくなるという事態は珍しくない。これは、DNS（Domain Name System）の特定のルールを理解していないと陥りがちな問題である。

DNSはインターネットの住所録のようなもので、ウェブサイト名やメールアドレスなどをコンピューターが理解できる数字のIPアドレスに変換する役割を担う。この住所録にはさまざまな種類の「レコード」が登録されており、それぞれが異なる情報を表している。例えば、ウェブサイトのアドレスを示すAレコード、メールの配送先を示すMXレコード、テキスト情報を示すTXTレコードなどがある。今回問題となるのは「CNAMEレコード」で、これはある名前が別の名前の「別名（エイリアス）」であることを示すレコードだ。例えば「blog.example.com」を「example.wordpress.com」の別名として設定するような場合に使う。

しかし、このCNAMEレコードには非常に厳格なルールがあり、同じ名前の場所にCNAMEレコードが存在する場合、そこにはAレコードやMXレコード、TXTレコードといった他の種類のレコードを一緒に設定することができない。CNAMEは「排他的」な存在であり、一つの名前に対して「これは別名です」という指示と「これはメールサーバーです」という指示が同時に存在することは許されないのだ。これはDNSの基本的なデータモデルにおける制約であり、設定の伝播が遅れるといった一時的な現象ではない。

例えば、ledger.exampleというドメインにすでに会社のメールを配送するためのMXレコードが設定されているとする。この同じledger.exampleに対して、ウェブサイト用のCNAMEレコードを追加し、別のターゲットへ転送しようとすると、矛盾した指示が同じ名前の場所で発生する。片方はこの名前が別名であることを示し、もう片方はメールサーバーが直接関連付けられていることを示すため、標準に準拠したDNSゾーンでは両方を同時に公開することはできない。この衝突は、DNS設定の編集ツールによっては変更を拒否したり、既存のデータを上書きしてしまったり、あるいは混乱を招くような中間的な状態を作り出してしまったりする原因となる。

さらに、ドメインの一番根元の部分、つまりexample.comのような「ゾーンエイペックス」と呼ばれる場所には、特別なレコード（SOAやNSレコード）が必ず存在するため、ここに一般的なCNAMEレコードを直接設定することも原則としてできない。一部のDNSサービスでは、特別な仕組みでエイペックスでのエイリアスを可能にするが、それは一般的なCNAMEレコードのルールとは異なる特殊な機能であることに注意が必要だ。

メールシステムはMXレコードだけでなく、送信者の認証を行うためのSPFやDMARCといった、TXTレコードを使って設定されるポリシーにも依存している。これらのレコードも、特定の名前（_dmarc.example.comなど）の下に設定される。ウェブサイトのルーティング変更のような一見小さな変更でも、同じ所有者名（ドメイン名やサブドメイン名）でこれらのメール関連レコードとCNAMEレコードが衝突すると、メールシステム全体に大きな影響が及ぶ可能性がある。

このような問題を避けるためには、DNSレコードを設定する際の「所有権の境界」を明確にすることが非常に重要となる。会社のメールシステムは、会社自身が完全に制御できる「顧客所有ゾーン」で管理すべきだ。つまり、メールの配送先を示すMXレコードや、認証ポリシーを定義するTXTレコードは、会社のメインドメイン（例：ledger.example）の下に置き、会社が責任を持って管理する。一方で、特定のサービスへのエイリアス（CNAME）を設定したい場合は、それをメインドメインとは異なる、専用のサブドメイン（例：portal.ledger.example）に設定することが推奨される。こうすることで、メインドメインのメール設定と、特定のサービスへのエイリアス設定が衝突することなく共存できる。これは、コードによっても事前に検証できる原則であり、例えばアプリケーションのデプロイ時にCNAMEが他のレコードと共存していないか、エイペックスにCNAMEが設定されていないかなどをチェックできる。

もしDNSレコードの変更後にメールに問題が発生した場合は、焦らず正しい手順でデバッグを行う必要がある。まず、最初に確認すべきは、自分たちが利用しているDNSサービスが実際に管理している「権威DNSサーバー」からの回答である。パソコンで通常利用するキャッシュDNSサーバーの情報を信用する前に、必ず権威サーバーに直接問い合わせを行い、MX、CNAME、TXTなどの関係するレコードがどのように設定されているかを確認する。これは、digコマンドなどのツールを使って、特定の権威サーバーを指定して問い合わせることで可能だ。権威サーバーからの回答が正しい設定を示しているにもかかわらず、メールが届かない場合は、キャッシュDNSサーバーの情報の更新遅延（TTLの期限切れ待ち）が原因である可能性がある。しかし、まず権威サーバーの一貫性を確認することが最優先である。ウェブサイトのAレコードが正しく引けることだけをもって、メールシステムが健全であると判断してはいけない。それぞれ異なるレコードタイプであり、異なる質問に対する答えだからである。

DNSレコードの変更は、システムの根幹に関わる重要な操作であるため、慎重な計画と実行が求められる。変更前には、既存のすべての権威サーバーから現在のレコード設定を完全にスナップショットとして取得しておくことが不可欠だ。そして、新しいレコード設定が既存のルールに違反していないかを事前に検証する。変更を公開した後は、再度すべての権威サーバーからの回答を確認し、意図した通りにレコードが反映されているかを検証する。その後、複数のキャッシュDNSサーバーを通じてのテストや、実際にメールを送受信する「SMTPレベルのテスト」を行うことで、エンドツーエンドでの動作確認を行う。

万が一問題が発生した場合に備え、元の状態に戻すための「ロールバック計画」も必須である。この際、単に新しいレコードを削除するだけでは不十分な場合がある。元のMXレコードやTXTレコードが上書きされて消えてしまっている可能性もあるため、必ず元の完全なレコードセットを復元できるよう準備しておく必要がある。削除はロールバックではないことを理解する必要がある。

会社のメールシステムや主要なドメインは、ルーティングや認証ポリシー、インシデント対応など、会社が完全にコントロールする必要があるため、「顧客所有ゾーン」で管理するのが最も適切である。一方、特定のアプリケーションやサービスで、プロバイダーが自由にレコードを作成・変更する必要がある場合は、メインドメインから「サブドメインを委譲」し、「プラットフォーム所有ゾーン」として運用させる方法がある。しかし、この委譲するサブドメインが、メインドメインのメールなど重要なレコードと重ならないように、明確な境界を設定することが重要だ。

最終的に、システムエンジニアがDNSレコードを扱う上で最も重要なのは、会社の組織ドメインの所有権を会社自身がしっかりと保持し、メール関連のMXやポリシーレコードはそこに維持することである。ウェブサービスなどのエイリアスは、専用のサブドメインに分離し、CNAMEの排他性ルールを常に意識して設定を検証する。変更前後の権威DNSサーバーからの回答を徹底的に比較し、メール配信を含むサービス全体のテストを行う。そして、問題発生時に速やかに元の状態に戻せるよう、確実なロールバック計画を準備しておくことが、安定したシステム運用には不可欠となる。小さな変更範囲で確実に作業を進めることが、予期せぬ障害を防ぐ最善策だ。