ZSK（Zone Signing Key）
概要
ZSK（Zone Signing Key） は、DNSSEC でゾーン内の各 RRset（同一名・同一タイプのレコード群）に署名するための鍵ペアです。RFC 4033・RFC 4034・RFC 4035（2005年）で定義された DNSSEC アーキテクチャの中核要素であり、A レコード、MX レコード、TXT レコードなど個別のリソースレコードに対する RRSIG を生成します。
DNSSEC は ZSK と KSK（Key Signing Key）の 2 種類の鍵を使い分けます。ZSK はゾーン内のデータに署名する「作業用の鍵」で、KSK は ZSK の正当性を保証する「信頼の起点」です。ZSK は頻繁にローテーション（鍵更新）されるため鍵長を短くでき、署名と検証の処理コストを抑えます。KSK はローテーション頻度が低いため長い鍵長を使い、長期的な安全性を確保します。
DNSKEY レコードでは、フラグフィールドの値 256 が ZSK、257 が KSK を示します。
仕組み
ZSK は各 RRset への署名を担当し、KSK が ZSK の正当性を保証する二重鍵構造で信頼の連鎖を構成します。
ZSK の役割
ZSK は次の流れでゾーンのレコードに署名します。
- 権威ネームサーバー（またはゾーン署名システム）が ZSK の秘密鍵を使い、各 RRset に署名を生成する
- 署名結果を RRSIG レコードとしてゾーンに配置する
- ZSK の公開鍵を DNSKEY レコードとしてゾーンに公開する
再帰リゾルバーが応答を検証するとき、DNSKEY の ZSK 公開鍵で RRSIG の署名を検証します。署名が正しければ、レコードが改ざんされていないことを確認できます。
KSK との関係
ZSK の公開鍵自体の正当性は KSK が保証します。
KSK（秘密鍵）
→ DNSKEY RRset（ZSK の公開鍵を含む）に署名（RRSIG を生成）
ZSK（秘密鍵）
→ A、MX、TXT 等の各 RRset に署名（RRSIG を生成）KSK の公開鍵ハッシュは親ゾーンの DS レコードに登録されています。この DS レコードが、親ゾーンから子ゾーンへの信頼の連鎖（Chain of Trust）を構成します。
ZSK と KSK を分離する設計のメリットは、ZSK のローテーションが親ゾーンとの調整なしに行える点です。ZSK を更新しても、KSK が変わらなければ親ゾーンの DS レコードを変更する必要がありません。KSK のローテーションは親ゾーンの DS レコード更新を伴うため頻度を下げ、ZSK は親ゾーンに影響を与えずに頻繁にローテーションできます。
鍵長とアルゴリズム
RFC 6781（2012年）で鍵運用のガイダンスが示され、RFC 8624（2019年）でアルゴリズムの推奨状態が整理されています。
| アルゴリズム | ZSK の典型的な鍵長 | KSK の典型的な鍵長 |
|---|---|---|
| RSA/SHA-256（アルゴリズム 8） | 1024〜2048 ビット | 2048〜4096 ビット |
| ECDSAP256SHA256（アルゴリズム 13） | 256 ビット | 256 ビット |
| Ed25519（アルゴリズム 15） | 256 ビット | 256 ビット |
ECDSA（アルゴリズム 13）と Ed25519（アルゴリズム 15）は鍵長が短くても RSA 2048 ビット相当の安全性を持ちます。署名サイズも小さいため DNS レスポンスの肥大化を抑えられ、現在の推奨アルゴリズムです。Cloudflare はアルゴリズム 13 を使用しています。
ZSK のローテーション
ZSK は定期的にローテーションします。推奨間隔は 1〜3 か月 です。ローテーション手順には「プレパブリッシュ方式」と「ダブルシグネチャ方式」があります。
プレパブリッシュ方式（RFC 6781 推奨）
- 新しい ZSK の公開鍵を DNSKEY に追加する（まだ署名には使わない）
- 旧 DNSKEY の TTL が世界中で切れるまで待つ
- 新しい ZSK で全 RRset に再署名し、RRSIG を差し替える
- 旧 RRSIG の TTL が切れるまで待つ
- 旧 ZSK を DNSKEY から削除する
各ステップの間に旧レコードの TTL 分の待機期間を設けることで、リゾルバーが旧鍵の DNSKEY と新鍵の RRSIG を同時に参照して検証に失敗するリスクを避けます。
具体例
DNSKEY レコードに含まれる ZSK と KSK の例です。
dig DNSKEY example.com;; ANSWER SECTION:
example.com. 3600 IN DNSKEY 256 3 13 MjyZielP0Gqn... ; ZSK（フラグ 256）
example.com. 3600 IN DNSKEY 257 3 13 mdsswUyr3DPW... ; KSK（フラグ 257）フラグ 256 が ZSK、257 が KSK です。3 はプロトコル番号（固定値）、13 はアルゴリズム番号（ECDSAP256SHA256）です。
確認方法
dig コマンドで DNSKEY レコードを問い合わせると、ZSK と KSK の両方が返ります。
dig DNSKEY example.comフラグフィールドが 256 のエントリが ZSK です。+dnssec フラグを付けると RRSIG も一緒に返ります。
dig DNSKEY example.com +dnssec# 署名に使われている鍵の Key Tag を確認
dig A example.com +dnssecRRSIG の Key Tag フィールドと DNSKEY の Key Tag を照合することで、どの ZSK で署名されているかを特定できます。
外部の視点からも確認したい場合は、Labee Dev Toolbox の DNS API を使うと、外部の視点から見た結果を取得できます。
curl "https://labee.dev/api/dns?domain=example.com&type=A"{
"success": true,
"data": {
"domain": "example.com",
"records": {
"A": [
{ "address": "93.184.216.34", "ttl": 3600 }
]
}
},
"error": null,
"meta": { "responseTime": 45 }
}API が正常にレコードを返せば、リゾルバーが DNSSEC 検証（ZSK による署名の検証を含む）に成功しています。
よくある問題
ZSK の運用では、ローテーション手順の省略による検証失敗と秘密鍵漏洩時の緊急対応が主な課題です。
ZSK ローテーション中の検証失敗
ローテーション手順で待機期間を省略すると、リゾルバーが古い DNSKEY をキャッシュした状態で新しい RRSIG を受け取り、検証に失敗します。DNSSEC 対応リゾルバーは検証失敗時に SERVFAIL を返すため、ドメインの名前解決が停止します。旧 DNSKEY の TTL が世界中で切れるまで必ず待ってください。
ZSK の秘密鍵が漏洩した
ZSK の秘密鍵が漏洩した場合、攻撃者がそのゾーンの任意のレコードに有効な署名を生成できます。ただし ZSK のローテーションが定期的に行われていれば、被害のウィンドウは限定されます。漏洩が判明したら即座に新しい ZSK を生成し、緊急ローテーションを実行してください。KSK は親ゾーンの DS レコードで保護されているため、ZSK の漏洩だけでは信頼の連鎖全体が破壊されることはありません。
ZSK と KSK を分離せずに運用している
一部の小規模ゾーンでは、ZSK と KSK を分離せず単一の鍵（CSK: Combined Signing Key）で運用する場合があります。RFC 6781 で言及されているこの方式は運用がシンプルですが、鍵のローテーション時に親ゾーンの DS レコード更新が毎回必要になります。Cloudflare のマネージド DNSSEC はこの方式に近い運用を行っていますが、DS レコードの更新が自動化されています。