KSK（Key Signing Key）

概要

KSK（Key Signing Key） は、DNSSEC で DNSKEY RRset（ゾーンの公開署名鍵群）に署名するための鍵ペアです。RFC 4033・RFC 4034・RFC 4035（2005年）で定義されており、DNSSEC の信頼の連鎖（Chain of Trust）の起点として機能します。

DNSSEC は ZSK（Zone Signing Key）と KSK の 2 種類の鍵を使い分けます。ZSK はゾーン内の A レコードや MX レコードなどの個別 RRset に署名する「作業用の鍵」です。KSK は DNSKEY RRset（ZSK と KSK の公開鍵が含まれるレコード群）に署名する「信頼の保証役」です。KSK の公開鍵のハッシュが親ゾーンに DS レコードとして登録されることで、親ゾーンから子ゾーンへの信頼の連鎖が成立します。

DNSKEY レコードでは、フラグフィールドの値 257 が KSK、256 が ZSK を示します。KSK は SEP（Secure Entry Point）ビットが立ったフラグ値です。

仕組み

KSK は DNSKEY RRset への署名と、DS レコード経由での親ゾーンとの信頼の連鎖構成という 2 つの役割を担います。

KSK の役割

KSK は DNSSEC の信頼モデルにおいて 2 つの役割を担います。

一つ目は DNSKEY RRset への署名です。ゾーンの DNSKEY レコードには ZSK と KSK の両方の公開鍵が含まれます。KSK の秘密鍵でこの DNSKEY RRset に署名し、RRSIG を生成します。リゾルバーは KSK の公開鍵で DNSKEY RRset の RRSIG を検証し、ZSK の公開鍵が正当であることを確認します。

二つ目は親ゾーンとの信頼の連鎖の構成です。KSK の公開鍵からハッシュ値を計算し、親ゾーンに DS（Delegation Signer）レコードとして登録します。リゾルバーが親ゾーンの DS レコードと子ゾーンの KSK を照合することで、子ゾーンの DNSKEY が正当であることを検証できます。

信頼の連鎖における KSK の位置

ルートゾーン（.）
  KSK → DNSKEY RRset に署名
  DS レコード → .com の KSK ハッシュを保持
        ↓ 親ゾーンの DS と子ゾーンの KSK を照合
.com ゾーン
  KSK → DNSKEY RRset に署名
  DS レコード → example.com の KSK ハッシュを保持
        ↓ 同様に照合
example.com ゾーン
  KSK → DNSKEY RRset に署名
  ZSK → A、MX、TXT 等の各 RRset に署名

リゾルバーは検証時にこの連鎖をルートゾーンまで遡ります。ルートゾーンの KSK はトラストアンカーとしてリゾルバーにあらかじめ設定されているため、ルートから対象ゾーンまでの信頼を連鎖的に検証できます。

DS レコードの生成

DS レコードは KSK の公開鍵からハッシュを計算して生成します。

example.com.  3600  IN  DS  12345 13 2 (
    E2D3C916F6DEEAC73294E8268FB5885044... )

フィールド	内容
12345	KSK の Key Tag
13	アルゴリズム（ECDSAP256SHA256）
2	ダイジェストタイプ（SHA-256）
E2D3C916…	KSK 公開鍵の SHA-256 ハッシュ

RFC 4509（2006年）で SHA-256 ダイジェストタイプが追加されました。現在は SHA-256（ダイジェストタイプ 2）の使用が推奨されています。

KSK のローテーション

KSK のローテーションは ZSK のローテーションより複雑です。親ゾーンの DS レコード更新を伴うため、レジストラとの連携が必要になります。

ダブル KSK ローテーション（RFC 6781 推奨）

1. 新しい KSK を生成し、DNSKEY RRset に追加する
2. 新しい KSK で DNSKEY RRset に再署名する
3. 新しい KSK のハッシュから DS レコードを生成し、レジストラ経由で親ゾーンに追加する
4. 旧 DS レコードの TTL が世界中で切れるまで待つ
5. 親ゾーンから旧 DS レコードを削除する
6. 旧 DS の TTL が切れるまで待つ
7. 旧 KSK を DNSKEY から削除する

各ステップの間にキャッシュの TTL 分の待機期間が必要です。KSK のローテーションは全体で数日〜数週間かかることがあります。

ルートゾーンの KSK ロールオーバー

ルートゾーンの KSK は ICANN が管理しています。2018 年 10 月 11 日に初めてのルート KSK ロールオーバーが実施されました。旧鍵（KSK-2010）から新鍵（KSK-2017）への移行で、RFC 5011（2007年）で定義された自動トラストアンカー更新プロトコルを使い、DNSSEC 対応リゾルバーのトラストアンカーを自動的に更新しました。

当初 2017 年 10 月に予定されていたロールオーバーは、一部のリゾルバーが新しいトラストアンカーを取得できていない問題が発見されたため 1 年延期されました。

確認方法

dig コマンドで DNSKEY レコードを問い合わせると、KSK を確認できます。

dig DNSKEY example.com

;; ANSWER SECTION:
example.com.  3600  IN  DNSKEY  256 3 13 MjyZielP0Gqn...  ; ZSK
example.com.  3600  IN  DNSKEY  257 3 13 mdsswUyr3DPW...  ; KSK

フラグ 257 が KSK です。

DS レコードは親ゾーンに問い合わせます。

dig DS example.com

;; ANSWER SECTION:
example.com.  3600  IN  DS  12345 13 2 E2D3C916F6DEE...

DS レコードの Key Tag（12345）と DNSKEY の KSK の Key Tag が一致すれば、信頼の連鎖が正しく構成されています。

# DNSSEC 検証の状態を確認（ad フラグの有無）
dig A example.com +dnssec @8.8.8.8

応答ヘッダーの flags: に ad が含まれていれば、KSK を起点とした信頼の連鎖が正しく検証されています。

外部の視点からも確認したい場合は、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 }
}

Labee Dev Toolbox の DNS API は DNS over HTTPS を使って外部のリゾルバーからレコードを取得します。リゾルバーは DNSSEC 検証を有効にしているため、API がレコードを正常に返せば、KSK を含む信頼の連鎖が正しく機能していることを意味します。

よくある問題

KSK に関する障害は、DS レコードの更新忘れや DNSSEC 無効化時の手順ミスで信頼の連鎖が切れ、名前解決が完全に停止するケースが典型的です。

DS レコードの更新忘れ

KSK をローテーションした際に、レジストラで DS レコードの更新を忘れると信頼の連鎖が切れます。親ゾーンの DS レコードが旧 KSK のハッシュを指したまま、ゾーンから旧 KSK を削除すると、リゾルバーは DNSKEY RRset の検証に失敗し SERVFAIL を返します。ドメインの名前解決が完全に停止する深刻な障害です。

DNSSEC を無効化する際の手順ミス

DNSSEC を無効化する場合は、先にレジストラから DS レコードを削除し、DS レコードの TTL が切れてからゾーンの署名を停止する必要があります。署名を先に停止すると、DS レコードが残っている間、リゾルバーは DNSSEC 検証を試み、署名なし応答に対して SERVFAIL を返します。

レジストラが DS レコードの管理に対応していない

一部のレジストラは DS レコードの登録や更新を管理画面から行えません。DNSSEC を利用するためには、DS レコードの管理に対応したレジストラを選択するか、レジストラのサポートに直接依頼する必要があります。Cloudflare Registrar や Google Domains は DS レコードの管理をサポートしています。