2026年6月10日

EDNS0 を導入してセキュリティを強化する設定｜バッファサイズ1232・DNS Cookie・パディングの設定と dig での確認

DNS・名前解決

EDNS0 は DNS の拡張の土台で、それ自体が暗号化や認証をする機能ではありません。セキュリティに効くのは、EDNS0 の上で動く DNSSEC・DNS Cookie・パディングなどを正しく有効にし、逆に断片化や情報漏れにつながる設定を抑えることです。この記事では、Unbound と BIND を例に、UDP バッファサイズを 1232 バイトにそろえる理由、DNS Cookie とパディングの有効化、EDNS Client Subnet の扱い、dig での確認方法を説明します。

EDNS0 とセキュリティの関係

EDNS0（RFC 6891）は、DNS メッセージに OPT という疑似レコードを付けて、従来の 512 バイト制限を超える UDP 応答や、追加のフラグ・オプションを運べるようにする仕組みです。現在の DNS は EDNS0 を前提に動いており、セキュリティに関わる次の機能もこの上に乗っています。

DNSSEC。 問い合わせ側が「署名データも欲しい」と伝える DO ビットは EDNS0 のフラグです。署名付きの応答は大きくなるため、512 バイトを超えて運べることも前提になっています。
DNS Cookie（RFC 7873）。 クライアントとサーバーが軽量なトークンを交換し、送信元を偽装した問い合わせや偽の応答を見分けやすくします。
パディング（RFC 7830）。 DoT や DoH で暗号化した通信の長さをそろえ、メッセージの長さから問い合わせ内容を推測されにくくします。
Extended DNS Errors（RFC 8914）。 SERVFAIL の理由（DNSSEC の検証失敗など）を詳しく返せるため、障害時の切り分けが速くなります。

一方で、EDNS0 の使い方次第で弱点になる部分もあります。大きすぎる UDP 応答は IP の断片化を招き、断片を差し替える形のキャッシュポイズニングや、取りこぼしによる名前解決の失敗につながります。また、利用者のネットワーク情報を上流へ渡す EDNS Client Subnet は、プライバシーの面で注意が必要です。「導入して強化する」とは、こうした機能を目的に合わせて有効・無効にそろえる作業だと考えると分かりやすいです。

作業前の準備

設定ファイル（unbound.conf、named.conf）をバックアップし、変更は検証用の環境で試してから本番へ反映します。
使っているソフトウェアのバージョンを確認します。ここで紹介する設定項目の多くは比較的新しいバージョンで既定値が変わっています。既定値のままで目的の値になっていることも多いため、まず現状を dig で測ってから、足りない部分だけ明示的に書くのが安全です（2026年10月現在）。

unbound -V | head -1
named -v

UDP バッファサイズを 1232 バイトにそろえる

なぜ 1232 なのか

EDNS0 では、受け取れる UDP メッセージの最大サイズを互いに伝えます。以前は 4096 バイトがよく使われていましたが、経路の途中で断片化が起き、断片が届かずに名前解決が失敗する、断片を偽装される、といった問題がありました。そこで DNS Flag Day 2020 では、IPv6 の最小 MTU（1280 バイト）からヘッダー分を引いた 1232 バイトを既定値にする方針が示され、主要な DNS ソフトウェアがこれに合わせました。

1232 バイトを超える応答は、切り詰め（TC フラグ）を返して TCP で取り直させます。そのため、TCP の 53 番が通ることが前提になります。ファイアウォールで UDP 53 番だけを許可している環境では、大きな応答（DNSSEC の署名付き応答など）が引けなくなります。

Unbound

# /etc/unbound/unbound.conf.d/edns.conf（例）
server:
    edns-buffer-size: 1232
    max-udp-size: 1232

BIND

// named.conf の options（例）
options {
    edns-udp-size 1232;
    max-udp-size 1232;
};

最近のバージョンでは既定値がすでに 1232 になっていることが多いため、書くかどうかは確認結果で決めます。明示しておくと、将来の設定見直しで意図が伝わりやすい利点があります。

DNS Cookie を有効にする

DNS Cookie は、クライアントが送るトークンと、サーバーが返すトークンを組み合わせて、やり取りの相手が前回と同じかを確かめる仕組みです。送信元を偽装した大量の問い合わせ（反射攻撃）や、オフパスからの偽応答への対策になります。暗号化ではなく、DNSSEC の代わりにもなりませんが、軽い負担で効果が得られます。

# Unbound（answer-cookie に対応したバージョン）
server:
    answer-cookie: yes

// BIND（既定で有効なことが多い項目）
options {
    answer-cookie yes;
    send-cookie yes;
    // エニーキャストや複数台で同じサーバーとして見せる場合は、全台で同じ秘密値を使う
    // cookie-secret "your-cookie-secret-hex";
};

複数台のサーバーを同じ IP アドレスで見せている（エニーキャストやロードバランサー配下）場合、台ごとに秘密値が違うと Cookie の検証が合わなくなります。BIND では cookie-secret を全台でそろえます。秘密値は推測できない値を生成し、設定ファイルの権限を絞って管理します。

暗号化 DNS ではパディングを有効にする

DoT や DoH で通信を暗号化しても、メッセージの長さは外から見えます。問い合わせる名前によって長さが変わるため、長さの傾向から内容を推測される可能性があります。EDNS0 のパディングで長さを一定のブロック単位にそろえると、この手がかりを減らせます。

# Unbound: TLS 接続（DoT/DoH）でのパディング
server:
    pad-responses: yes
    pad-responses-block-size: 468
    pad-queries: yes
    pad-queries-block-size: 128

ブロックサイズの 128（問い合わせ）と 468（応答）は、RFC 8467 で推奨されている値です。パディングは暗号化された通信でのみ意味があり、平文の UDP に付けても通信量が増えるだけです。Unbound の pad-responses は TLS 接続に対して働く設定です。

EDNS Client Subnet と情報を漏らす設定を確認する

EDNS Client Subnet（ECS）

ECS は、フルリゾルバーが利用者の IP アドレスの一部を権威 DNS へ伝える拡張です。CDN が利用者に近いサーバーを返すために使われますが、利用者のネットワーク情報が外部へ出ていくことになります。社内や自宅のリゾルバーで特別な理由がなければ、送らない設定のままにしておくのが無難です。Unbound では ECS を送るには専用のモジュール（subnetcache）を有効にする必要があり、既定では送りません。dnsdist などのプロキシを挟んでいる場合は、そちらの設定も確認します。

NSID とバージョン情報

NSID（RFC 5001）は、応答したサーバーの識別子を返す拡張で、エニーキャストの障害調査には便利ですが、内部のホスト名をそのまま返すと構成が外から分かります。バージョン情報の問い合わせも同様です。

# Unbound
server:
    hide-identity: yes
    hide-version: yes

BIND では version none; や server-id none; で同様に隠せます。障害調査のために NSID を使いたい場合は、内部名ではなく意味の分からない識別子を返すようにします。

反射攻撃への備えを合わせて行う

EDNS0 で大きな UDP 応答を返せるということは、送信元を偽装された問い合わせに対して大きな応答を第三者へ送ってしまう（増幅攻撃）余地があるということです。次の基本を合わせて確認します。

フルリゾルバーは access-control（Unbound）や allow-recursion（BIND）で、使ってよいネットワークだけに限定します。
権威 DNS では、BIND の rate-limit（RRL）のような応答レート制限を検討します。
DNS Cookie を有効にしておくと、正規のクライアントとそうでない問い合わせを区別しやすくなります。

dig で確認する

設定を反映したら、構文チェックと再読み込みを行い、dig で応答を確かめます。

sudo unbound-checkconf && sudo systemctl reload unbound
# BIND の場合
sudo named-checkconf && sudo rndc reconfig

# OPT PSEUDOSECTION の udp: の値を確認（1232 になっているか）
dig @127.0.0.1 +dnssec www.isc.org A

# DNS Cookie: 出力の COOKIE 行に (good) と表示されれば、サーバー Cookie が返っている
dig @127.0.0.1 +cookie www.isc.org A

# EDNS バージョン 1 で問い合わせ、BADVERS が返るのが正しい実装の動作
dig @127.0.0.1 +edns=1 +noednsneg +norec www.isc.org SOA

# TCP でも引けるか（UDP で切り詰められた応答の取り直しに必要）
dig @127.0.0.1 +tcp www.isc.org A

dig の出力の OPT PSEUDOSECTION には、EDNS のバージョン、フラグ（DNSSEC を求めた場合は do）、UDP サイズ、Cookie などが表示されます。外部向けの権威 DNS を確認するときは、@127.0.0.1 を権威サーバーのアドレスに置き換え、社外のネットワークからも試すと、経路上の機器による影響まで確かめられます。

よくあるつまずき

大きな応答だけ引けない。 TCP の 53 番がファイアウォールで閉じている、または一部のファイアウォールの DNS 検査機能が 512 バイトを超えるパケットを捨てている可能性があります。dig +tcp で引けるか、途中の機器の設定を確認します。
Cookie の検証が不安定。 複数台構成で秘密値がそろっていないことが多い原因です。
ECS を止めたら一部のサイトが遅くなった気がする。 CDN の振り分け精度が下がることがありますが、多くの場合は大きな差になりません。プライバシーとの兼ね合いで判断します。

まとめ

EDNS0 は DNSSEC・DNS Cookie・パディングなどの土台で、セキュリティの強化は「これらを正しく有効にし、断片化や情報漏れにつながる設定を抑える」ことです。
UDP バッファサイズは 1232 バイトにそろえ、TCP の 53 番を通しておきます。
DNS Cookie を有効にし、複数台構成では秘密値をそろえます。DoT/DoH ではパディングを有効にします。
ECS は必要がなければ送らず、NSID やバージョン情報は内部の情報を出さない設定にします。
反映後は dig の OPT PSEUDOSECTION、+cookie、+edns=1、+tcp で確認します。