← 一覧へ戻る

Claude が書いた記事

「CNAME ベースのドメイン検証 (DCV) が廃止」は何が消えたのか ── 直接 / 委任 / TXT の 3 方式と、Front Door に降ってくるまで

「CNAME は自動更新できて最高」と聞いた直後に「CNAME ベース DCV 廃止」のニュース。矛盾に見えるこれを、消えた『委任』と生き残った『直接』に分けてほどいた学習ログ。

俺の最初の疑問

Azure Front Door のドキュメントに「CNAME ベースのドメイン検証 (DCV) を廃止」と書いてあった。

ナンノコッチャ全く意味がわからんかった。CNAME なくしたら、どうやってアプリケーション通信すんねんって。

まず一言でいうと

  • DCV (Domain Control Validation) は証明書のことではなく、証明書発行前の「あんた本当にこのドメインの持ち主か？」を確認するプロセスのこと。パスポートに貼る旅行ビザを出す前の本人確認にあたる。
  • その確認手段に「CNAME」と名のつくものが 2 種類ある。①直接 CNAME と ②CNAME 委任 (delegation) の 2 つだ。
  • Front Door のドキュメントで「CNAME ベース DCV 廃止」と書いてあるのは ② CNAME 委任の方だ。①直接 CNAME は生き残っている。

何と比べるとわかるか ── DCV は証明書やなく「ビザ申請の本人確認」

ここを混ぜると一生モヤる。DCV と証明書は別物や。

役割たとえ
DCV発行する前に所有者を確認するプロセスビザを出す前の本人確認 (自分にしか出せない書類を提出)
証明書 (TLS cert)確認が通った後に発行される本体確認を通って発給されるビザ (査証) そのもの

CNAME / TXT / メールといった証明書を発行するときにドメイン所有者であることを証明する各方式は、全部 DCV の話 ── つまりどの書類で本人確認するかにあたる。証明書 (ビザ) の中身や強度とは関係ない。今回廃止されたのも確認のやり方の一種であって、証明書が消えるわけやない。

まず大前提 ── dig で見る CNAME と、DCV の CNAME は別物

CNAME の話に入る前に、ここを切り分けておかんと全部混ざる。あなたが普段 dig で見てる CNAME と、今回の主役 (DCV の CNAME) は別物や。同じレコード種やけど、目的も読む人も違う。

観点通信用の CNAMEDCV の CNAME
例www.example.com → example.azurefd.net_dnsauth.www.example.com → 検証先
役割通信の道案内 (カスタムドメインを Front Door エンドポイントに向ける)ドメイン所有を証明する審査
名前の頭www などの素のホスト名_dnsauth (_ で始まる)
読む人世界中のブラウザCA (DigiCert)
いつ読む常時証明書を発行・更新する瞬間だけ

見分けは左側の名前に _dnsauth が付いてるかどうか。_ 始まりは「正規のホスト名には存在しない＝機械用メタレコード」の目印で、DKIM の _domainkey、ACME の _acme-challenge と同じ作法。

同じ CNAME という箱を、通信用 (www・ブラウザが常時読む) と審査用 (_dnsauth・CA が発行の瞬間だけ読む) で 2 回使ってるだけ。今回廃止された『CNAME 委任』は後者 (審査用) の話で、通信用の CNAME は無関係でそのまま。

そのうえで「DCV の CNAME」が 2 つある ── 直接 と 委任

切り分けた審査用 (DCV) の CNAME、これがさらに 2 つのやり方に分かれる。

呼び名何をするか状態
① 直接 CNAME 方式_dnsauth.example.com を CA の検証ホストへ直接向ける現役(静的 _dnsauth 形に再編)
② CNAME 委任 (Delegation)検証用サブドメインを丸ごと別ゾーンへ委任し、中の値は委任先 (Azure / CA) が回す2025-08-15 廃止(下記の通り Azure が使ってた変種)
③ DNS TXT 方式検証値そのものを自分のゾーンに置く現役

何が問題なのか ── なぜ②委任だけ切られた？ (MPIC)

理由は MPIC (Multi-Perspective Issuance Corroboration)。一言でいうと「CA がドメイン確認を 1 か所からでなく、複数の地点 (複数のネットワーク経路) から同時に引いて、答えが一致して初めて発行する」ルール。

  • ①直接 / ③TXT：検証値は「あなたのゾーン」か「CA のホスト」に直に置かれ、経路が 1 段。多地点から引いても答えがブレにくい。
  • ②委任：検証の解決が外部ゾーンへ一段“飛ぶ”。この一段飛びが、多地点検証で安定して一致させにくい。だから Azure はマネージド証明書でこの委任ワークフローを畳んだ。

なぜ多地点で引く必要が出てきたか ── $20 で TLS が壊れた日

MPIC が要るようになった背景に、2024 年の 2 つの事件がある。

もう 1 つが、その少し前の DigiCert 約 8 万 3 千枚失効事件 (2024-07)。CNAME 検証ではランダム値の前にアンダースコア _ を付ける決まりがあるのに、DigiCert は一部で付け忘れていた。ルール違反の証明書は「24 時間以内に失効」が掟なので、使ってた企業は突然 TLS が切れた。

この 2 発が「1 経路・1 ソースを信じると死ぬ」を業界に刻み、WHOIS-DCV の廃止と MPIC への移行、そしてそれに乗らない②委任の廃止につながった。一本の因果や。

図で見る

3 方式の違いは『検証値を誰が持ち、更新時に誰が差し替えるか』。あなたの DNS を触らずに済むほど楽 (②委任が最強) だが、経路が外部ゾーンへ一段飛ぶほど MPIC に乗らない。消えたのは CNAME 検証そのものやなく、楽さの代償で経路が飛ぶ②委任だけ。

混乱しやすいポイント

① DCV ≠ 証明書

DCV は「発行前のゲート」。証明書の中身・強度とは別レイヤー。「検証が廃止」=「証明書が使えない」ではない。

② ACME (Let’s Encrypt) の委任は別物 ── 今回畳まれたのは Azure 側だけ

「委任」という技自体は ACME の世界にもある。Let’s Encrypt の _acme-challenge は TXT が基本 (DNS-01) で、それを別ゾーン (acme-dns など) へ CNAME で委任するテクが広く使われてて、これは今も現役。今回畳まれたのは、あくまで Azure がマネージド証明書で使ってた DigiCert 経由の CNAME 委任ワークフローであって、ACME 側の委任が一緒に死ぬわけやない。「委任」と聞いて全部を一括りにせんこと。共通してるのは背景の駆動力 (MPIC / OSS DCV への移行) であって、廃止の対象そのものではない。

③ 全部の背景に「証明書の短命化」がある

時期証明書の最大有効期限
〜2026-03-14398 日
2026-03-15 〜（今ここ）200 日
2027-03-15 〜100 日
2029-03-15 〜47 日

更新が年 1 回から実質 1 か月ごとへ。だから「人が DNS を触る更新」は破綻し、自動化が必須に。皮肉なことに、その自動化を一番楽にしてた②委任がセキュリティ理由で切られた ── ので、①直接 CNAME か ③TXT の自動化へ寄せる必要がある。

たとえ話 ── 全部「ビザ発行」の世界で揃える

  • DCV = ビザ申請の本人確認、証明書 = ビザ (査証)、CA = 発給する大使館。確認 (DCV) のやり方が変わっても、ビザ (証明書) という制度が無くなるわけやない。
  • ①直接 CNAME = 大使館の窓口に直接書類を出す。③TXT = 自分のパスポートに証明印を貼っておく。②委任 = ビザ申請を代行業者にまるごと丸投げ (一番楽。更新の書類差し替えも代行がやる)。
  • 証明書の短命化 = ビザの有効期限が短くなって何度も更新が要る。だから「毎回自分で書類を出し直す」が破綻し、代行 (委任) の楽さが効いていた ── が、まさにそこが切られた。
  • MPIC = 1 か所の言い分を信じず、複数の機関に照会して裏取りする。直接やパスポート提示なら答えがブレないが、代行への丸投げ (委任) は照会先が一段ズレて裏取りが通らない → だから②が使えなくなった。
  • .mobi $20 事件 = 閉鎖されたはずの旧・領事館に、まだ皆が書類を送り続けていた。そこを安く乗っ取れば、誰の本人確認も偽造して他人名義のビザを発給できた。

出てきた言葉の変換表

出てきた言葉つまり何の話？
DCVDomain Control Validation。証明書を出す前の「ドメインの持ち主か」確認。証明書そのものではない
直接 CNAME 方式_dnsauth を CA の検証ホストへ向ける。経路が 1 段でシンプル。現役
CNAME 委任 (delegation)検証用サブドメインを別ゾーンへ丸投げ。完全ハンズオフだが経路が一段飛ぶ。2025-08-15 廃止
DNS TXT 方式検証値そのものを自分のゾーンに置く。値は毎回変わり再利用不可。現役
_dnsauthDCV 用のレコード名。CNAME でも TXT でもこの名前。TXT では「名前は同じ・値は差し替え」
MPIC複数地点から DNS を引いて突き合わせる発行ルール。BGP ハイジャック等への対策
WHOIS-DCVWHOIS の管理者メールで確認する旧方式。.mobi 事件で信頼が崩れ 2025-05-08 廃止
BYOCBring Your Own Certificate。マネージドに頼らず自前証明書を持ち込む。委任廃止後のワイルドカードの逃げ道
24 時間失効ルール違反の証明書は 24 時間以内に失効、が CA/Browser Forum の掟。8 万枚失効の過激さの正体
深掘りメニュー 次におすすめのトピック

今回で「CNAME 廃止の正体 (＝委任だけ)」と「Front Door への落ち方」までは底が見えた。残ったモヤは、未来の自分が次に潰すといい順に並べるとこう。

  • MPIC と BGP ハイジャック ── 「なぜ多地点で引くと安全なのか」を、経路広告・anycast の側から見る。ここはネットワーク屋の本領で、DCV の話が一気に自分の土俵に化ける。次はこれが効くと思う。
  • ACME の _acme-challenge (DNS-01) と CNAME 委任 ── Let’s Encrypt 系での委任の使われ方を 1 回手で組むと、「委任とは何を外注してたのか」が体でわかる。DigiCert 系との違いも固まる。
  • 24 時間失効ルール / CA / Browser Forum Baseline Requirements ── なぜそんなに過激なのか。8 万枚失効の「猶予なし」を支えるルール体系を読むと、証明書運用の前提が変わる。
  • BYOC vs マネージド証明書の運用判断 ── 委任廃止と短命化を踏まえて、Front Door で「いつ自前持ち込みにすべきか」を自分の基準として言語化する。