DNSKEY レコード
概要
DNSKEY レコード は、DNSSEC(DNS Security Extensions)の署名検証に使う公開鍵を格納する DNS レコードです。RFC 4034(2005年)で定義されており、レコードタイプ番号は 48 です。
DNSSEC はゾーン内の各レコードに電子署名(RRSIG レコード)を付与し、応答が改ざんされていないことを検証する仕組みです。DNSKEY レコードはその署名を検証するための公開鍵を公開します。リゾルバーは DNSKEY レコードの公開鍵を使って RRSIG を検証し、DNS 応答の真正性を確認します。
仕組み
DNSKEY レコードは Flags・Protocol・Algorithm・Public Key の 4 フィールドで構成され、ZSK と KSK の 2 種類の鍵を格納します。
レコードの構造
DNSKEY レコードは 3 つのフィールドで構成されます。
example.com. IN DNSKEY 257 3 13 mdsswUyr3DPW132mOi8V9xESWE8jTo0d...
| フィールド | 説明 |
|---|---|
| Flags | 鍵の種類を示すフラグ。256 は ZSK(Zone Signing Key)、257 は KSK(Key Signing Key) |
| Protocol | 常に 3(DNSSEC)。RFC 4034 で固定値として規定されている |
| Algorithm | 暗号アルゴリズム番号。13(ECDSAP256SHA256)や 8(RSASHA256)などがある |
| Public Key | Base64 エンコードされた公開鍵データ |
ZSK と KSK の役割
DNSSEC では 2 種類の鍵ペアを使い分けます。
ZSK(Zone Signing Key) は、ゾーン内の各 DNS レコードセット(A、MX、TXT など)に対する RRSIG 署名を作成します。Flags は 256 です。ZSK はゾーン内の全レコードに署名するため、頻繁にローテーションします(一般的に 1〜3 か月)。
KSK(Key Signing Key) は、DNSKEY レコードセット自体に署名します。Flags は 257 です。KSK のハッシュ値が親ゾーンに DS レコードとして登録され、信頼の連鎖(Chain of Trust)を構成します。KSK は親ゾーンとの連携が必要なため、ZSK より長い間隔(1〜2 年)でローテーションします。
信頼の連鎖
DNSSEC の検証は次の流れで行われます。
- リゾルバーがルートゾーンの KSK(トラストアンカー)を保持している
- ルートゾーンの DS レコードが
.comゾーンの KSK のハッシュを格納している .comゾーンの DS レコードがexample.comゾーンの KSK のハッシュを格納しているexample.comの KSK で DNSKEY レコードセットの RRSIG を検証する- 検証された DNSKEY レコードセットから ZSK を取り出す
- ZSK で各 DNS レコードの RRSIG を検証する
このチェーンが 1 か所でも途切れると、DNSSEC の検証が失敗して SERVFAIL が返ります。
暗号アルゴリズム
RFC 8624(2019年)でアルゴリズムの推奨ステータスが整理されています。
| 番号 | アルゴリズム | ステータス |
|---|---|---|
| 8 | RSA/SHA-256 | 実装推奨 |
| 13 | ECDSA Curve P-256 with SHA-256 | 実装推奨 |
| 14 | ECDSA Curve P-384 with SHA-384 | 実装推奨 |
| 15 | Ed25519 | 実装推奨 |
アルゴリズム 13(ECDSAP256SHA256)は鍵サイズが小さく、RSA 系と比較して DNS パケットサイズの増大を抑えられるため、近年の DNSSEC 導入で採用が増えています。Cloudflare は ECDSA P-256(アルゴリズム 13)をデフォルトで使用しています。
設定例
KSK(Flags 257)と ZSK(Flags 256)の組み合わせを、ECDSA P-256 と RSA/SHA-256 の両アルゴリズムで示します。
KSK と ZSK の組み合わせ
; KSK (Flags 257)
example.com. IN DNSKEY 257 3 13 (
mdsswUyr3DPW132mOi8V9xESWE8jTo0d
xCjjnopKl+GqJxpVXckHAeF+KkxLbxIL
fDLUT0rAK9iUzy1L53eKGQ==
)
; ZSK (Flags 256)
example.com. IN DNSKEY 256 3 13 (
oJMRESz5E4gYzS/q6XDrvU2qTLFz1hRL
Lkrl3xEpNuo9HNmrFQY3w1sXrg0aHMKB
TVhEOYPhVFb+GOPaYDSHQw==
)
ECDSA P-256(アルゴリズム 13)
現在の推奨構成です。鍵サイズが小さいため、UDP パケットサイズの制約に収まりやすくなります。
example.com. IN DNSKEY 257 3 13 (
kXKkvWU3vGYfTJGl3qBd4qhiGp5MIsQh
BOkOYnRMNiGBz/wq+bNaEg== )
RSA/SHA-256(アルゴリズム 8)
レガシー互換性が必要な場合に使います。鍵長 2048 ビットの RSA では公開鍵データが長くなります。
example.com. IN DNSKEY 257 3 8 (
AwEAAbOFAxl+Lkt0UMglZizKEC1IuP9MJ
MqBkP5FQ5hkA/hZVzpOFxcuLR5f1Nqr7E
... (長い Base64 データ) )
確認方法
dig で DNSKEY レコードを確認するには次のコマンドを使います。
dig DNSKEY example.com
出力の ANSWER SECTION に Flags、Protocol、Algorithm、公開鍵データが表示されます。
;; ANSWER SECTION:
example.com. 3600 IN DNSKEY 257 3 13 mdsswUyr3DPW132mOi8V9xESWE8jTo0d...
example.com. 3600 IN DNSKEY 256 3 13 oJMRESz5E4gYzS/q6XDrvU2qTLFz1hRL...
Flags が 257 のレコードが KSK、256 のレコードが ZSK です。
RRSIG レコードも合わせて確認するには +dnssec オプションを付けます。
dig DNSKEY example.com +dnssec
+dnssec オプションを付けると RRSIG レコードも返り、署名の状態を確認できます。
DNSSEC の信頼の連鎖全体を検証するには +trace と +dnssec を組み合わせます。
dig A example.com +trace +dnssec
Labee Dev Toolbox の DNS API は現在 DNSKEY レコードタイプに対応していないため、dig コマンドで確認します。
よくある問題
DNSKEY レコード関連のトラブルは DS レコードとの連携ミス、ZSK 署名の期限切れ、パケットサイズ超過に起因します。
KSK ローテーション時に DS レコードの更新を忘れる
KSK を更新したら、新しい KSK のハッシュ値を DS レコードとして親ゾーンに登録する必要があります。古い DS レコードしか存在しないと、リゾルバーが新しい KSK を検証できず SERVFAIL が返ります。RFC 7583 では、新旧両方の DS レコードが一定期間共存する「Double-DS」ローテーション手順を規定しています。
ZSK の期限切れで署名が無効になる
RRSIG には有効期限があり、ZSK のローテーションと再署名が期限内に行われないと署名が失効します。自動署名を有効にしていないゾーンでは、手動で再署名する運用が必要です。Cloudflare や Route 53 のマネージド DNSSEC では、プロバイダーが鍵のローテーションと再署名を自動的に処理します。
DNSKEY レコードが UDP パケットサイズを超える
RSA 2048 ビットの KSK + ZSK を含む DNSKEY 応答はパケットサイズが大きくなります。UDP の最大ペイロードサイズ(通常 1232 バイト が推奨上限、DNS Flag Day 2020 推奨値)を超えると TCP へフォールバックしますが、ファイアウォールが DNS over TCP(ポート 53)をブロックしていると応答を受け取れません。ECDSA(アルゴリズム 13)に移行すると鍵サイズが大幅に小さくなり、この問題を回避できます。
DNSSEC を無効化する際にゾーンが解決不能になる
DNSSEC を無効化する際は、先に親ゾーンの DS レコードを削除し、その TTL が世界中のキャッシュから消えるまで待ってから、ゾーンの DNSKEY と RRSIG を削除します。この順序を守らないと、リゾルバーが DS レコードの存在を根拠に DNSSEC 検証を試みて失敗し、ドメインが解決不能になります。