DoQ（DNS over QUIC）を導入すると、端末とリゾルバの間の DNS 通信を暗号化し、経路上での盗み見や書き換えを防げます。ただし、DoQ は応答の中身が正しいかどうかまでは保証しないため、DNSSEC の検証と組み合わせ、待ち受けを必要な相手だけに絞ることが、セキュリティを強化するうえでの要点です。この記事では、自前のリゾルバの前に DoQ の入口を置く構成を例に、守れる範囲の整理、設定、アクセス制限、確認方法までを説明します。
DoQ の証明書や鍵を後から入れ替える手順は、導入とは別の作業になるため、この記事では扱いません。
DoQ で守れるもの・守れないもの
DoQ は RFC 9250 で標準化された方式で、QUIC（UDP の 853 番）の上で DNS をやり取りします。QUIC は TLS 1.3 を組み込んでいるため、次のことが期待できます。
- 端末からリゾルバまでの経路で、問い合わせ内容を第三者に読まれにくくなる
- 経路上で応答を書き換えられた場合に、通信の段階で検知できる
- 接続先のリゾルバが本物かどうかを、証明書で確かめられる
一方で、次のことは DoQ だけでは守れません。
- リゾルバ自身がどの問い合わせを受けたかは、リゾルバの運用者に見える
- リゾルバから権威サーバーへの問い合わせは、多くの場合いまも暗号化されていない
- 権威サーバーの応答が改ざんされていないことの保証は、DNSSEC の役割
つまり DoQ は「通り道の保護」です。データそのものの正しさは、リゾルバで DNSSEC を検証して補います。DoT や DoH も守る範囲はほぼ同じで、DoQ は QUIC による接続の速さや、1つの応答の遅れが他の応答を待たせにくい点が違いです。
クライアントの対応状況にも注意が要ります。OS の標準機能で暗号化 DNS を設定する場合、主に DoT や DoH が選択肢になっており、DoQ を使うには対応したアプリや、ローカルで動かす中継ソフトが必要になる場面が多いのが実情です（2026年10月現在）。DoQ を入れる場合も、DoT を併せて提供しておくと、DoQ に対応していない端末の受け皿になります。
構成を決める
ここでは、すでに DNSSEC を検証する Unbound が 127.0.0.1:5353 で動いており、その前に dnsdist を置いて DoQ で受け付ける構成を例にします。dnsdist は PowerDNS が開発している DNS 用のロードバランサーで、比較的新しい版で DoQ の待ち受けに対応しています。AdGuard Home のように、リゾルバと暗号化 DNS の待ち受けを1つで提供するソフトウェアを使う方法もあります。
どの構成でも、最初に決めておくべきなのは「誰に使わせるか」です。インターネット全体に開いたリゾルバ（オープンリゾルバ）は、悪用や負荷の問題を抱えやすく、運用の負担も大きくなります。自分の端末や社内の拠点だけで使うなら、接続元の IP アドレスで絞るのが基本です。
事前に用意するもの
- リゾルバに付けるホスト名（例：dns.example.com）と、その A / AAAA レコード
- そのホスト名の証明書（公的な認証局のものを使うと、クライアント側の設定が簡単になる）
- ファイアウォールとクラウドのセキュリティグループで、UDP 853 番を許可する設定
- 設定ファイルのバックアップと、可能ならステージング環境
QUIC は UDP を使うため、TCP の 853 番（DoT）だけを開けていても DoQ はつながりません。逆に、UDP 853 番を誰にでも開けると、意図しない相手からも接続を受けることになります。ファイアウォールの段階で接続元を絞れるなら、そこで絞っておくと二重の防御になります。
dnsdist で DoQ の待ち受けを設定する
dnsdist の設定ファイル（Lua 形式）の例です。証明書のパスや接続元の範囲は環境に合わせて書き換えてください。
-- /etc/dnsdist/dnsdist.conf の例
-- 後ろにいる DNSSEC 検証リゾルバ（Unbound）
newServer({address = '127.0.0.1:5353'})
-- DoQ の待ち受け（UDP 853）
addDOQLocal('0.0.0.0:853', '/etc/dnsdist/tls/fullchain.pem', '/etc/dnsdist/tls/privkey.pem')
-- DoT も併せて提供する（DoQ 非対応の端末向け）
addTLSLocal('0.0.0.0:853', '/etc/dnsdist/tls/fullchain.pem', '/etc/dnsdist/tls/privkey.pem')
-- 使わせる相手だけを許可する（例の範囲は文書用アドレス）
setACL({'192.0.2.0/24', '2001:db8::/32', '127.0.0.0/8'})
-- 1つの接続元から毎秒 20 件を超える問い合わせは捨てる
addAction(MaxQPSIPRule(20), DropAction())dnsdist の DoQ 対応は、ビルド時に QUIC のライブラリを組み込んでいるかどうかに左右されます。OS 標準のパッケージでは無効になっていることがあるため、dnsdist --version の出力で DoQ が機能一覧に含まれているかを確かめてください。含まれていない場合は、PowerDNS が配布しているパッケージを使う方法があります。
設定を書いたら、dnsdist --check-config で構文を確認してから再起動します。秘密鍵のファイルは dnsdist の実行ユーザーだけが読めるようにし、権限は 600 程度にしておきます。
アクセス制限とレート制限を考える
setACL は、問い合わせを受け付ける接続元を指定する設定です。dnsdist は既定ではプライベートアドレスなど限られた範囲しか許可しないため、外から使わせたい範囲を明示的に書きます。範囲を広げすぎないことが、DoQ を導入するうえでの最も実用的なセキュリティ対策です。
MaxQPSIPRule は、接続元ごとの問い合わせ数の上限です。数値は利用者の数や使い方で変わるため、最初は余裕を持たせ、ログを見ながら調整します。正規の利用者の問い合わせまで捨ててしまうと、名前解決が断続的に失敗し、原因の切り分けに時間がかかります。
QUIC には、再接続時に最初の往復を省く 0-RTT という仕組みがあります。RFC 9250 では、0-RTT のデータは再送（リプレイ）されうることへの注意が書かれています。実装に 0-RTT を有効にする設定がある場合、必要性がはっきりしない限りは既定のまま（無効、または実装が制限している状態）にしておくのが無難です。
ログとプライバシーを決めておく
DoQ で通り道を暗号化しても、リゾルバのログに接続元の IP アドレスと問い合わせたドメインを長く残していれば、利用者の行動はそこから読み取れます。障害対応に必要な期間だけ残す、集計値だけを残す、といった方針を決めておきます。家族や社員など他人に使わせる場合は、何をどれだけ保存するかを利用者に説明し、必要に応じてプライバシーポリシーにも記載します。
あわせて、dnsdist や QUIC のライブラリは更新して脆弱性の修正を取り込める状態にしておきます。新しいプロトコルの実装ほど修正が入る頻度が高い傾向があります。
端末側から DoQ で使う
OS の設定で DoQ を直接指定できない端末では、ローカルで中継ソフトを動かし、OS からはそのソフトを通常の DNS サーバーとして使う方法があります。AdGuard が公開している dnsproxy の例です。
# 127.0.0.1:53 で受けて、DoQ のリゾルバへ転送する例
sudo dnsproxy -l 127.0.0.1 -p 53 -u quic://dns.example.comオプションの書き方は版によって変わることがあるため、dnsproxy --help で確認してください。DoQ がつながらないときに平文の DNS へ自動で切り替える設定を入れると、利便性は上がる一方で、暗号化されないまま問い合わせが流れる可能性があります。何を優先するかを決めてから設定します。
動作を確かめる
外部の端末から DoQ で問い合わせ、応答が返るかを確認します。
# Knot DNS 付属の kdig（+quic に対応した版）
kdig @dns.example.com +quic +tls-hostname=dns.example.com example.com A
# DNSSEC の検証結果も見る（後ろのリゾルバが検証していれば ad が付く）
kdig @dns.example.com +quic +tls-hostname=dns.example.com +dnssec isc.org A
# AdGuard の dnslookup
dnslookup example.com quic://dns.example.com:853許可していない接続元から試して、応答が返らないことも確かめておきます。さらに、端末側で sudo tcpdump -ni any udp port 53 or tcp port 53 を動かしながらブラウザを操作し、外部の DNS サーバーへ平文の問い合わせが流れていないかを見ると、設定の漏れ（別のアプリが独自の DNS を使っている、など）に気づけます。
まとめ
- DoQ は端末とリゾルバの間の通り道を守る仕組みで、データの正しさは DNSSEC の検証で補う
- UDP 853 番を開ける必要があり、接続元はファイアウォールと
setACLの両方で絞る - レート制限は余裕を持たせて始め、ログを見て調整する。0-RTT は必要がなければ有効にしない
- ログの保存方針を決め、他人に使わせるなら保存内容を説明する
- DoQ に対応しない端末のために DoT を併せて提供し、外から
kdig +quicなどで確かめる