EDNS0 の鍵を更新する手順｜EDNS0 自体に鍵は無い。DNS Cookie のシークレットとルート KSK のトラストアンカーを入れ替える

EDNS0 は DNS のメッセージに追加情報を載せるための拡張の枠組みで、それ自体は鍵を持ちません。「EDNS0 の鍵」として更新が必要になるのは、EDNS0 のオプションとして運ばれる DNS Cookie のサーバーシークレットと、EDNS0 の DO ビットで要求する DNSSEC の検証に使うルートのトラストアンカー（KSK）の2つが主なものです。この記事では、BIND と Unbound を例に、それぞれを止めずに入れ替える手順と確認方法を説明します。

EDNS0 と「鍵」の関係を整理する

EDNS0（RFC 6891）は、問い合わせと応答に OPT という疑似レコードを付け、UDP で受け取れるサイズや各種オプションを伝える仕組みです。鍵が関わるのは、その上に載る次のような機能です。

ゾーンの署名鍵（ZSK・KSK）のロールオーバーや TSIG の鍵は EDNS0 の機能ではないため、ここでは扱いません。

DNS Cookie のサーバーシークレットを入れ替える

DNS Cookie は、クライアントとサーバーが互いに Cookie を付け合うことで、送信元を偽った問い合わせによる反射攻撃などを難しくする仕組みです。サーバーは、クライアントの IP アドレスやクライアント Cookie、時刻などとシークレットから、サーバー Cookie を計算します。シークレットが漏れると、第三者が正しいサーバー Cookie を作れてしまうため、定期的に、また漏えいの疑いがあるときに入れ替えます。

入れ替えの基本は「新しいシークレットを先に受け入れ用として配り、次に生成用へ切り替え、最後に古いものを外す」という3段階です。いきなり差し替えると、古いシークレットで作られた Cookie を持つクライアントの検証が一時的に合わなくなります。複数台のサーバーで同じシークレットを共有している構成（エニーキャストなど）では、全台に配り終えてから次の段階へ進みます。

シークレットを作る

SipHash-2-4 を使う方式（RFC 9018）では、シークレットは 128 ビットです。16 進数で 32 文字の値を作ります。

openssl rand -hex 16

作った値は設定ファイルに書くことになるため、ファイルの権限を DNS サーバーの実行ユーザーと管理者だけが読める状態にしておきます。値をチャットやチケットに貼らないようにします。

BIND の場合

BIND では cookie-secret を複数書けます。最初に書いたものが新しい Cookie の生成に使われ、残りは返ってきた Cookie の検証にだけ使われます。この仕様をそのまま入れ替えの3段階に当てはめます。

// 段階1: 新しいシークレットを2番目に追加（検証のみに使われる）
options {
    cookie-algorithm siphash24;
    cookie-secret "現在のシークレット（32文字の16進数）";
    cookie-secret "新しいシークレット（32文字の16進数）";
};

全台に反映したら、順番を入れ替えて新しいシークレットを1番目にします（段階2）。しばらく置いてから、古いシークレットの行を削除します（段階3）。各段階の反映は設定の確認と再読み込みで行います。

sudo named-checkconf
sudo rndc reconfig

cookie-algorithm で選べる方式は版によって異なり、新しい版では SipHash-2-4 を前提にしています（2026年10月現在）。お使いの版のリファレンスで確認してください。段階2から段階3までの間は、クライアントが新しい Cookie を受け取り直すのに十分な時間を取ります。RFC 9018 の Cookie には時刻が含まれ、古い Cookie は一定時間で作り直される仕組みなので、数時間から1日程度の重なりを持たせておくと安心です。

Unbound の場合

Unbound では answer-cookie: yes で DNS Cookie に応答するようになり、cookie-secret でシークレットを指定できます。新しめの版では、シークレットをファイルで管理し、unbound-control で追加・切り替え・削除する仕組みも用意されています。対応する版や項目名はリリースノートで確かめてください。

# unbound.conf（例）
server:
    answer-cookie: yes
    cookie-secret: "現在のシークレット（32文字の16進数）"

設定ファイルに1つだけ書く方式では、値を書き換えて再起動すると切り替えは一度に起きます。Unbound をキャッシュ DNS として使っていて、クライアントが Cookie を必須にしていない一般的な構成なら影響は小さいものの、影響を避けたい場合は、段階的な切り替えに対応した版の仕組みを使います。

入れ替え後の確認

dig で Cookie 付きの問い合わせを送り、OPT の欄に COOKIE が返ることを確かめます。

dig @ns1.example.com example.com SOA +cookie +norecurse

OPT PSEUDOSECTION の COOKIE: にクライアント Cookie とサーバー Cookie が続けて表示され、dig が正しいと判断した印が付いていれば応答できています。表示の形式は dig の版で異なります。入れ替えの途中で require-server-cookie のような Cookie を必須にする設定は有効にしないでください。古い Cookie を持つクライアントが一時的に通らなくなる可能性があります。

ルート KSK のトラストアンカーを更新する

DNSSEC の検証は、ルートゾーンの鍵（KSK）を信頼の起点にします。この起点がリゾルバーの持つトラストアンカーです。ルートの KSK は ICANN の計画に沿って入れ替えが進められており、新しい鍵 KSK-2024 がルートゾーンに公開され、署名への切り替えと旧鍵 KSK-2017 の失効が予定されています（2026年10月現在の計画。日程と進み具合は ICANN の告知で確認してください）。

トラストアンカーが古いままのリゾルバーは、旧鍵が使われなくなると署名済みのドメインをすべて検証できず、SERVFAIL を返すようになります。DO ビットで署名を要求している以上、EDNS0 を使う検証リゾルバーすべてに関わる作業です。

自動更新になっているかを確かめる

多くのリゾルバーは、RFC 5011 の手順でトラストアンカーを自動更新できます。自動更新の設定になっていれば、管理者の作業は「本当に新しい鍵を取り込んでいるか」の確認だけです。

# Unbound: 自動更新用ファイルを使っているか、新しい鍵が入っているか
grep -n auto-trust-anchor-file /etc/unbound/unbound.conf /etc/unbound/unbound.conf.d/*.conf
sudo grep -n "id = " /var/lib/unbound/root.key

# BIND: 管理しているトラストアンカーの状態
sudo rndc managed-keys status

Unbound の自動更新ファイルには、鍵ごとに id = に続けて鍵の番号と状態が記録されます。KSK-2017 の 20326 に加えて、新しい鍵の番号（KSK-2024 は 38696 と公表されています）が有効な状態で入っているかを見ます。BIND で dnssec-validation auto; を使っている場合は、組み込みのルート鍵と RFC 5011 による更新が使われます。古い版の BIND では組み込みの鍵が新しい KSK を含まないことがあるため、版の更新も合わせて検討してください。

自動更新されない構成を探す

注意が必要なのは、次のような構成です。

• trust-anchor-file などで、鍵を固定のファイルとして読み込んでいる（RFC 5011 の更新が働かない）
• コンテナイメージに古いトラストアンカーを焼き込み、書き込めない場所に置いている
• 長期間停止していた予備のサーバーや、バックアップから戻したサーバー

固定のファイルを使っている場合は、Unbound なら unbound-anchor で取得し直すなどの方法で更新し、可能なら自動更新の設定へ切り替えます。

sudo unbound-anchor -a /var/lib/unbound/root.key

応答サイズと TCP を確かめる

鍵の入れ替えの期間は、ルートの DNSKEY の応答に複数の鍵と署名が並び、大きくなります。EDNS0 のバッファサイズを 1232 バイト程度にしている環境では、応答が切り詰められて TCP で取り直すことになるため、リゾルバーから外向きの TCP の 53 番が通る必要があります。

dig . DNSKEY +dnssec +bufsize=1232
dig . DNSKEY +dnssec +tcp

1つ目で flags: に tc が付き、2つ目で応答が返れば、切り詰めからの TCP 再送が成り立っています。2つ目がタイムアウトするなら、ファイアウォールやセキュリティグループを見直します。

作業前の注意

どちらの作業も、名前解決が止まるとサイト全体に影響します。設定ファイルを控え、DNS が止まってもサーバーへ入れる経路を確保し、ステージングや予備のサーバーで手順を試してから本番に反映してください。WordPress が動くサーバーのリゾルバーが SERVFAIL を返すようになると、プラグインの更新確認や外部 API、メール送信がまとめて失敗します。

まとめ

• EDNS0 は拡張の枠組みで、鍵を持ちません。更新が要るのは DNS Cookie のシークレットと、DNSSEC 検証のトラストアンカーです。
• DNS Cookie のシークレットは「受け入れ用に追加→生成用に切り替え→古いものを削除」の3段階で、全台にそろえながら入れ替えます。
• ルート KSK の入れ替えが進む時期です。RFC 5011 の自動更新になっているか、新しい鍵が取り込まれているかを確かめ、固定ファイルや古いイメージを洗い出します。
• 鍵の入れ替え中は応答が大きくなるため、TCP の 53 番が通るかも合わせて確認します。

• DNSSEC を有効化する手順と注意点
• BINDでDNSサーバーを構築する方法