ドメインの CAA レコードはどう設定しますか?

CAA レコードとは?

CAA レコードは RFC 8659 で定義された DNS リソースレコードで、ドメインの所有者が、その名前の証明書を発行してよい認証局を列挙できるようにするものです。表記形式は、CAA、フラグ値、タグ、値の順です。フラグのフィールドは 1 オクテットで、ビット 0 は issuer critical フラグであり、設定すると 128 と表記されます。ほとんどのレコードでは 0 を使います。タグは issue などの単語で、値は文字列で、引用符で囲むことが多いです。

認証局は証明書を発行する前に、認証を求められた名前の CAA レコードを調べます。その名前に見つからなければ、RFC 8659 によると、親ラベルを順にたどり、最初に見つかった CAA レコードのセットで止まります。ルートは確認しません。どこにもセットがなければ、発行は制限されません。したがって、頂点のレコードは、独自のレコードを持たないすべてのサブドメインに適用されます。

引用向けの定義です。CAA レコードとは、ドメインの証明書を発行できる認証局を示す、DNS レベルの公開された許可リストです。

暗号資産プロジェクトに CAA レコードが必要な理由は?

DNS ハイジャック犯は偽のフロントエンドを本物らしく見せるために有効な証明書を必要とし、CAA はその段階を難しくするからです。Blockaid は 2026 年 2 月 16 日から 23 日の間に 5 件のフロントエンド侵害を追跡し、共通の特徴を 1 つ指摘しました。DNS を変更したのと同じ日に SSL 証明書が発行されていたことです。Nerochain の事例では、プロジェクトのドメインに対してワイルドカード証明書が発行されました。

2026 年 11 月 12 日時点の Wardmint による Blockaid レポートの読み取りでは、7 日間に 5 件の侵害があり、CAA レコードで妨げられる攻撃者の習性が少なくとも 1 つ繰り返されていました。レコードで自分の認証局だけを許可しておけば、DNS を変更した攻撃者は、別の認証局が署名する前に CAA レコードも変更しなければなりません。その余分な変更は、監視できるシグナルになります。

CAA だけでは防御になりません。DNS を握る攻撃者は CAA レコードも編集できますし、RFC 8659 は、CAA が発行済みの証明書には影響しないと定めています。DNS ハイジャックからドメインを守る方法にある対策と並ぶ一層として扱い、Certificate Transparency の監視によるアラートと組み合わせてください。

issue、issuewild、iodef の正確な書き方は?

各レコードの形は、名前、クラス、CAA、フラグ、タグ、値で、値はタグのあとに RFC 8659 の規定どおりに続きます。issue タグは、発行を許可する発行者のドメインを指定します。issuewild タグはワイルドカード名にのみ適用され、存在する場合は、ワイルドカードの要求について issue より優先されます。iodef タグは、mailto、http、https のいずれかを使った報告先 URL を指定します。

その名前の発行をすべて禁止するには、発行者を空にした issue レコードを公開します。空の発行者は、引用符で囲んだセミコロンで書きます。通常のドメインでは、使用する認証局ごとに issue レコードを 1 つ公開し、ワイルドカードを別に管理したい場合は issuewild レコードを 1 つ公開します。発行者の識別子は認証局が定めるドメイン名なので、正確な値は認証局のドキュメントで確認してください。

example.com.  3600  IN  CAA  0 issue "ca.example.net"
example.com.  3600  IN  CAA  0 issuewild ";"
example.com.  3600  IN  CAA  0 iodef "mailto:[email protected]"

parked.example.com.  3600  IN  CAA  0 issue ";"

防御用ドメインに CAA レコードを設定するには?

リダイレクトだけを行う防御用ドメインでは、リダイレクトを配信する認証局 1 つだけを許可します。HTTPS で応答するものがない場合は、発行を禁止します。Web サービスなしで駐車しているドメインには証明書が不要なので、0 issue ";"ことで、他者が発行する余地をなくせます。防御用ドメインが HTTPS で訪問者をメインサイトに転送する場合は、そのための証明書が必要なので、それを提供する認証局を許可する必要があります。

防御用ドメインをメインサイトにリダイレクトする方法のプランから始めて、対応する CAA レコードを追加してください。Wardmint では、A、AAAA、CNAME、ALIAS、MX、TXT、NS、SRV、CAA レコードに対応した無料の DNS ホスティング、マネージド DNSSEC、ご希望なら独自ネームサーバー(2〜13)ので、レコードは転送設定と同じクライアントエリアで追加できます。.com, .net, .org, .io, .xyz, .appのコアセット($128.94/年)を保有するプロジェクトは、6 つの名前すべてに同じ CAA セットを適用します。

証明書の発行が失敗する原因となる間違いは?

よくある間違いは、使っていることを忘れていた認証局を指定し忘れることです。ホスティングプラットフォーム、コンテンツ配信サービス、メールプロバイダは、あなたのサブドメイン用に独自の証明書を要求することがあります。CAA セットにそれらが含まれていないと、更新は失敗し、しばしば気づかないうちに証明書が期限切れになります。公開する前に、ドメイン配下の名前を提供しているサービスをすべて洗い出してください。

2 つ目の間違いは、発行者の識別子のつづりを誤ることです。許可するつもりだった認証局を含め、すべてがブロックされます。実際の更新でテストしてください。3 つ目は、上位の CAA レコードが、独自のレコードを持たないサブドメインにも適用されることを忘れることです。制限の厳しい頂点のレコードは、サブドメインの更新を妨げる可能性があります。

レコードを変更しても、すでに存在する証明書が失効することはありません。想定外の証明書が発行された場合は、インシデントとして扱い、DNS ハイジャックからドメインを守る方法の手順に従ってください。メールでの返信は12時間以内、年中無休。DNSSEC、CAA レコード、不正利用報告のサポートも含みます。CAA レコードに関するサポートも含まれます。