CAAレコードの直し方

CAAレコードは、ドメインの設定に記す短い指示で、あなたのウェブサイトの『鍵マーク』のセキュリティ証明書を発行してよい証明書会社を名指しします。これをオンにすると、他のどの会社もあなたの名前で有効な証明書を静かに作れなくなります。

あなたのビジネスにとっての結論： CAAレコードがないと、世界中の数百の証明書会社のほぼどれもが、あなたのドメインの本物で完全に信頼された鍵マーク証明書を発行できます—詐欺師が、完璧で完全に『安全』に見えるサイトのクローンを立ち上げ、画面上に警告が出ないまま顧客のログインやカード情報を収集できるのです。

これで失いかねないもの

詐欺師があなたのサイトのコピーの本物の証明書を取得し、緑の鍵マークとHTTPSを表示します—顧客には何も異常が見えず、パスワードやカード番号を入力し、チャージバックや怒りの電話が始まって初めて気づきます。
顧客が、あなたのログインページのピクセル単位でそっくりな偽物でフィッシングされます。その後始末—返金、サポートの負担、評判の損害—は、本物のサイトが一度も触れられていなくても、あなたのブランドに降りかかります。
見込み客のセキュリティ・調達チームが契約前に手早くドメインを調べ、CAA保護がないのを見て、静かに『基本に弱い』と減点します—5分で追加できる設定のために商談を危険にさらします。
世界の証明書会社のひとつが侵害され（これは繰り返し起きています—DigiNotar、Comodo、Symantec）、あなたが誰に代理を許すか一度も言っていないため、最も弱い環になった会社の影響にあなたのドメインがさらされます。

なぜ重要か。 今、扉は大きく開いています。地球上のどの証明書会社も、あなたと取引したことがあろうとなかろうと、あなたを名乗るサイトを保証できます。CAAレコードはその扉を施錠し、あなたが選んだプロバイダーだけが証明書を発行できるようにします—オンラインで会社になりすまされることに対する、最も単純で最も安い防御です。

CAAレコード、平易に言うと

すべての安全なウェブサイトには証明書があります—ブラウザの鍵マークやアドレスの前の『https』の背後にあるものです。それらの証明書は証明書認証局（CA）と呼ばれる専門会社が交付します。Let’s Encrypt、DigiCert、Sectigo、Google Trust Servicesといった名前です。ブラウザが有効な証明書を見ると、鍵マークを表示し、接続が本物で安全だと顧客に告げます。

ほとんどの経営者が一度も教わっていない部分はこうです。初期状態では、世界中の数百のこれらの証明書認証局が、それぞれあなたのドメインの証明書を発行することを許されています—あなたが聞いたことがあろうとなかろうと。CAAレコード（Certification Authority Authorization）は、ドメインのDNS設定に追加する1行の覚書で、実質的に『これらのプロバイダーだけが私の証明書を発行してよい』と言います。すべての正規の証明書認証局は、業界のルールにより、発行前にその覚書を確認し、リストになければ拒否することを義務づけられています。

誰でも歩いて通れる施錠されていない玄関ドアと、あなたが選んだ人だけが鍵を持つドアの違いです。そして追加に費用はかかりません。

これが招きうる損失

CAAレコードが閉じるリスクは説得力のあるなりすましです。詐欺師があなたのサイトのコピーの本物の証明書を取得できると、通常の警告サインが消えます—壊れた鍵マークも、『安全でない』バナーも、証明書エラーもありません。すべてが正しく見え、まさにそれが危険なのです。

完璧な偽物。 詐欺師がそっくりのアドレスを登録（あるいは顧客への経路を侵害）し、本物の証明書を取得し、ログインや決済ページの完璧なクローンを—鍵マークごと—立ち上げます。顧客はいつものようにパスワードやカード番号を入力します。あなたが最初に知るのは、チャージバック・不正報告・怒りの電話の波です。
あなたの名前でのフィッシングキャンペーン。 攻撃者が『アカウントを確認してください』というメールを送り、証明書付きのクローンへリンクします。ページが完全に安全に見えるため、より多くの人が引っかかります。後始末—顧客への通知、返金、サポート時間、気まずい公の説明—はすべて、本物のサーバーが一度も触れられていなくても、あなたに降りかかります。
チェックリストで止まる商談。 大口顧客のセキュリティ・調達チームが契約前にドメインをスキャンします。『CAAレコードなし』があなたの名前の横に赤や黄の項目として現れます。技術的には小さなことですが、『基本をカバーしていない』と読め、勝てたはずの契約を遅らせたり沈めたりします。
他者の侵害に巻き込まれる。 取引したことのない証明書認証局が侵害されます—これは仮定の話ではありません。DigiNotar、Comodo、Symantecはすべて深刻なインシデントを起こしています。誰に代理を許すか制限しなかったため、攻撃者はその弱いCAを通じてあなたのドメインの有効な証明書を取得できます。CAAレコードがあれば拒否されていました。
ワイルドカードの盲点。 主サイトに気をつける企業でも、しばしばサブドメインを忘れます。issuewildルールがないと、ワイルドカード証明書を取得できる攻撃者は、これから持つすべてのサブドメインへの鍵を一度に手にすることになります。

これらはどれもサーバーへの巧妙な攻撃を必要としません。CAAレコードがないと、広い証明書システムがあなたに代わって単に信用しすぎるという事実を突くのです。

これの実体と『良い』状態

CAAレコードはドメインのDNS—ドメインをウェブサイトやメールに向けるのと同じ設定—にあります。各レコードには3つの部分があります。フラグ、タグ、値です。重要なタグは：

issue — ドメインの通常の証明書を発行してよい証明書認証局を名指しします。正当に使うプロバイダーごとに1つずつ、複数持てます。
issuewild — ワイルドカード証明書（すべてのサブドメインをカバーする1つの証明書、例：*.example.com）を制御します。ワイルドカードを使わないなら、推奨設定は完全にブロックします。
iodef — 任意の連絡先アドレスで、CAAポリシーのために証明書認証局が要求を拒否したときに通知を受けられます。誰かが試みたという早期警告です。

『良い』状態とは： 少なくとも1つのissue（またはissuewild）レコードが存在し、実際に使うプロバイダーを名指しし、ワイルドカードは名指ししたプロバイダーに限定されているかブロックされていること。それがこの検査が測る基準です—いくつかの独立したリゾルバーであなたのドメインのCAAレコードを調べ、本物のissueまたはissuewildポリシーが整っているときに合格します。CAAレコードがまったくないドメインは、開いた扉として扱われます。

これは評点に影響しますか？ はい。欠けているCAAレコードは評点付きの項目で、中重大度で指摘されます—あると良いだけのものではなく正真正銘のギャップです。実在のなりすまし経路を開いたままにするからです。レコードを追加するとギャップが閉じ、指摘が消えます。

修正方法（無料・約5分）

ドメインやウェブサイトを管理する人にこの項を渡してください。修正は無料です。 再構築ではなく小さなDNS変更です。当社が料金をいただくのは、後でレコードが維持されているか監視をご希望の場合のみで、追加には費用がかかりません。

ステップ1 — 実際に使っている証明書認証局を確認する。 正しくする価値のある唯一のステップです。間違ったプロバイダーを列挙すると次の更新をブロックしかねないからです。一般的なケース：

Let’s Encrypt — 多くのホストやコントロールパネル（cPanel、Plesk）が使用 → letsencrypt.org
Cloudflare（エッジ証明書を発行する場合）→ letsencrypt.org、digicert.com、comodoca.com、pki.goog、ssl.com（Cloudflareは複数のバックエンドCAを使うので、ダッシュボードが示すもの、またはその全集合を列挙し、更新が決して壊れないようにします）
Google Workspace / Google Trust Services → pki.goog
DigiCert → digicert.com
Sectigo / Comodo → sectigo.com（およびcomodoca.com）
Microsoft 365 / Azure — Microsoftはマネージド証明書に通常DigiCertを使用 → digicert.com（ポータルで確認）

不明な場合は、ブラウザで現在の証明書を見て（鍵マークをクリック → 証明書の詳細 → 『発行元』）誰が発行したか確認します。

ステップ2 — DNSプロバイダーにログインする。 ドメインのレコードがある場所—通常はレジストラ、ウェブホスト、Cloudflare。DNSレコードのセクションを見つけ、種類CAAの新しいレコードを追加します（インターフェースによっては種類257と表示）。

ステップ3 — 使うプロバイダーごとにissueレコードを追加する。 例えばLet’s Encryptなら：

example.com.   CAA   0 issue "letsencrypt.org"

正当なプロバイダーごとにissue行を1つ追加します。ほとんどのDNSダッシュボードは、フラグ（0）・タグ（issue）・値（CAのドメイン）に別々の入力欄を用意するので、行全体を手で打つ必要はありません。

ステップ4 — ワイルドカード証明書を制御する。 ワイルドカードを使わないなら、誰も静かに取得できないよう完全にブロックします：

example.com.   CAA   0 issuewild ";"

ワイルドカードを使うなら、代わりにプロバイダーを名指しします：0 issuewild "letsencrypt.org"。

ステップ5 —（推奨）通知アドレスを追加する。 CAが試みを拒否したら知らされるよう—誰かが試みたという早期警告です：

example.com.   CAA   0 iodef "mailto:[email protected]"

ステップ6 — 保存して検証する。 dig CAA example.comを実行（または任意のオンラインDNS検索ツールを使用）してレコードが現れることを確認します。変更がインターネット全体に広がるのに数分から数時間かかります。既存の証明書とすべての更新は、その間も機能し続けます—CAAは新規の発行だけを司ります。

プラットフォーム別の手早い注記： CloudflareではDNS → Records → Add record → 種類CAA。Google Workspaceではレジストラ（またはCloud DNSを使うならそこ）でDNSを管理します—そこにpki.googでCAAレコードを追加します。Microsoft 365ではM365管理センターでCAAを設定しません。ドメインのDNSがホストされている場所で、マネージド証明書のCA（一般にDigiCert）を列挙して追加します。一般的なホスト（GoDaddy、Namecheap、Blacknightなど）では、AやMXレコードと同じDNSパネルにあります。

よくある間違い

間違ったCAを列挙する—または1つ忘れる。 現実世界で最大のリスクはセキュリティではなく、自分の更新をブロックすることです。複数の発行者を使うなら（例えば主サイト用とCloudflare背後用）、すべて列挙してください。迷ったら、少なすぎるより信頼するものをいくつか列挙しましょう。
issueは設定するがワイルドカードを無視する。 通常の証明書を制限してもワイルドカードについて何も言わないドメインは、より強力なワイルドカード経路を開いたままにします。常にissuewildも設定—プロバイダーへ、または";"でブロックします。
CAAを間違った名前に置く。 CAAは証明書を発行する正確な名前について証明書認証局が読み、木をのぼります。ドメインの頂点（『apex』、例：example.com）に設定するのが正しい—サブドメインが独自に設定しない限り、初期状態でサブドメインをカバーします。
プラットフォームがすでにやったと思い込む。 Cloudflare、Google、Microsoftは証明書を管理しますが、CAAレコードはあなたのために追加しません。追加していない限り、あなたのドメインは依然として開いています。
一度きりで監視なしと扱う。 後のDNS移行、レジストラ変更、レコードの『整理』がCAA保護を静かに落としかねません。DNS変更の後はまだあるか確認する価値があります。

技術層（IT担当へ渡す内容）

CAAはRFC 8659で定義され、CA/Browser Forum Baseline Requirementsの下で強制されます—公的に信頼されたすべてのCAは発行時にCAAを確認することを義務づけられています。レコードは<flags> <tag> <value>の形を取り、タグはissue、issuewild、iodefです。空でないissueまたはissuewildポリシーがこの検査を満たすもので、iodef単独では満たしません（認可ではなく報告です）。

apexでの手堅い基準：

example.com.   CAA   0 issue "letsencrypt.org"
example.com.   CAA   0 issuewild ";"
example.com.   CAA   0 iodef "mailto:[email protected]"

実装者への注記：

CAAのツリークライミング： CAは要求されたFQDNから上方へapexまでCAAを評価し、CAAレコードが設定された最初の名前で止まります。したがってapexのレコードは、サブドメインが独自に公開しない限りすべてのサブドメインを保護します（独自公開も可能で、特定のサブドメインが別の発行者を使う場合に有用）。
issuewildの;値は『どのCAもワイルドカードを発行してはならない』を意味します—明示的な拒否です。ワイルドカードが構成の一部でないときは常に使ってください。
0フラグはissuer-criticalフラグで、0（非クリティカル）が通常の使用には正しい。完全に理解しない限りクリティカルビットを設定しないこと。誤解されたクリティカルタグは準拠CAに発行を拒否させかねません。
複数の発行者： 複数のissueレコードが許され加算されます—スタック内の正当なすべてのCA（CDN/エッジプロバイダーが使うバックエンドCAを含む）を列挙し、更新の失敗を防ぎます。
検証： dig CAA example.com +short、またはCA/Browser ForumのCAAテストツールで確認します。この検査自体は複数の独立したリゾルバー（ローカルDNS、次にGoogle・Cloudflare・Quad9のDNS-over-HTTPSをフォールバック）でCAAを照会し、最初の権威ある回答を受け入れるので、単一のリゾルバー障害が誤った『CAAなし』結果を生むことはありません。
DNSSECとの組み合わせ： CAAは誰が発行してよいかをCAに告げ、DNSSECはCAAの回答自体が転送中に偽造されるのを止めます。互いを補完します—価値の高いドメインには両方を運用してください。

ご利用のホストで設定する

主要な事業者向けのステップ別ガイド：

よくある質問

技術に詳しくありません。自分で対応できますか？

細部を理解する必要はありませんが、修正はドメインのDNS設定内の小さな変更なので、ウェブサイトやドメインを管理する人に渡すのが最善です。下の『修正方法』の項を送ってください—5分・無料の変更です。当社が料金をいただくのは、後でレコードが維持されているか監視をご希望の場合のみで、修正そのものは常に無料です。

これを追加するとサイトや証明書が壊れますか？

いいえ—実際に使っている証明書プロバイダーを列挙する限り、すべてこれまでどおり動きます。CAAレコードは既存の証明書に触れたり置き換えたりせず、誰が新しいものを作ってよいかだけを司ります。問題を起こす唯一の道は、本物のプロバイダーをリストから漏らすことで、次の自動更新をブロックしかねません—下の手順はまさにそれを避けるよう書かれています。

最近は証明書が自動発行されるのに、なぜまだこれが必要なのですか？

自動証明書は結構で便利です—問題は、その仕組みが初期状態で全員に開かれていて、あなたを装う者も含むことです。CAAレコードは誰が許されるかを名指しするだけで、開いた扉を自分の鍵のかかったものに変えます。自動発行に逆らうのではなく、並んで機能します。

これはGoogleの順位やこのレポートの評点に影響しますか？

ここでのセキュリティ評点に影響します—欠けているCAAレコードは評点付きの項目で、中重大度のギャップと表示されます。実在のなりすまし経路を開いたままにするからです。直接のGoogle順位要因ではありませんが、それが防ぐなりすましやフィッシングは、まさに信頼と流入を損なうインシデントです。いずれにせよ手早く無料の勝ちです。

『issue』と『issuewild』の違いは？

『issue』レコードはドメインとそのサブドメインの通常の証明書を制御します。『issuewild』レコードはワイルドカード証明書—すべての可能なサブドメインを一度にカバーする単一の証明書（*.example.comのような）—を制御します。ワイルドカードはより強力で、間違った手にあるとよりリスクが高いので、別々に制御するのが良い習慣です。ワイルドカードを使わないなら、完全にブロックしましょう。

Cloudflare / Google Workspace / Microsoft 365 を使っています。これですでにカバーされていますか？

自動的にはされません。それらのプラットフォームは証明書を管理しますが、明示的にCAAレコードを追加していない限り、あなたのドメインは依然として『どの機関も発行してよい』と世界に告げています。良い知らせは、修正はどれでも同じ単純なDNS変更で、Cloudflareやホストが証明書を発行する場合はそのプロバイダーを列挙するだけです。下の修正の項のプラットフォーム注記が一般的なケースをカバーします。

CAAレコード の直し方