2026年6月16日

DANE と DoQ (DNS over QUIC) を併用する設定｜送信メールサーバーの上流を DoQ にするときの転送役・UDP 853番・フォールバックの決め方

DNS・名前解決

DANE と DoQ を併用するときも、DNSSEC の検証は自分のホストのリゾルバーで行い、DoQ は上流への通信路の暗号化にだけ使う、という分担が基本です。Postfix と同じホストに検証役の Unbound を置き、その上流に DoQ の転送役として AdGuard の dnsproxy をつなぐと、TLSA の検証結果を Postfix に渡しながら、上流への問い合わせを QUIC で暗号化できます。この記事では、その構成の設定と、DoQ ならではの注意点（UDP 853番の通り道、フィルタありの上流、止まったときの切り替え先）を順に説明します。

上流を DoT や DoH にする構成は同じサイトの別記事で扱っています。ここでは DoQ を選ぶ場合に固有の判断に絞ります。

DoQ を選ぶ理由と、選ばない理由

DoQ（RFC 9250）は DNS のメッセージを QUIC で運ぶ仕組みで、UDP の853番を使います。TLS 1.3 を前提にした暗号化に加え、接続の確立が速く、1本の接続の中で複数の問い合わせが互いの遅れに引きずられにくい点が特徴です。

一方で、送信メールサーバーの上流として使うには、次の点を先に確かめる必要があります。

UDP 853番の外向き通信が通るか：クラウドのセキュリティグループや社内のファイアウォールで、外向きの UDP が53番以外は閉じられていることがあります。
上流の選択肢：DoT や DoH に比べると、DoQ を提供している公開リゾルバーは限られます。提供の有無や接続先の名前は、利用する事業者の案内で確認してください（2026年10月現在）。
転送役の対応：Unbound は上流への DoQ 転送に対応していないため、別のソフトウェアを間に置く必要があります。

これらを満たせない環境では、上流を DoT にするほうが運用は楽です。DoQ は「経路の暗号化に加え、応答の速さや接続の安定性も重視したい」場合に検討する選択肢と考えてください。

構成の全体像

Postfix ── 127.0.0.1:53 ── Unbound（DNSSEC 検証・キャッシュ）
                              └─ 127.0.0.1:5354 ── dnsproxy ── UDP 853（DoQ）── 上流のリゾルバー
                                                       └─ 失敗時: TCP 853（DoT）── 予備の上流

検証を Unbound で行うのは、上流が付けた AD ビットを信用するより、自分のホストで検証したほうが信頼の範囲がはっきりするからです。dnsproxy は問い合わせを運ぶだけで、DNSSEC の検証はさせません。

UDP 853番の通り道を先に確かめる

設定を始める前に、メールサーバーから上流の DoQ に届くかを確認します。AdGuard が公開している dnslookup というコマンドは、quic:// の形式で DoQ のサーバーに問い合わせられます。

# 接続先は利用する事業者の DoQ の名前に置き換える
dnslookup example.com quic://dns.example-resolver.net

Knot DNS の kdig も、新しめの版では +quic オプションで DoQ に対応しています。手元のパッケージの版で使えるかは kdig -h で確かめてください。

応答が返らずタイムアウトする場合は、UDP 853番が経路のどこかで止められている可能性が高いです。クラウドの外向きルール、ホストの nftables や firewalld、ネットワーク機器の順に確認します。TCP 853番（DoT）は通るのに UDP 853番だけ通らない、という環境は珍しくありません。

dnsproxy の設定

dnsproxy は単体のバイナリで動き、コマンドラインのオプションか YAML の設定ファイルで動作を指定します。導入方法やオプションの名前は版によって変わることがあるため、dnsproxy --help の表示で確認してから使ってください。以下は考え方を示す例です。

dnsproxy \
  -l 127.0.0.1 -p 5354 \
  -u quic://dns.example-resolver.net \
  -u quic://dns.example-resolver2.net \
  -f tls://dns.example-backup.net

-l と -p は待ち受けるアドレスとポートです。外から使わせる必要はないので、ループバックに限定します。
-u は上流です。DoQ の上流を2か所以上入れておくと、片方が止まっても続けられます。
-f はフォールバック先で、上流がすべて応答しないときに使われます。ここに平文の DNS ではなく DoT（tls://）を指定しておくと、DoQ が通らなくなっても暗号化は保たれます。

常駐させる場合は systemd のユニットを用意し、専用の権限の低いユーザーで動かします。ループバックの 1024 番以上のポートで待ち受けるので、特別な権限は要りません。

フィルタなしの上流を選ぶ

DoQ を提供する公開リゾルバーには、広告やトラッカーのドメインを遮断する「フィルタあり」の接続先が既定になっているものがあります。遮断されたドメインには偽の応答が返るため、署名されたドメインでこれが起きると Unbound の検証が失敗し、メールが保留されます。メールサーバーの上流には、事業者が案内しているフィルタなしの接続先を指定してください。

設定後は、dnsproxy 単体で DNSSEC の情報が通るかを確かめます。

dig +dnssec @127.0.0.1 -p 5354 example.com SOA

応答に RRSIG が含まれていれば、署名は転送の途中で落とされていません。

Unbound の設定

# /etc/unbound/unbound.conf.d/dane-doq.conf（例）
server:
    interface: 127.0.0.1
    access-control: 127.0.0.0/8 allow
    # ループバック上の dnsproxy に問い合わせるために必要
    do-not-query-localhost: no
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    edns-buffer-size: 1232

forward-zone:
    name: "."
    forward-addr: 127.0.0.1@5354
    forward-first: no

do-not-query-localhost: no が無いと、Unbound はループバックの転送先に問い合わせません。トラストアンカー（auto-trust-anchor-file）が無いと検証そのものが行われないので、配布パッケージの既定で設定済みかも確認します。forward-first: no は、転送先が止まったときに Unbound が自分で平文の再帰問い合わせを始めないための設定です。

sudo unbound-checkconf
sudo systemctl restart unbound
dig @127.0.0.1 example.com SOA +dnssec

フラグに ad があれば、Unbound が検証に成功しています。

Postfix 側の設定と、AD ビットの受け渡し

# /etc/postfix/main.cf（抜粋）
smtp_dns_support_level = dnssec
smtp_tls_security_level = dane

Postfix が検証結果を受け取るには、/etc/resolv.conf が 127.0.0.1 を向き、glibc 2.31 以降では options trust-ad が入っている必要があります。Debian 系で smtp プロセスが chroot で動いている場合は、/var/spool/postfix/etc/resolv.conf も同じ内容になっているかを確かめてください。

フォールバックの方針を決める

DoQ の上流を使う構成で最も迷うのが、「通らなくなったときにどうするか」です。選択肢は次の3つです。

DoT に切り替える（上の例の -f tls://）：暗号化は保ったまま、UDP 853番の障害を回避できます。多くの環境ではこれが無難です。
名前解決を失敗させる：フォールバックを設定せず、Unbound も forward-first: no にします。メールは保留されますが、平文の問い合わせは出ません。
平文の再帰問い合わせに切り替える（Unbound の forward-first: yes）：配送は続きますが、障害中は送信先ドメインの問い合わせが平文で出ていきます。

DANE の安全性そのものは、どの選択肢でも DNSSEC の検証が行われていれば保たれます。違いは「障害時に問い合わせの中身を経路に見せてよいか」です。運用方針として決め、設定と手順書に残しておきます。

動作の確認

TLSA の取得と検証を Unbound 経由で確かめます。

dig +dnssec @127.0.0.1 _25._tcp.mx.example.net TLSA
posttls-finger -c -l dane example.net

TLSA が ad 付きで返り、posttls-finger で Verified の表示になれば、DANE の照合まで動いています。続けて、上流への通信が DoQ で出ているかを確認します。

sudo tcpdump -ni eth0 'udp port 853 or port 53'

外向きに UDP 853番の通信があり、53番の通信が無ければ想定どおりです。UDP 853番を一時的に遮断して、フォールバック先の TCP 853番に切り替わるかも、ステージング環境で試しておくと安心です。

まとめ

DoQ は上流への通信路の暗号化に使い、DNSSEC の検証は自分のホストの Unbound で行う。
Unbound は上流への DoQ 転送に対応していないため、dnsproxy などの転送役を置く。転送先がループバックなら do-not-query-localhost: no が必要。
設定前に UDP 853番の外向き通信が通るかを確かめる。通らない環境では DoT のほうが運用しやすい。
上流はフィルタなしの接続先を選び、RRSIG が通ることを確かめる。
障害時に DoT へ切り替えるか、失敗させるか、平文に切り替えるかを運用方針として決めておく。