EDNS0 と DoH (DNS over HTTPS) を併用する設定｜バッファサイズ・パディング・Client Subnet をどう決めるか

DoH（DNS over HTTPS）でも、DNS のメッセージの中身は従来と同じ形式で、EDNS0（DNS の拡張の仕組み）はそのまま使われます。ただし、DoH では EDNS0 の項目ごとに意味が変わります。UDP のバッファサイズは DoH の区間では効かなくなり、パディング（EDNS Padding）は暗号化の効果を保つために重要になり、Client Subnet（ECS）は DoH で守ったはずのプライバシーを損ねることがあります。この記事では、Unbound で DoH を提供する構成を例に、EDNS0 の3つの項目をどう設定するか、設定が効いているかを dig でどう確かめるかを説明します。

DoH サーバーそのものの立て方や公開時の制限は別の記事で扱っています。ここでは EDNS0 の扱いに絞ります。

DoH の中で EDNS0 がどう扱われるか

DNS の問い合わせの経路は、DoH を使っても2つの区間に分かれます。

• 端末から DoH サーバーまで。 DNS のメッセージを HTTPS（HTTP/2 など）で運びます。TCP やその上の TLS で運ぶため、UDP のように大きさの制限で応答が切り詰められる（TC フラグが立つ）ことは基本的に起きません。
• DoH サーバー（リゾルバー）から権威サーバーまで。 ここは従来どおり UDP と TCP の DNS です。EDNS0 のバッファサイズが効くのはこちらの区間です。

この2区間を意識すると、各項目の決め方が分かりやすくなります。

手順0：Unbound が DoH に対応しているかを確かめる

Unbound で DoH を提供するには、HTTP/2 のライブラリ（libnghttp2）と一緒にビルドされている必要があります。

unbound -V

出力のビルドオプションに libnghttp2 の記載があれば DoH を使えます。ない場合、ディストリビューションのパッケージが対応していない可能性があるため、別のパッケージやビルドを検討します。設定を変える前に、unbound.conf と関連ファイルのバックアップを取っておきます。

手順1：DoH の待ち受けと EDNS0 の設定を書く

DoH の待ち受けと、EDNS0 に関わる項目をまとめた例です。パスや値は環境に合わせて変えてください。

server:
    # DoH の待ち受け
    interface: 0.0.0.0@443
    interface: ::0@443
    https-port: 443
    http-endpoint: "/dns-query"
    tls-service-key: "/etc/unbound/tls/privkey.pem"
    tls-service-pem: "/etc/unbound/tls/fullchain.pem"

    # 権威サーバーへの問い合わせで使うバッファサイズ
    edns-buffer-size: 1232

    # 暗号化した区間のパディング
    pad-responses: yes
    pad-responses-block-size: 468
    pad-queries: yes
    pad-queries-block-size: 128

    # 検証つきのリゾルバーとして動かす
    module-config: "validator iterator"
    auto-trust-anchor-file: "/var/lib/unbound/root.key"

    # 利用者を絞る（例）
    access-control: 0.0.0.0/0 refuse
    access-control: 192.0.2.0/24 allow

保存したら unbound-checkconf で文法を確かめてから再起動します。各項目の意味と、決め方の理由を順に説明します。root.key の場所はディストリビューションで異なるので、既存の設定に合わせます。

バッファサイズ（edns-buffer-size）

edns-buffer-size は、Unbound が権威サーバーへ問い合わせるときに「この大きさまでなら UDP で受け取れる」と伝える値です。大きすぎると、途中で IP の断片化が起き、断片が落とされて応答が届かないことがあります。2020年の DNS Flag Day で示された 1232 バイトが広く使われていて、Unbound の最近のバージョンではこれが既定値になっています。既定値のままで問題がなければ、明示しなくても構いません。

DoH の区間には関係しないため、「DoH にしたのでバッファを大きくしてよい」とはなりません。DNSSEC の署名で応答が大きくなる場合も、UDP に収まらなければ TCP に切り替わる動きに任せます。

パディング（pad-responses・pad-queries）

暗号化しても、通信の大きさは外から見えます。問い合わせと応答の大きさの組み合わせから、どのドメインを引いたかを推測される余地があるため、EDNS0 の Padding オプションでメッセージを決まった大きさの倍数にそろえます。RFC 8467 では、問い合わせを 128 バイト、応答を 468 バイトの倍数にそろえる方法が推奨されていて、上の設定もそれに合わせています。

Unbound の pad-responses は、TLS で受けた問い合わせに Padding オプションが付いていた場合に、応答を指定の大きさの倍数にそろえる設定です。クライアントがパディングを付けてこなければ、応答もそろえられません。クライアント側の対応状況は、ブラウザーや OS のバージョンで異なります。pad-queries は Unbound が TLS で上流へ転送するときの問い合わせに関わる設定で、DoT で上流に転送する構成で意味を持ちます。

Client Subnet（ECS）

ECS は、リゾルバーが利用者の IP アドレスの一部を権威サーバーへ伝え、近いサーバーの IP を返してもらうための拡張です。CDN の振り分けには役立つ一方、DoH で隠したはずの利用者の位置の情報を外部へ渡すことになります。

Unbound は、subnetcache モジュールを有効にして送信先を指定しない限り ECS を送りません。上の例の module-config に subnetcache を含めていないのはこのためです。CDN の振り分けの精度を優先して ECS を使う場合は、送る先と送る桁数（プレフィックス長）を絞り、プライバシーポリシーに書いておきます。公開の DoH サービスでも ECS の扱いは事業者ごとに違い、方針は変わることがあります（2026年10月現在）。利用する前に各社の公開情報で確かめてください。

手順2：dig で EDNS0 の項目を確かめる

BIND 9.18 以降の dig は DoH での問い合わせに対応していて、EDNS0 のオプションも付けられます。手元の dig が古い場合は、Knot DNS の kdig でも同様のことができます。

# DoH で問い合わせ、OPT（EDNS0）の欄を見る
dig +https @dns.example.com wordpress.org A

# パディングを付けて問い合わせる
dig +https +padding=128 @dns.example.com wordpress.org A

# ECS を使わないよう求める（0.0.0.0/0 は「位置を使わないで」の意味）
dig +https +subnet=0.0.0.0/0 @dns.example.com wordpress.org A

出力の OPT PSEUDOSECTION に、EDNS のバージョンと udp: の値が表示されます。パディングを付けた問い合わせでは、応答側に PADDING の行が現れれば、Unbound が応答をそろえています。ECS の確認では、応答に CLIENT-SUBNET の行が返ってきた場合、その内容（どの範囲として扱われたか）を見ます。

権威サーバー側の区間は、Unbound のサーバー上から次のように確かめます。

# 権威サーバーが 1232 バイトのバッファで応答できるか
dig +dnssec +bufsize=1232 @ns1.example.com example.com DNSKEY

応答に tc フラグが立てば、UDP に収まらず TCP へ切り替わる状況です。権威サーバーへの TCP 53 番がファイアウォールで閉じていると、ここで名前解決が失敗します。

つまずきやすい点

• DoH の応答だけが遅い、または失敗する。 端末から DoH サーバーまでは問題がなく、権威サーバーへの区間で詰まっていることがあります。サーバー上で dig を使い、UDP の応答が届くか、TCP への切り替えが通るかを確かめます。
• 古い権威サーバーが EDNS0 に正しく応答しない。 FORMERR を返したり応答しなかったりする実装が、まれに残っています。Unbound のログで特定の権威サーバーに偏った失敗がないかを見ます。
• HTTP のキャッシュが効かない。 DoH を GET で受けるとき、RFC 8484 では DNS メッセージの ID を 0 にすることが推奨されています。ID が問い合わせごとに変わると、同じ内容でも URL が変わり、手前のキャッシュが効きにくくなります。

まとめ

• DoH の中でも EDNS0 は使われますが、効く区間が項目ごとに違います。端末から DoH サーバーと、リゾルバーから権威サーバーの2区間に分けて考えます。
• バッファサイズは権威サーバー側の区間のための値で、1232 バイトが目安です。DoH にしたからといって大きくはしません。
• パディングは暗号化した区間で通信の大きさを隠すために使い、RFC 8467 の 128／468 バイトを基準にします。
• ECS は既定では送らず、使う場合は範囲を絞ってプライバシーポリシーに書きます。
• 確認は dig +https に +padding や +subnet を付けて行い、権威サーバー側はサーバー上の dig で確かめます。

• DoH (DNS over HTTPS) の導入手順
• dig コマンドで DNS レコードを調査する方法