• HOME
  • DoQ（DNS over QUIC）の導入手順：自前リゾルバを UDP 853 番で提供するまで

2026年6月17日

  • シェア
  • ツイート

    • 2026年6月17日

    DoQ（DNS over QUIC）の導入手順：自前リゾルバを UDP 853 番で提供するまで

    DoQ（DNS over QUIC）を導入する流れは、「対応するサーバーソフトを選ぶ → ホスト名と TLS 証明書を用意する → UDP 853 番を開ける → 利用できる相手を絞る → 対応クライアントで確認する」の5段階です。DoQ は暗号化 DNS の中では新しい方式で、対応するクライアントがまだ限られるため、DoH や DoT と並べて提供するのが現実的です。この記事では、Linux サーバーに自前の DoQ リゾルバを立てる手順を、AdGuard の dnsproxy を例に説明します。

    DoQ とは何か、DoH・DoT とどう違うか

    DoQ は RFC 9250 で標準化された、DNS を QUIC の上で運ぶ方式です。主な違いは次のとおりです。

    • DoT（DNS over TLS）: TCP 853 番。TCP と TLS の上で DNS を運ぶため、1つの応答が遅れると後ろの応答も待たされることがあります。
    • DoH（DNS over HTTPS）: 通常は TCP 443 番。Web の通信と見分けにくく、ブラウザの対応が進んでいます。HTTP/3 で運ぶ DoH3 もありますが、DoQ とは別の方式です。
    • DoQ: UDP 853 番。QUIC は接続の確立が速く、複数の問い合わせを独立した流れ（ストリーム）で運べるため、1つの遅れが他に影響しにくい設計です。

    一方で、UDP 853 番は企業や公衆 Wi-Fi のファイアウォールで閉じられていることが多く、OS の標準機能として DoQ を設定できる環境もまだ限られます。DoQ に対応しているのは、AdGuard の各種アプリや一部の DNS ツールなどが中心です（2026年10月現在）。この点を理解したうえで、「自分や組織の端末向けに、より速い暗号化 DNS の選択肢を用意する」位置づけで導入するのが無理のない進め方です。

    サーバーソフトを選ぶ

    DoQ に対応しているサーバーソフトには、次のようなものがあります。対応状況や必要なビルドオプションは版によって変わるため、導入前に各プロジェクトのドキュメントを確認してください。

    • AdGuard dnsproxy: 単体で動く軽量なプロキシ。DoQ・DoH・DoT の受け口を持ち、上流のリゾルバへ転送します。
    • AdGuard Home: 管理画面付きの DNS サーバー。暗号化の設定画面で DoQ のポートを指定できます。
    • dnsdist（PowerDNS）: 比較的新しい版で DoQ の受け口に対応しています。
    • Unbound、CoreDNS、Technitium DNS Server: 版やビルドによって DoQ に対応しています。

    この記事では、設定が少なく挙動が分かりやすい dnsproxy を使います。dnsproxy 自体は DNSSEC を検証しないため、上流には DNSSEC を検証するリゾルバ（自前の Unbound や、検証する公開リゾルバ）を指定します。

    手順1：ホスト名と証明書を用意する

    DoQ は TLS 1.3 を使うため、クライアントから見たホスト名（例: dns.example.com）に対する証明書が必要です。まず DNS に A（必要なら AAAA）レコードを登録し、Let's Encrypt などで証明書を取得します。

    # 例: 80番が空いているサーバーで certbot のスタンドアロン方式を使う
sudo certbot certonly --standalone -d dns.example.com

    80 番を Web サーバーが使っている場合は webroot 方式、外部から 80 番に届かない場合は DNS-01 方式を使います。証明書は90日程度で更新されるため、更新後に dnsproxy を再起動する仕組み（certbot の deploy フックなど）を最初から組み込んでおくと、期限切れでの停止を防げます。

    手順2：dnsproxy を設置して起動を試す

    dnsproxy は GitHub のリリースページで各 OS 向けのバイナリが配布されています。公式のリリースからダウンロードし、配布されているチェックサムで改ざんがないことを確かめてから設置してください。まずは手動で起動して動作を確認します。

    sudo /usr/local/bin/dnsproxy \
  -l 0.0.0.0 \
  --quic-port=853 \
  --tls-crt=/etc/letsencrypt/live/dns.example.com/fullchain.pem \
  --tls-key=/etc/letsencrypt/live/dns.example.com/privkey.pem \
  -u 127.0.0.1:5335 \
  -p 0

    ここでは、同じサーバーの 5335 番で DNSSEC を検証する Unbound が動いている前提で、そこを上流にしています。-p 0 は平文の 53 番での待ち受けを無効にする指定です。オプション名は版によって変わることがあるため、dnsproxy --help の出力で確認してから使ってください。

    手順3：常駐させる

    動作を確認できたら、systemd のサービスとして登録します。root 以外のユーザーで 853 番を使うために、必要な権限だけを付与します。

    # /etc/systemd/system/dnsproxy.service
[Unit]
Description=dnsproxy (DNS over QUIC)
After=network-online.target
Wants=network-online.target

[Service]
User=dnsproxy
AmbientCapabilities=CAP_NET_BIND_SERVICE
ExecStart=/usr/local/bin/dnsproxy -l 0.0.0.0 --quic-port=853 --tls-crt=/etc/dnsproxy/fullchain.pem --tls-key=/etc/dnsproxy/privkey.pem -u 127.0.0.1:5335 -p 0
Restart=on-failure

[Install]
WantedBy=multi-user.target
    sudo useradd --system --no-create-home dnsproxy
sudo systemctl daemon-reload
sudo systemctl enable --now dnsproxy

    証明書は certbot の deploy フックで /etc/dnsproxy/ にコピーし、dnsproxy ユーザーが読める権限にしてから systemctl restart dnsproxy を実行する形にすると、Let's Encrypt のディレクトリの権限を広げずに済みます。

    手順4：UDP 853 番を開け、利用者を絞る

    ファイアウォールで UDP 853 番を許可します。DoQ は UDP なので、TCP 853 番（DoT）だけを開けても届きません。クラウドの場合は、OS のファイアウォールとセキュリティグループなどの両方を確認します。

    # ufw の例: 特定のネットワークからだけ許可する
sudo ufw allow from 192.0.2.0/24 to any port 853 proto udp

    誰でも使えるリゾルバとして公開すると、想定外の負荷や悪用の踏み台になるおそれがあります。ファイアウォールで送信元を絞るか、AdGuard Home などのアクセス制御機能を使い、利用者を限定してください。上流の Unbound 側でも、access-control でローカルからの問い合わせだけを受け付けるようにしておきます。

    手順5：クライアントで確認する

    確認には、DoQ に対応したコマンドラインツールを使います。

    # AdGuard の dnslookup
dnslookup example.com quic://dns.example.com

# Knot DNS の kdig（DoQ 対応版）
kdig @dns.example.com +quic example.com A

    応答が返れば DoQ での接続は成功です。上流で DNSSEC が検証されているかは、署名されたドメインを問い合わせたときの AD フラグや、わざと署名を壊したテスト用ドメインで SERVFAIL になるかで確かめます。

    つながらない場合は、次の順に確認すると原因を絞り込みやすくなります。

    1. ss -ulpn | grep 853 で dnsproxy が UDP 853 番で待ち受けているか
    2. ファイアウォールやセキュリティグループで UDP 853 番が許可されているか
    3. クライアントが指定したホスト名と証明書の名前が一致しているか、証明書の期限が切れていないか
    4. journalctl -u dnsproxy に TLS や上流への接続のエラーが出ていないか

    運用の注意点

    • クライアント側の対応が限られるため、DoH や DoT の受け口も並べて用意すると、UDP 853 番が通らないネットワークでも暗号化 DNS を使えます。dnsproxy は同じプロセスで複数の方式を待ち受けられます。
    • 証明書の更新とプロセスの再起動が連動しているかを、certbot renew --dry-run で定期的に確かめます。
    • dnsproxy や上流のリゾルバは更新を追い、脆弱性の修正を取り込みます。本番に入れる前に検証用のサーバーで動作を確認してください。

    まとめ

    • DoQ は RFC 9250 で定められた UDP 853 番の暗号化 DNS で、接続確立の速さと遅延への強さが特長
    • クライアントの対応はまだ限られるため、DoH・DoT と並べて提供する
    • 導入はサーバーソフトの選定、証明書の用意、UDP 853 番の開放、利用者の制限、対応ツールでの確認の順に進める
    • dnsproxy は DNSSEC を検証しないので、上流に検証するリゾルバを置く
    • 証明書の更新と再起動の連動、アクセス範囲の制限を最初から設計に入れる
    Views: 63

    お気軽にご相談ください

    お見積りへ お問い合わせへ
    閉じる
    ▲