要約

  • RFC 6844はドメイン名の保有者が、その名前の証明書を発行できる認証局をDNSに示せるようにした。初期の検索規則はCNAMEやDNAMEをたどり、別名の先にある親の名前も調べたため、ホスティング事業者のCAA方針が顧客名の発行確認に入り得た。
  • RFC 8659は通常のDNS別名解決を残しながら、親をたどる検索を審査対象の完全修飾ドメイン名に限定した。顧客の方針と事業者の名前空間との境界を、より明確にした変更だ。

DNSの答えだけでは発行可否は決まらない

仮の例として、www.client.example が tenant.platform.example を指すCNAMEだとする。顧客の名前は共有ホスティング事業者の名前空間を経由する。認証局は証明書を発行する前に、もう一つ確認する。www.client.example に適用されるCAAレコードはどれか。

名前解決が境界をまたぐと、この問いは単純でなくなる。顧客は一つのDNS名前空間を管理し、ホスティング事業者は別の名前空間を管理する。リゾルバーは一瞬で別名をたどれる。顧客が自分のゾーンに一度も書いていない方針を適用するため、認証局も事業者側の親名まで検索すべきだろうか。

2013年1月のRFC 6844は、DNSのCertification Authority Authorizationレコード、タイプ257を定義した。ドメイン名の保有者は、その名前の証明書を発行できる認証局を一つ以上指定できる。規格に準拠する認証局は発行前に該当するCAAレコードを調べ、認められない要求を拒まなければならない。ただし認証局の証明書ポリシーや運用規程に例外があれば、その例外が適用される。

CAAは、保有者が名前のほかの情報と同じ場所、つまりDNSに発行方針を書ける仕組みだった。認証局は発行前にその方針を確かめる。問題は、DNS名をまたぐ検索で「該当する」がどの範囲を指すかだった。

2013年の検索は二つの名前の木を進めた

RFC 6844の規則は、問い合わせた名前から親へ上るだけではない。あるラベルでCAAレコードがなく、そこにCNAMEまたはDNAMEの別名があれば、その先をたどって再帰的に検索できた。そこでも見つからない場合に、元の名前の親へ進む。

仮の名前で動きを見てみよう。www.client.example が tenant.platform.example を指し、事業者が platform.example に CAA 0 issue "issuer.example" を置いたとする。RFC 6844の再帰規則では、別名の先へ進んだ後、さらに親の platform.example まで検索してこの方針を見つけ得る。事業者の親ゾーンに置かれたレコードが、顧客名の発行検索に入る可能性があった。

規則は適用されるCAAレコードを探すもので、顧客ドメインの所有権を事業者へ移すものではない。それでもDNS解決と方針の継承は同じ再帰処理の中を進んだ。顧客名が事業者の別名を経由し、その親ゾーンの方針に届く。共有ホスティングでは、事業者が名前の上位に置いたルールが顧客ごとに適用されかねなかった。

2019年、親への検索は要求された名前の木にとどまった

2019年11月公開のRFC 8659はRFC 6844を置き換え、処理アルゴリズムを改めた。認証局は今も要求された完全修飾ドメイン名について通常のDNS問い合わせを行い、その中で別名をたどることもある。CAAレコードが返らなければ、審査対象の名前の親ラベルを上へたどる。見つかったCNAMEやDNAMEの各ターゲットについて、別々に親の名前をたどる処理はしなくなった。

差は小さく見えるが、意味がある。別名のターゲットそのものにCAAレコードがあれば、通常のDNS問い合わせで返ることはある。変わったのは、そのターゲットの親を別途上へたどる部分だ。顧客の親方針は引き続き顧客のサブドメインに適用できる。一方、CNAMEが事業者の名前空間を指すだけで、事業者の親方針まで顧客の検索に入るわけではなくなった。

RFC 8659自身は、RFC 6844との差分として理由を述べている。多くの別名を持つ名前で、元の名前と各別名の双方を親まで検索すると非効率になる。また、ホスティング事業者が自社のFQDNにCAA方針を設定しながら、顧客に望まない方針を適用しないことが難しくなる。改訂後の問いは絞られた。通常のDNS別名解決の結果、この要求名にどのCAAセットが返り、その名前自身の親には何があるか。

これは発行時の認可確認であり、ブラウザーの検証ではない

CAAが働くのは証明書を発行する前だ。発行済みの証明書をブラウザーが再判定する仕組みではなく、DNSを変更しても既存証明書は失効しない。規格は、証明書を使う側が現在のCAAレコードを証明書検証に使うことを禁じている。記録されるのは発行時点の認可であり、その時刻が重要になる。

CAAレコード自体がDNSの回答を認証するわけでもない。RFC 8659はDNSSECを強く推奨するが、必須にはしていない。問い合わせが遮断されたり、壊れた応答が届いたり、空の回答を誤処理したりすれば、認証局は方針を読めない。規格の運用上の注意がこうした問題を並べるのは、発行者が記録を取得して解釈できて初めて制御が働くからだ。

CAAには複数のプロパティがある。issueは通常の証明書に使い、issuewildがあればワイルドカード証明書の要求を扱う。空の発行者値は、どの認証局にも発行させない要求を表せる。タグは方針の内容を記す。2019年の改訂は、その内容をどの名前の木から探すかを定め直した。

歴史的な変化はここにある。最初のCAA規格は、ドメイン保有者が発行者をDNSで指定できるようにした。後継規格は、その名前の木とホスティング事業者の木との境界を見直した。DNS問い合わせは引き続き別名を解決するが、認可検索ではすべての宛先の親を顧客名の親として扱わない。

ここで使った名前はアルゴリズムから組み立てた例であり、報告済みの事故ではない。RFCから分かるのは意図された規則だ。各認証局の実装を測るには、ドメイン名と時刻を結び付けたCAA問い合わせおよび発行判断のログが必要になる。

出典