2026年6月8日

CAAレコードと DoT (DNS over TLS) を併用する設定｜サーバーの名前解決を暗号化したうえで CAA を確かめ、監視する

DNS・名前解決

CAA レコードと DoT は守る場所が違うため、併用しても互いの設定を変える必要はありません。CAA は認証局が証明書を発行する前に参照する「発行してよい認証局の一覧」で、DoT は自分の端末やサーバーとリゾルバーの間の通信を暗号化する仕組みです。この記事では、両者の関係を整理したうえで、サーバーの名前解決を DoT にする設定と、DoT 経由で CAA を確かめる方法、CAA が書き換わっていないかを監視するスクリプトの例を説明します。

2つの仕組みの役割を分けて考える

最初に、よくある誤解を整理しておきます。

自分のサーバーで DoT を有効にしても、認証局が CAA を調べる経路は変わりません。 認証局は自社のリゾルバーから権威 DNS サーバーへ問い合わせます。あなたのサーバーのリゾルバー設定は関係しません。
DoT は CAA の中身を守りません。 DoT が守るのは、問い合わせる側とリゾルバーの間の通信だけです。権威サーバーの応答が正しいかどうかは、DNSSEC の署名で確かめる仕組みです。CA/ブラウザフォーラムの規定でも、CAA の確認と DNSSEC の検証を結びつける方向の改訂が進んでいます（適用時期や細部は Baseline Requirements の最新版で確認してください）。
CAA の書式や値は、DoT の有無で変わりません。 issue、issuewild、iodef の書き方はこれまでどおりです。

では、併用して何が良くなるのでしょうか。主に次の2点です。

証明書の更新前後に自分のサーバーから CAA を確かめるとき、ネットワークの途中で応答を覗かれたり、すり替えられたりする余地を減らせます。社内ネットワークの DNS が独自の応答を返す環境（スプリットホライズン）で、外から見える値を確かめたいときにも役立ちます。
監視スクリプトが公開リゾルバーへ DoT で問い合わせることで、経路上の機器の影響を受けにくい形で CAA の変化を追えます。

サーバーの名前解決を DoT にする（systemd-resolved の例）

systemd-resolved が動いている Linux なら、設定ファイルを1つ変えるだけで上流への問い合わせを DoT にできます。

# /etc/systemd/resolved.conf（例）
[Resolve]
DNS=9.9.9.9#dns.quad9.net 1.1.1.1#cloudflare-dns.com
DNSOverTLS=opportunistic

# のあとは、リゾルバーの証明書を確かめるためのホスト名です。DNSOverTLS には yes（DoT が使えなければ名前解決を失敗させる）と opportunistic（使えなければ平文に戻る）があります。853 番ポートが経路のどこかで塞がれていると、yes では名前解決が止まり、WordPress の更新確認やメール送信まで影響が出ます。最初は opportunistic で動作を確かめ、問題がないと分かってから yes に切り替える進め方が安全です。

sudo cp /etc/systemd/resolved.conf /etc/systemd/resolved.conf.bak
sudo systemctl restart systemd-resolved
resolvectl status

resolvectl status の出力で、DoT の項目に +DNSOverTLS のような表示が出ていれば有効になっています。表示の細部は systemd の版で異なります（2026年10月現在）。作業はコンソール接続など、名前解決が止まっても入れる経路を確保してから行ってください。

DoT 経由で CAA を確かめる

サーバー全体の設定を変えずに、CAA の確認だけを DoT で行うこともできます。Knot DNS に付属する kdig が扱いやすいです。

# Quad9 に DoT で CAA を問い合わせ、証明書のホスト名も検証する
kdig @9.9.9.9 +tls-ca +tls-hostname=dns.quad9.net example.com CAA

# BIND 9.18 以降の dig でも DoT で問い合わせられる（証明書検証の指定は版により異なる）
dig +tls @9.9.9.9 example.com CAA

+tls-ca を付けると、OS の信頼済み証明書でリゾルバーの証明書を検証します。付けないと暗号化はされても相手の確認は行われないため、確認用途では付けておくのがよいでしょう。

結果は、権威サーバーへ直接聞いた値と比べます。

# 権威サーバーの名前を調べてから、直接問い合わせる
dig example.com NS +short
dig @ns1.example-dns.net example.com CAA +norecurse

両者が違う場合、まず TTL によるキャッシュの残りを疑います。CAA を変更した直後なら、古い値が TTL の時間だけ残ります。TTL を過ぎても違うなら、ネームサーバーごとに設定が食い違っていないか、DNS サービスの管理画面で変更が保存されているかを確かめます。社内のリゾルバーだけ値が違う場合は、スプリットホライズンや社内 DNS の上書き設定が原因であることが多いです。

サブドメインは親をたどる

認証局は、証明書のホスト名に CAA が無ければ、親のドメインへ順にさかのぼって最初に見つかった CAA を使います。www.example.com の証明書で問題が出たときは、www.example.com だけでなく example.com まで確かめます。CNAME がある名前では、CNAME の先の CAA が参照される場合もあります。

CAA の変化を DoT で監視する

CAA が意図せず書き換わると、次の証明書更新で発行が止まり、更新期限が近づいて初めて気づくことになりがちです。期待する値を決めておき、DoT で定期的に比べるスクリプトの例です。

#!/bin/bash
# caa-watch.sh: CAA が期待値と違えば終了コード1で知らせる（例）
set -u
NAME="example.com"
RESOLVER="9.9.9.9"
TLSHOST="dns.quad9.net"
EXPECTED='0 issue "letsencrypt.org"'

ACTUAL=$(kdig @"$RESOLVER" +tls-ca +tls-hostname="$TLSHOST" +short "$NAME" CAA | sort)
if [ -z "$ACTUAL" ]; then
  echo "CAA の取得に失敗、または CAA が空: $NAME" >&2
  exit 1
fi
if ! printf '%s\n' "$ACTUAL" | grep -qxF "$EXPECTED"; then
  echo "CAA が想定と違います: $NAME" >&2
  printf '%s\n' "$ACTUAL" >&2
  exit 1
fi
echo "OK: $NAME"

cron や systemd タイマーで1日に数回動かし、終了コードが1のときにメールやチャットへ通知する形にすると扱いやすいです。期待値は、許可している認証局の行に合わせて書き換えてください。issuewild や accounturi を使っている場合は、その行も期待値に含めます。

DoT のリゾルバーが一時的に応答しないと、取得失敗として通知が出ます。誤報を減らしたい場合は、2つの公開リゾルバーに問い合わせて両方が失敗したときだけ知らせる、といった工夫が考えられます。

自分で DoT サーバーを運用している場合

社内向けや Android の「プライベート DNS」向けに、自分のホスト名で DoT サーバーを立てている場合は、そのホスト名の証明書も CAA の対象になります。たとえば dns.example.com の証明書を Let's Encrypt で取っているなら、example.com の CAA に Let's Encrypt が許可されている必要があります。DoT サーバーの証明書を更新するときも、ウェブサイトの証明書と同じように CAA の確認を手順に入れておきます。

つまずきやすい点

853 番の遮断：ホスティング事業者やネットワーク機器によっては、外向きの 853 番が通らないことがあります。opportunistic では気づきにくいため、kdig で DoT の応答が返るかを一度確かめておきます。
時刻のずれ：DoT は TLS を使うため、サーバーの時刻が大きくずれていると証明書の検証に失敗します。NTP が動いているかを確かめます。
CAA の確認結果と発行の可否は別：手元で CAA が正しく見えても、認証局側の判断は認証局のリゾルバーと規定に従います。最終的な確認は、ステージング環境での発行テストや実際の更新で行います。

まとめ

CAA は認証局が参照する発行の許可、DoT はリゾルバーとの通信の暗号化で、守る場所が違います。DoT を有効にしても CAA の設定を変える必要はありません。
認証局が CAA を調べる経路は DoT の影響を受けません。CAA の中身の正しさを担保するのは DNSSEC です。
systemd-resolved の DNSOverTLS は opportunistic から試し、853 番が通ると分かってから yes にします。
kdig +tls-ca で CAA を DoT 経由で確かめ、権威サーバーの値と比べます。期待値と比べるスクリプトで定期的に監視すると、更新の失敗を前もって防げます。