DNSKEYレコードは手で書き込むものではなく、権威DNSサーバーの署名機能に鍵を作らせ、ゾーンに自動で公開させるのが今の標準的な設定方法です。BIND 9 なら dnssec-policy をゾーンに指定するだけで、鍵の生成・DNSKEYの公開・署名の更新までを行います。この記事では、DNSKEYの役割を確認したうえで、BINDでの設定、公開されたDNSKEYからDSレコードを作って親ゾーンに登録する手順、マネージドDNSや他の権威DNSソフトでの考え方を説明します。DNSKEYが正しく設定されたかを細かく点検する方法は、検証手順を扱う別記事に任せ、ここでは「設定して公開するまで」に絞ります。
DNSKEYレコードの役割
DNSSECでは、ゾーンの各レコードに署名（RRSIG）を付け、その署名を確かめるための公開鍵をDNSKEYレコードとして公開します。DNSKEYには主に2種類があります。
- KSK（鍵署名鍵）: DNSKEYの集まりそのものに署名する鍵です。フラグの値は257で、親ゾーンに登録するDSレコードはこの鍵から作ります
- ZSK（ゾーン署名鍵）: ゾーン内の通常のレコードに署名する鍵です。フラグの値は256です
最近はKSKとZSKを1本で兼ねるCSK（結合署名鍵）を使う構成も一般的で、BINDの既定のポリシーもこの形です。DNSKEYレコードの中身は次のような形をしています。
example.com. 3600 IN DNSKEY 257 3 13 (公開鍵のBase64文字列)257 がフラグ、3 はプロトコル番号で常に3、13 は署名アルゴリズムの番号です。13は ECDSAP256SHA256 で、鍵と署名が小さく応答サイズを抑えられるため、新しく設定するなら有力な選択肢です。RSA系の8（RSASHA256）も広く対応しています。使うアルゴリズムは、ドメインのレジストリとレジストラがDSの登録に対応しているかを先に確かめて選びます。
設定前に確かめること
- 権威DNSソフトのバージョン:
dnssec-policyはBIND 9.16で導入され、9.18以降の安定版で使うのが前提です。古いauto-dnssecの書き方は新しい版では使えなくなっています（2026年10月現在）。named -vで版を確かめます - 時刻の同期: 署名には有効期間があり、サーバーの時刻がずれると検証に失敗します。NTPなどで時刻を合わせておきます
- セカンダリDNS: セカンダリは署名済みのゾーンを転送で受け取るだけなので、通常は鍵を持たせる必要はありません。ただし、ゾーン転送の応答が大きくなるため、転送が正常に動くかを後で確かめます
- バックアップ: 設定ファイル、ゾーンファイル、鍵を置くディレクトリを控えます。鍵を失うと、DSを登録した後のゾーンが検証できなくなります
手順1：BINDでdnssec-policyを指定する
ゾーンの定義に dnssec-policy と鍵の保存場所を書きます。まずは既定のポリシー（default）で始めるのが簡単です。
// named.conf.local などのゾーン定義
zone "example.com" {
type primary;
file "/var/lib/bind/example.com.zone";
key-directory "/var/lib/bind/keys";
dnssec-policy default;
inline-signing yes;
};inline-signing yes; は、元のゾーンファイルを書き換えずに、署名済みの別ファイルをBINDが管理する方式です。必要かどうかの既定の扱いはBINDの版によって違うため、ここでは明示しています。鍵のディレクトリはBINDの実行ユーザーが書き込める場所にし、他のユーザーからは読めない権限にします。
アルゴリズムや鍵の寿命を自分で決めたい場合は、独自のポリシーを定義して指定します。
dnssec-policy "example-policy" {
keys {
csk lifetime unlimited algorithm ecdsap256sha256;
};
};ゾーン側は dnssec-policy "example-policy"; に変えます。KSKとZSKを分けたい場合は、csk の行を ksk と zsk の2行にし、ZSKに lifetime P90D のような寿命を付けると、BINDが期限に合わせて鍵を入れ替えます。寿命の書き方や入れ替えの細かな挙動は版ごとに変わることがあるため、使っている版の管理者マニュアルで確かめてください。
設定を確かめてから読み込みます。
named-checkconf
rndc reconfig手順2：DNSKEYが公開されたか確かめる
読み込み後、BINDは鍵を生成し、DNSKEYレコードをゾーンに追加して署名を始めます。鍵のディレクトリに Kexample.com.+013+12345.key のような名前のファイルができていれば、鍵は作られています（数字の部分は鍵ごとに変わります）。
# 署名の状態を表示する（BIND 9.18以降）
rndc dnssec -status example.com
# 権威DNSにDNSKEYを問い合わせる
dig @ns1.example.com example.com DNSKEY +multiline +norecurse+multiline を付けると、各DNSKEYの行に KSK や ZSK の種類と鍵の番号（key id）がコメントで表示されます。セカンダリDNSにも同じDNSKEYが届いているかを、ネームサーバーごとに問い合わせて確かめます。
この時点ではまだ親ゾーンにDSが無いため、外部から見るとDNSSECは「署名はあるが、つながっていない」状態です。検証するリゾルバーはこの状態を通常の未署名ゾーンと同じに扱うので、サイトの表示に影響はありません。
手順3：DSレコードを作って親ゾーンに登録する
DSレコードは、KSK（またはCSK）のDNSKEYから作るハッシュ値です。鍵ファイルから作る方法と、公開されたDNSKEYから作る方法があります。
# 鍵ファイルからSHA-256のDSを作る
dnssec-dsfromkey -2 /var/lib/bind/keys/Kexample.com.+013+12345.key
# 公開されているDNSKEYから作る
dig @ns1.example.com example.com DNSKEY +noall +answer | dnssec-dsfromkey -f - -2 example.com出力は example.com. IN DS 12345 13 2 (ハッシュ値) の形です。並んでいる数字は、鍵の番号・アルゴリズム・ダイジェストの種類（2はSHA-256）の順です。これをレジストラの管理画面でDS（またはDNSSEC）の欄に登録します。レジストラによって、DSの4項目を入力する形式と、DNSKEYそのものを入力する形式があります。入力欄の名前や手順はレジストラごとに違います。
DSは、DNSKEYが公開されてすべての権威DNSに行き渡ってから登録します。順序を逆にして、DNSKEYが見えないうちにDSだけが親ゾーンに出ると、検証するリゾルバーからはドメイン全体が SERVFAIL になります。
登録後、親ゾーンにDSが出たかを確かめ、BINDに「DSが公開された」ことを知らせます。
dig example.com DS +short
rndc dnssec -checkds -key 12345 published example.comBINDの版によっては、parental-agents などの設定で親ゾーンのDSを自動で確かめさせることもできます。鍵を入れ替えるときに、BINDはこの情報を手がかりに古いDSを外してよいかを判断するため、手動で知らせるか自動確認を設定するかのどちらかを用意しておきます。
手順4：検証が通るかを確かめる
DSが親ゾーンに出たら、検証するリゾルバーに問い合わせます。
dig @1.1.1.1 example.com A +dnssecヘッダーの flags: に ad が含まれていれば、検証に成功しています。status: SERVFAIL になる場合は、DSと公開中のDNSKEYの鍵番号・アルゴリズムが一致しているかを最初に確かめます。DNSVizなどの可視化ツールを使うと、親ゾーンからDNSKEYまでの鎖のどこが切れているかが図で分かります。
マネージドDNSや他のソフトの場合
- マネージドDNS（Cloudflare、Route 53 など）: 管理画面でDNSSECを有効にすると、DNSKEYはサービス側で作られ公開されます。利用者が行うのは、表示されたDSをレジストラに登録することです。Route 53 では鍵署名鍵にAWS KMSの鍵を使うなど、サービスごとに準備が異なるため、各社の手順書に従います
- PowerDNS:
pdnsutilのサブコマンドでゾーンを署名し、DSを表示できます。版によってサブコマンドの書き方が変わっているため、使っている版のドキュメントで確かめます - Knot DNS: ゾーン設定で自動署名を有効にし、ポリシーでアルゴリズムや鍵の寿命を決めます
どの方式でも、レジストリが CDS・CDNSKEY レコードの自動取り込みに対応していれば、DSの登録や更新を自動化できる場合があります。対応状況はトップレベルドメインごとに違います。
設定後に気をつけること
DNSKEYを公開してDSを登録した後は、DNSサービスの移転やDNSSECの停止に順序が生まれます。停止する場合は先にレジストラでDSを削除し、親ゾーンのDSのTTLが切れてから署名を止めます。鍵のディレクトリはバックアップ対象に加え、権限を絞ったまま保管してください。
まとめ
- DNSKEYは手で書かず、BINDなら
dnssec-policyで鍵の生成と公開を任せる - 新しく設定するなら、アルゴリズムは13（ECDSAP256SHA256）か8（RSASHA256）が一般的で、レジストラの対応を先に確かめる
- 公開されたDNSKEYを権威DNSで確かめてから、
dnssec-dsfromkeyでDSを作って親ゾーンに登録する - 登録後は
rndc dnssec -checkdsなどでBINDにDSの公開を知らせ、adフラグで検証を確かめる - 停止や移転はDSの削除を先に行い、鍵のバックアップと権限管理を続ける