2026年6月11日

CAAレコードと DoQ (DNS over QUIC) を併用する設定｜DoQ リゾルバーの証明書を CAA で守り、CAA の確認にも DoQ を使う

DNS・名前解決

CAA レコードと DoQ（DNS over QUIC）は、別々の層で働く仕組みです。CAA は「どの認証局（CA）がこのドメインの証明書を発行してよいか」を宣言し、DoQ は DNS の問い合わせを QUIC で暗号化して運びます。両者を併用する意味がはっきりあるのは、自前で DoQ のリゾルバーを公開している場合です。DoQ のクライアントはホスト名と証明書で接続先を確かめるため、その証明書を不正に発行されにくくする CAA が、リゾルバーのなりすまし対策として効いてきます。この記事では、DoQ リゾルバーのホスト名に絞った CAA の書き方、証明書の取得方法との組み合わせ、DoQ を使った CAA の確認方法、併用しても変わらないことを順に説明します。

2つの仕組みが守るもの

最初に役割を整理しておくと、設定の目的がぶれません。

DoQ（RFC 9250）。 端末とリゾルバーの間の DNS の通信を、QUIC（UDP の 853 番）で暗号化します。クライアントは TLS の証明書で「接続先が本物のリゾルバーか」を確かめます。
CAA（RFC 8659）。 権威 DNS に置くレコードで、CA が証明書を発行する直前に参照します。許可されていない CA は発行を断ります。
DNSSEC。 DNS の応答が改ざんされていないことを署名で保証します。DoQ は通信路を暗号化するだけで、応答の正しさは保証しません。

DoQ のクライアントが信頼するのは「ホスト名に合った、信頼された CA の証明書」です。もし第三者がそのホスト名の証明書を手に入れれば、経路を乗っ取ったうえで偽のリゾルバーを名乗れます。CAA で発行できる CA と ACME アカウントを絞っておくと、こうした不正発行の余地を小さくできます。

一方で、端末が DoQ を使っていても、CA が CAA を確認する経路は変わりません。CA は自前のリゾルバーで CAA を引きます。自分の端末の DNS を DoQ にしたからといって、証明書の発行が安全になったり、逆に止まったりすることはありません。

構成の例

ここでは次の構成を例にします。

メインのサイト：example.com、www.example.com（Web サーバーで証明書を取得）
DoQ リゾルバー：dns.example.com（dnsdist で UDP 853 番を待ち受け）
証明書は Let's Encrypt から取得

dnsdist で DoQ を待ち受ける設定は、証明書と秘密鍵のパスを渡す形になります。

-- /etc/dnsdist/dnsdist.conf（抜粋・例）
newServer({address="127.0.0.1:5300"})
addDOQLocal("0.0.0.0:853", "/etc/dnsdist/tls/fullchain.pem", "/etc/dnsdist/tls/privkey.pem")

dnsdist の DoQ 対応は比較的新しく、配布パッケージによっては DoQ を有効にしたビルドになっていないことがあります。dnsdist --version の機能一覧で対応を確かめてください（2026年10月現在）。

証明書の取得方法を先に決める

CAA で検証方法まで絞る場合は、dns.example.com の証明書をどの方法で取るかを先に決めます。DoQ のサーバーは UDP の 853 番しか使わないことが多く、HTTP の 80 番で検証する HTTP-01 を使うには、別途 80 番を開ける必要があります。リゾルバーのサーバーに Web サーバーを置きたくない場合は、DNS に TXT レコードを書いて検証する DNS-01 が向いています。DNS-01 を使うと、外部に開けるポートを UDP 853 番だけに保てます。

DoQ のホスト名に CAA を書く

CA は、証明書の名前そのものから親のドメインへ順にさかのぼり、最初に見つかった CAA を使います。dns.example.com に CAA を置けば、その名前にはそれが適用され、example.com の CAA は参照されません。これを利用すると、メインのサイトとは別の、より厳しい条件をリゾルバーにだけ付けられます。

; メインのサイト（Web サーバーの証明書）
example.com.     3600 IN CAA 0 issue "letsencrypt.org"
example.com.     3600 IN CAA 0 iodef "mailto:security@example.com"

; DoQ リゾルバー専用（ACME アカウントと検証方法まで絞る）
dns.example.com. 3600 IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456789; validationmethods=dns-01"
dns.example.com. 3600 IN CAA 0 issuewild ";"
dns.example.com. 3600 IN CAA 0 iodef "mailto:security@example.com"

accounturi（RFC 8657）は、発行を許可する ACME アカウントの URL です。数字はダミーなので、certbot なら certbot show_account などで実際の URL を確認して貼り付けます。
validationmethods=dns-01 は、DNS-01 以外の検証方法での発行を断るよう CA に求める指定です。
issuewild ";" は、この名前でのワイルドカード証明書をどの CA にも許可しない指定です。
iodef は、ポリシーに反する発行依頼があったときの連絡先です。CA が通知を送るかどうかは CA の判断に任されているため、これだけに頼らず、後述の CT ログの監視と組み合わせます。

dns.example.com を CNAME で別の名前に向けている場合、CAA の参照は CNAME の先に進みます。リゾルバーのホスト名は A/AAAA レコードで直接向けておくと、CAA の適用範囲が分かりやすくなります。

accounturi を書くと、ACME アカウントを作り直したときに新しい URL を先に追加しないと発行が止まります。サーバーの移行や証明書ツールの入れ替えの予定がある場合は、その手順に CAA の更新を組み込んでおきます。

ゾーンを DNSSEC で署名する

CAA は DNS のレコードなので、CA が引く途中で応答を偽装されれば効き目がありません。ゾーンを DNSSEC で署名していると、CA は署名を検証したうえで CAA を判断します。DoQ リゾルバー自身が DNSSEC の検証を行っていれば、利用者に返す応答の正しさも担保できます。CAA と DoQ を組み合わせるなら、DNSSEC まで揃えておくと「発行の制限」「通信路の暗号化」「応答の真正性」の3つがそろいます。

DoQ を使って CAA を確かめる

管理用の端末から、自分の DoQ リゾルバー経由で CAA を引いて、意図した内容が返るかを確かめます。Knot DNS 3.3 以降の kdig は +quic で DoQ の問い合わせができます。

# 自前の DoQ リゾルバー経由で CAA を引く（証明書もホスト名で検証する）
kdig @dns.example.com +quic +tls-ca +tls-hostname=dns.example.com dns.example.com CAA

# 権威 DNS サーバーに直接聞いた結果と比べる
dig +short example.com NS
dig +norec @ns1.example-dns.net dns.example.com CAA

DoQ では1つの問い合わせを1本の QUIC ストリームでやり取りするため、従来の UDP のように応答が大きくて切り詰められ、TCP で取り直す、という動きは起きません。CAA の行を多く並べたり、DNSSEC の署名が付いて応答が大きくなったりしても、DoQ の経路ではそのまま受け取れます。

2つの結果が食い違う場合は、リゾルバー側のキャッシュが古い可能性があります。CAA を変更した直後は TTL が切れるまで古い内容が返ることがあり、これは CA 側でも同じです。CA は CAA の確認結果を一定時間（業界の基準では最長8時間）使い回すことも認められているため、変更から発行までは余裕を持たせます。

kdig が手元にない場合は、q や dnslookup など DoQ に対応したコマンドラインのツールもあります。オプションの書き方はツールごとに異なるため、各ツールの説明を確認してください。

発行の監視を続ける

CAA は発行を断るための仕組みで、発行されてしまった証明書を見つける仕組みではありません。dns.example.com の証明書は Certificate Transparency のログに記録されるため、crt.sh などの検索サービスや CT ログの監視サービスで定期的に確かめ、心当たりのない発行がないかを見ます。

あわせて、DoQ リゾルバーの証明書の期限切れも監視します。証明書が切れると、DoQ のクライアントはリゾルバーにつながらなくなります。Web サイトと違ってブラウザの警告で気付くことがないため、外部からの監視を入れておくと安心です。

# DoT（TCP 853）を同じ証明書で提供している場合は、そちらから期限を確かめられる
openssl s_client -connect dns.example.com:853 -servername dns.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -enddate

併用しても変わらないこと

CAA は証明書の発行時にだけ参照されます。CAA を厳しくしても、すでに発行済みの証明書は失効しません。
CAA は、クライアントが証明書をどう検証するかには関わりません。公開鍵のピン留めを使っているクライアントがあるなら、その運用は CAA とは別に続けます。
DoQ を使っても、CA による CAA の確認経路は変わりません。

まとめ

CAA と DoQ を併用する意味が大きいのは、自前で DoQ リゾルバーを公開している場合です。リゾルバーの証明書の不正発行を CAA で防ぎます。
リゾルバーのホスト名に専用の CAA を置くと、メインのサイトとは別に、ACME アカウントや検証方法まで絞れます。DoQ だけを開けるなら DNS-01 での取得が向いています。
ゾーンを DNSSEC で署名すると、CA が引く CAA の真正性も守れます。
確認は kdig +quic で DoQ 経由の結果と権威 DNS の結果を比べ、CT ログと証明書の期限も継続して監視します。