2026年6月13日

2026年6月13日

DoQ (DNS over QUIC) が動作しない場合のトラブルシューティング|UDP 853 番・クライアント対応・証明書・ALPN を順に確かめる

DoQ(DNS over QUIC)が動かないとき、原因として多いのは「UDP の 853 番が途中で通っていない」と「使っているクライアントが実は DoQ に対応していない」の2つです。この記事では、症状をタイムアウト・接続エラー・一部だけ失敗の3つに分け、可能性の高い原因から順に、確認のコマンドと直し方を説明します。自前で DoQ リゾルバーを運用している場合と、公開リゾルバーを DoQ で使おうとしている場合の両方を対象にしています。

まず症状を分ける

DoQ(RFC 9250)は QUIC の上で DNS をやり取りし、通常は UDP の 853 番を使います。同じ 853 番でも DoT(DNS over TLS)は TCP なので、ファイアウォールの扱いが別になる点が、切り分けの出発点です。症状は次の3つに分けると原因を絞りやすくなります。

  • 応答がなくタイムアウトする。 パケットが届いていないか、サーバーが待ち受けていない状態です。
  • すぐにエラーで切れる。 証明書の検証や、QUIC・TLS のハンドシェイクで失敗しています。
  • 最初は動くが、ときどき止まる。 ネットワーク機器の UDP の扱いや、サイズの問題が疑われます。

以下のコマンド例では、リゾルバーのホスト名を dns.example.com としています。

切り分けに使う道具

DoQ はブラウザや dig では試せないため、DoQ に対応したツールを用意します。

# Knot DNS 3.3 以降の kdig(Debian・Ubuntu では knot-dnsutils パッケージ)
kdig @dns.example.com +quic +tls-ca +tls-hostname=dns.example.com example.com A

# 同じサーバーの DoT(TCP 853)と比べる
kdig @dns.example.com +tls-ca +tls-hostname=dns.example.com example.com A

# OpenSSL 3.2 以降なら、DoQ のハンドシェイクと証明書を直接見られる
openssl s_client -quic -alpn doq -connect dns.example.com:853 -servername dns.example.com </dev/null

kdig のバージョンが古いと +quic が使えません。kdig -V で確認してください(2026年10月現在)。ほかに q や dnslookup など、DoQ に対応したコマンドラインのツールもあります。

DoT では成功して DoQ だけ失敗するなら、証明書やリゾルバー本体ではなく、UDP の経路か DoQ の待ち受けに原因がある、と絞り込めます。

原因1:クライアントが DoQ を使っていない

端末で「暗号化 DNS を設定したのに DoQ が動かない」という場合、そもそも DoQ ではない方式で動いていることがよくあります。

  • Android の「プライベート DNS」は DoT の機能です。DoQ のホスト名を入れても、DoT で接続しようとします。
  • Windows の標準機能は DoH が中心で、DoQ は使えません。
  • Chrome や Firefox のセキュア DNS の設定は DoH です。

DoQ を使うには、DoQ に対応したアプリや、手元で DoQ に変換するプロキシ(AdGuard の dnsproxy など)、AdGuard Home のように上流に quic:// を指定できるリゾルバーを経由させる必要があります。対応状況はバージョンで変わるため、使っているソフトウェアの説明で確かめます。設定の確認は、アプリのログやクエリログに DoQ(quic://)の上流が記録されているかで行います。

原因2:UDP の 853 番が途中で止まっている

タイムアウトの原因として最も多いのがこれです。確認は、クライアントから問い合わせを送りながら、サーバー側でパケットが届いているかを見る方法が分かりやすいです。

# サーバー側で実行し、クライアントから kdig +quic を送る
sudo tcpdump -ni any 'udp port 853'
  • 何も表示されない。 パケットがサーバーまで届いていません。クラウドのセキュリティグループやネットワーク ACL で、TCP 853 番だけを許可して UDP を許可していない設定はよくある見落としです。社内ネットワーク、公衆 Wi-Fi、一部のモバイル回線では、外向きの UDP を一般的なポート以外で止めていることもあります。別の回線(スマートフォンのテザリングなど)から試すと、経路の問題かどうかを判断できます。
  • 届いているが応答がない。 サーバー内のファイアウォールか、待ち受けの問題です。ufw を使っているなら、許可の一覧を確かめて UDP を追加します。
sudo ufw status verbose
sudo ufw allow 853/udp

IPv6 を有効にしている場合は、IPv6 側のファイアウォールでも許可されているかを確かめます。クライアントが IPv6 を優先して接続し、IPv6 側だけ止まっている、という状態は気付きにくい原因です。

原因3:サーバーが DoQ を待ち受けていない

自前のリゾルバーでは、待ち受けそのものができていないことがあります。

sudo ss -ulnp | grep ':853'
sudo journalctl -u dnsdist --since "1 hour ago"
  • ss に UDP の 853 番が表示されなければ、DoQ の待ち受けが起動していません。dnsdist では、設定に addDOQLocal を書いても、DoQ の機能を含まないビルドでは起動時にエラーになります。dnsdist --version の機能一覧で DoQ に対応しているかを確かめます。
  • 待ち受けアドレスが 127.0.0.1 や IPv4 だけになっていないかも確認します。
  • 証明書や秘密鍵のファイルを読めず、待ち受けに失敗していることもあります。ログに権限エラーが出ていれば、実行ユーザーで読める権限に直します。

原因4:証明書の検証に失敗している

接続してすぐ切れる場合は、証明書を疑います。DoT 側でも同じ証明書を使っているなら、openssl s_client -connect dns.example.com:853 -servername dns.example.com の出力で、期限、ホスト名、チェーンをまとめて確認できます。

  • ホスト名が合っていない。 証明書の名前と、クライアントに設定したホスト名を比べます。IP アドレスだけで接続する設定では、ホスト名の検証ができずに失敗するクライアントがあります。
  • 中間証明書が含まれていない。 サーバー証明書単体ではなく fullchain.pem を指定します。
  • 期限が切れている。 証明書を更新したあと、DoQ の待ち受けが古い証明書のままになっていないかも確かめます。再読み込みで DoQ 側が更新されない実装では、サービスの再起動が必要です。

原因5:ALPN の不一致

DoQ では、TLS の ALPN という仕組みで「DoQ で話す」ことを伝え、RFC 9250 では値を doq と定めています。標準化の途中の版を実装した古いクライアントやサーバーは、doq-i02 のような別の値を使っていることがあり、相手と合わないとハンドシェイクで失敗します。

openssl s_client -quic -alpn doq で接続できるのに特定のクライアントだけ失敗する場合は、そのクライアントのバージョンが古い可能性があります。クライアントとサーバーの両方を、RFC 9250 に対応した版へ更新するのが根本的な直し方です。

原因6:パケットサイズと UDP のタイムアウト

最初は動くのにときどき止まる場合や、特定の回線でだけ失敗する場合は、ネットワークの UDP の扱いを疑います。

  • パケットサイズ。 QUIC は、接続の最初のパケットを 1,200 バイト以上の UDP で送る決まりです。VPN やトンネルの中など、通せるサイズが小さい経路では、この大きなパケットだけが落ち、通常の DNS(小さな UDP)は通るのに DoQ だけ失敗する、という症状になります。VPN を切って試す、別の回線で試す、といった比較で判断します。
  • UDP のタイムアウト。 NAT やファイアウォールは、通信のない UDP の対応表を短い時間で消すことがあります。DoQ のクライアントが接続を使い回していると、しばらく問い合わせがなかった後の最初の問い合わせだけ失敗し、再接続で回復する、という動きになります。多くのクライアントは自動で接続し直しますが、待ち時間が長いならクライアントを更新するか、設定でアイドル時のタイムアウトを短くします。

原因7:サーバー側の負荷と制限

利用者が増えてから失敗が増えた場合は、サーバー側の制限を確認します。dnsdist で送信元ごとのレート制限を入れているなら、正当なクライアントまで制限に当たっていないかをログやメトリクスで確かめます。UDP の受信バッファが小さいと、混雑時にパケットを取りこぼすこともあります。カーネルのパラメーターを変える前に、まずはどのくらいの問い合わせが来ているかを把握するのが先です。

直すまでの間の回避策

原因の特定に時間がかかる場合は、同じリゾルバーで DoT(TCP 853)や DoH(TCP 443)も提供しておき、クライアントをそちらに切り替えると、暗号化を保ったまま名前解決を続けられます。特に UDP を止めている経路では、DoH が通ることが多いです。DoQ を復旧させたら、クライアントの設定を戻します。

まとめ

  • DoQ は UDP の 853 番を使います。まず DoT(TCP 853)と比べ、UDP の経路か DoQ の待ち受けかに絞ります。
  • 端末側では、Android のプライベート DNS は DoT、ブラウザや Windows の標準機能は DoH です。DoQ を使うには対応したアプリやプロキシが必要です。
  • サーバー側は、tcpdump でパケットの到着、ss で待ち受け、ログで証明書の読み込みを順に確かめます。
  • 接続直後のエラーは証明書と ALPN(doq)、ときどき止まる症状はパケットサイズと UDP のタイムアウトを疑います。

お気軽にご相談ください

お見積りへ お問い合わせへ
▲