インターネットを使っていて、「このDNS応答は本当に正しいの？」「誰かが途中で書き換えていないか心配…」「偽のサイトに誘導されたらどうしよう」と不安に思ったことはありませんか？
「DNSSECって複雑そう」「電子署名って何？」「自分のサイトに設定すべき？」と感じている方も多いはずです。
実は、RRSIG（Resource Record Signature）は、DNSレコードに付けられる「デジタル印鑑」のようなもので、DNS応答が本物であることを証明し、改ざんを検出できる重要な技術なんです。まるで、重要書類に押された実印と印鑑証明書のように、「このDNS応答は正規のものです」と証明してくれるんですよ。
この記事では、RRSIGの基本から仕組み、設定方法、検証、トラブル対処まで、初心者の方にも分かりやすく丁寧に解説していきます。
図解や具体例をたくさん使いながら、DNSセキュリティの核心をマスターしていきましょう！
RRSIGとは？その基本を知ろう
基本的な説明
RRSIG（アールアール・シグ）は、DNSレコードに対する電子署名を格納するDNSレコードタイプです。
正式名称：
Resource Record Signature（リソース・レコード・シグネチャ）
読み方：
- RRSIG：アールアール・シグ、またはアールアールエス・アイ・ジー
- Resource Record Signature：リソース・レコード・シグネチャ
役割：
DNSレコードが改ざんされていないことを証明する電子署名です。
身近な例で理解しよう
契約書と実印：
紙の契約書：
契約書（本文）
↓
実印を押す（署名）
↓
印鑑証明書で本物か確認
↓
改ざんされていないことを証明DNS応答：
DNSレコード（example.com → 192.0.2.1）
↓
秘密鍵で署名（RRSIGレコード生成）
↓
公開鍵（DNSKEY）で検証
↓
改ざんされていないことを証明RRSIGは、「契約書に押された実印」のようなものなんです。
宅配便の伝票：
署名なし：
荷物を届ける
誰が送ったか不明
本物か偽物か分からない署名あり（RRSIG）：
荷物を届ける
送り主のサインがある（RRSIG）
本物と確認できる
安心して受け取れるRRSIGがあることで、DNS応答が本物だと確認できるんですね。
DNSSECとの関係
DNSSEC（DNS Security Extensions）の構成要素：
┌─────────────────────────────────┐
│ DNSSECの仕組み │
│ │
│ 1. DNSKEYレコード │
│ └─ 公開鍵を格納 │
│ │
│ 2. RRSIGレコード ★今回のテーマ │
│ └─ 電子署名を格納 │
│ │
│ 3. DSレコード │
│ └─ 信頼の連鎖 │
│ │
│ 4. NSEC/NSEC3レコード │
│ └─ 否定応答の証明 │
└─────────────────────────────────┘RRSIGは、DNSSECの中核となる「署名」部分を担当します。
DNSKEYとRRSIGの関係
前回の記事のおさらい：
秘密鍵（サーバー側に保管）
↓ 署名
RRSIGレコード（署名データ）
↓ 検証
公開鍵（DNSKEYレコードで公開）関係性：
- DNSKEY：公開鍵（検証に使う）
- RRSIG：署名データ（検証される）
- 秘密鍵：署名に使う（非公開）
DNSKEYとRRSIGは、ペアで機能するんです。
RRSIGの役割と重要性
何を守るのか
RRSIGが保護するもの：
1. DNS応答の完全性
DNS応答が改ざんされていないことを保証します。
例：
正規の応答：
example.com → 192.0.2.1
攻撃者が改ざん：
example.com → 198.51.100.1（偽のサーバー）
RRSIGで検証 → 改ざんを検出！2. DNS応答の真正性
DNS応答が本物の権威DNSサーバーから来たことを証明します。
3. DNS応答の非改変性
通信経路で誰も内容を変更していないことを保証します。
どんな攻撃を防ぐか
DNSキャッシュポイズニング攻撃：
通常の攻撃（RRSIGなし）：
攻撃者 → 偽のDNS応答を注入
↓
キャッシュDNSサーバーが偽の情報を保存
↓
ユーザーが偽サイトに誘導されるRRSIGによる防御：
攻撃者 → 偽のDNS応答を注入
↓
キャッシュDNSサーバーがRRSIGを検証
↓
署名が無効！偽の応答を拒否
↓
ユーザーは保護される中間者攻撃（Man-in-the-Middle）：
通信経路上で攻撃者がDNS応答を改ざんしても、RRSIGの検証で検出できます。
ドメインハイジャック：
不正にDNS設定を変更されても、正規のRRSIGがないため検出されます。
RRSIGレコードの構造
レコードフォーマット
RRSIGレコードの形式：
example.com. 3600 IN RRSIG <Type Covered> <Algorithm> <Labels> <Original TTL> <Signature Expiration> <Signature Inception> <Key Tag> <Signer's Name> <Signature>各フィールドの詳細説明：
1. Type Covered（対象レコードタイプ）：
どのレコードタイプに対する署名かを示します。
例：
A：Aレコードの署名AAAA：AAAAレコードの署名MX：MXレコードの署名DNSKEY：DNSKEYレコードの署名
2. Algorithm（アルゴリズム）：
使用した暗号化アルゴリズムの番号です。
主なアルゴリズム：
- 5：RSA/SHA-1
- 8：RSA/SHA-256
- 10：RSA/SHA-512
- 13：ECDSA Curve P-256 with SHA-256
- 15：Ed25519
3. Labels（ラベル数）：
ドメイン名のラベル数です。
例：
example.com.→ 2ラベルwww.example.com.→ 3ラベルmail.subdomain.example.com.→ 4ラベル
4. Original TTL（元のTTL）：
署名対象レコードの元のTTL値です。
5. Signature Expiration（署名有効期限）：
この署名がいつまで有効かを示すタイムスタンプです。
形式：YYYYMMDDHHmmSS
例：
20231215120000 → 2023年12月15日 12:00:006. Signature Inception（署名開始時刻）：
この署名がいつから有効かを示すタイムスタンプです。
7. Key Tag（鍵タグ）：
署名に使用したDNSKEYの識別子です。
例：
12345これにより、複数のDNSKEYがある場合でも、どの鍵で署名したか分かります。
8. Signer’s Name（署名者名）：
署名を行ったゾーンの名前です。
例：
example.com.9. Signature（署名データ）：
実際の電子署名データ（Base64エンコード）です。
実際のRRSIGレコード例
Aレコードの署名：
example.com. 3600 IN A 192.0.2.1
example.com. 3600 IN RRSIG A 8 2 3600 (
20231215120000 20231115120000 12345 example.com.
kRCOH5EnivgMEE8...（省略）...xpeFKmBJd
)解説：
- Type Covered:
A（Aレコードの署名） - Algorithm:
8（RSA/SHA-256） - Labels:
2（example.com = 2ラベル） - Original TTL:
3600 - Signature Expiration:
20231215120000（2023年12月15日） - Signature Inception:
20231115120000（2023年11月15日） - Key Tag:
12345 - Signer’s Name:
example.com. - Signature:
kRCOH5Eniv...（Base64エンコード）
DNSKEYレコードの署名：
example.com. 3600 IN DNSKEY 256 3 8 AwEAAb2H0...
example.com. 3600 IN DNSKEY 257 3 8 AwEAAcX7...
example.com. 3600 IN RRSIG DNSKEY 8 2 3600 (
20231215120000 20231115120000 54321 example.com.
A1B2C3D4E5F6...（省略）...G7H8I9J0
)解説：
- DNSKEYレコード自体も署名される（自己署名）
- Key Tag
54321は、KSKを指す
署名と検証の仕組み
署名の生成プロセス
ステップ1：DNSレコードの準備
example.com. 3600 IN A 192.0.2.1ステップ2：正規化（Canonical Form）
DNSレコードを標準形式に変換します。
正規化の内容：
- ドメイン名を小文字に統一
- TTLを含める
- 順序を整理
ステップ3：ハッシュ化
正規化されたデータをハッシュ関数（SHA-256など）で処理します。
Hash = SHA256(正規化されたDNSレコード)ステップ4：秘密鍵で署名
ハッシュ値を秘密鍵で暗号化します。
Signature = Encrypt(Hash, 秘密鍵)ステップ5：RRSIGレコードの生成
署名データと各種メタデータを組み合わせてRRSIGレコードを作成します。
RRSIG A 8 2 3600 20231215120000 20231115120000 12345 example.com. kRCOH5Eniv...検証のプロセス
ステップ1：DNS応答の受信
example.com. 3600 IN A 192.0.2.1
example.com. 3600 IN RRSIG A 8 2 3600 20231215120000 20231115120000 12345 example.com. kRCOH5Eniv...ステップ2：対応するDNSKEYの取得
Key Tag（12345）を使って、対応するDNSKEYレコードを取得します。
example.com. 3600 IN DNSKEY 256 3 8 AwEAAb2H0...ステップ3：DNSレコードの正規化
受信したDNSレコードを正規化します。
ステップ4：ハッシュ化
正規化されたデータをハッシュ化します。
Hash = SHA256(正規化されたDNSレコード)ステップ5：署名の復号化
公開鍵（DNSKEY）を使って、RRSIGの署名データを復号化します。
DecryptedHash = Decrypt(Signature, 公開鍵)ステップ6：ハッシュの比較
ステップ4で計算したハッシュと、ステップ5で復号化したハッシュを比較します。
Hash == DecryptedHash ?
↓
一致 → 検証成功！改ざんなし
不一致 → 検証失敗！改ざんありステップ7：有効期限の確認
現在時刻が、Signature InceptionとSignature Expirationの間にあるか確認します。
Signature Inception ≤ 現在時刻 ≤ Signature Expiration ?
↓
YES → 有効
NO → 期限切れすべてのチェックが成功すれば、DNS応答は本物です！
RRSIGの生成方法
BIND9での自動署名
設定ファイル（named.conf）：
zone "example.com" {
type master;
file "/etc/bind/example.com.zone";
auto-dnssec maintain;
inline-signing yes;
key-directory "/etc/bind/keys";
};説明：
- auto-dnssec maintain：自動でRRSIGを生成・更新
- inline-signing yes：動的に署名（元のゾーンファイルは変更しない）
- key-directory：鍵ファイルの場所
BINDが自動的にRRSIGを生成してくれます！
手動署名（dnssec-signzone）
コマンド：
dnssec-signzone -o example.com \
-k Kexample.com.+008+54321 \
example.com.zone \
Kexample.com.+008+12345パラメータ：
-o example.com：ゾーン名-k Kexample.com.+008+54321：KSK（鍵署名鍵）example.com.zone：元のゾーンファイルKexample.com.+008+12345：ZSK（ゾーン署名鍵）
出力：
example.com.zone.signedこのファイルには、元のDNSレコードに加えて、RRSIGレコードが含まれています。
生成されたゾーンファイルの例：
; 元のレコード
example.com. 3600 IN A 192.0.2.1
; RRSIGレコード（自動生成）
example.com. 3600 IN RRSIG A 8 2 3600 20231215120000 20231115120000 12345 example.com. kRCOH5Eniv...
; MXレコード
example.com. 3600 IN MX 10 mail.example.com.
; MXレコードのRRSIG
example.com. 3600 IN RRSIG MX 8 2 3600 20231215120000 20231115120000 12345 example.com. A1B2C3D4...
; DNSKEYレコード
example.com. 3600 IN DNSKEY 256 3 8 AwEAAb2H0...
example.com. 3600 IN DNSKEY 257 3 8 AwEAAcX7...
; DNSKEYのRRSIG
example.com. 3600 IN RRSIG DNSKEY 8 2 3600 20231215120000 20231115120000 54321 example.com. A1B2C3...すべてのレコードタイプに対して、RRSIGが生成されます。
PowerDNSでの設定
pdnsutilコマンド：
# ゾーンをDNSSEC化
pdnsutil secure-zone example.com
# 自動署名を有効化
pdnsutil set-meta example.com PRESIGNED 0
# 鍵のアルゴリズム指定
pdnsutil add-zone-key example.com ksk active 2048 rsasha256
pdnsutil add-zone-key example.com zsk active 2048 rsasha256PowerDNSが自動的にRRSIGを生成します。
RRSIGの有効期限と更新
有効期限の設定
推奨設定：
Signature Inception（開始時刻）：
現在時刻 - 1時間時刻のずれを考慮して、少し前から有効にします。
Signature Expiration（有効期限）：
現在時刻 + 30日1ヶ月程度が一般的です。
例：
現在：2023年11月15日 12:00
↓
Inception：2023年11月15日 11:00
Expiration：2023年12月15日 12:00自動更新の仕組み
BINDの自動更新（sig-validity-interval）：
named.confの設定：
options {
dnssec-validation auto;
sig-validity-interval 30 7;
};パラメータ：
- 30：RRSIGの有効期間（日数）
- 7：期限切れ前の再署名期間（日数）
動作：
RRSIGを生成（30日有効）
↓
23日経過（残り7日）
↓
自動的に再署名（新しいRRSIG生成）
↓
古いRRSIGと新しいRRSIGが両方存在
↓
古いRRSIGの期限切れ
↓
新しいRRSIGだけが残るシームレスに更新されます！
期限切れの影響
RRSIGが期限切れになると：
ユーザーがDNS問い合わせ
↓
期限切れのRRSIGを受信
↓
検証DNSサーバーが期限切れを検出
↓
SERVFAIL エラー
↓
Webサイトが表示されない！非常に深刻なので、自動更新が重要です。
RRSIGの検証方法
digコマンドでの確認
RRSIGレコードの取得：
dig @8.8.8.8 example.com A +dnssec出力例：
;; ANSWER SECTION:
example.com. 300 IN A 192.0.2.1
example.com. 300 IN RRSIG A 8 2 300 20231215120000 20231115120000 12345 example.com. kRCOH5Eniv...
;; ADDITIONAL SECTION:
example.com. 3600 IN DNSKEY 256 3 8 AwEAAb2H0...
example.com. 3600 IN RRSIG DNSKEY 8 2 3600 20231215120000 20231115120000 54321 example.com. A1B2C3...確認ポイント：
- RRSIGレコードが存在するか
- 有効期限が切れていないか
- DNSKEYレコードがあるか
delvコマンドでの検証
DNSSEC検証専用ツール：
delv @8.8.8.8 example.com A +rtrace成功時の出力：
; fully validated
example.com. 300 IN A 192.0.2.1
example.com. 300 IN RRSIG A 8 2 300 20231215120000 20231115120000 12345 example.com. kRCOH5Eniv...fully validatedが表示されれば、RRSIGの検証に成功しています。
失敗時の出力：
; broken trust chain resolving 'example.com/A/IN'検証に失敗した理由が表示されます。
オンライン検証ツール
Verisign DNSSEC Debugger：
使い方：
- ドメイン名を入力（例：example.com）
- 「Analyze」をクリック
- 各ステップの検証結果が表示される
正常な場合：
✓ RRSIG for example.com/A found
✓ Signature verified
✓ Within validity period問題がある場合：
✗ RRSIG not found
✗ Signature verification failed
✗ Expired signature具体的なエラー内容が表示されます。
DNSViz：
視覚的に信頼の連鎖とRRSIGの検証状態が確認できます。
実践例：RRSIGの動作確認
例1：正常なRRSIG
コマンド：
dig @8.8.8.8 cloudflare.com A +dnssec +multiline出力（一部）：
;; ANSWER SECTION:
cloudflare.com. 300 IN A 104.16.132.229
cloudflare.com. 300 IN A 104.16.133.229
cloudflare.com. 300 IN RRSIG A 13 2 300 (
20231130181429 20231128161429 34505 cloudflare.com.
A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5P6Q7R8S9T0U1V2W3
X4Y5Z6... )確認できること：
- Aレコードの応答
- 対応するRRSIGレコード
- 署名の有効期限
例2：RRSIGの検証
検証プロセスの確認：
delv @1.1.1.1 cloudflare.com A +rtrace +multiline出力（簡略化）：
; fetch: cloudflare.com/A
; fetch: cloudflare.com/DNSKEY
; validating cloudflare.com/A: attempting positive response validation
; validating cloudflare.com/A: verify rdataset (keyid=34505): success
; validating cloudflare.com/A: signed by trusted key; marking as secure
; fully validated
cloudflare.com. 300 IN A 104.16.132.229
cloudflare.com. 300 IN A 104.16.133.229検証ステップ：
- Aレコードを取得
- DNSKEYレコードを取得
- RRSIGを検証（keyid=34505を使用）
- 検証成功（success）
- 信頼できるとマーク（marked as secure）
例3：期限切れのRRSIG
シミュレーション（テスト環境）：
RRSIG A 8 2 300 20231101000000 20231001000000 12345 example.com. ...
^^^^^^^^^^^^^^^^
既に過去の日付検証結果：
delv @1.1.1.1 example.com A出力：
; broken trust chain resolving 'example.com/A/IN': expired signatureエラー：署名が期限切れ
RRSIGのベストプラクティス
推奨設定
1. 適切な有効期間
推奨値：
- 有効期間：30日
- 再署名のタイミング：期限切れ7日前
設定例（BIND）：
sig-validity-interval 30 7;2. 強力なアルゴリズム
推奨アルゴリズム：
- ECDSA P-256（アルゴリズム13）：軽量で高速
- Ed25519（アルゴリズム15）：最新、高セキュリティ
避けるべき：
- RSA/SHA-1（アルゴリズム5）：古い、脆弱
3. 自動署名の有効化
手動署名は忘れるリスクがあるため、必ず自動化します。
BIND：
auto-dnssec maintain;
inline-signing yes;PowerDNS：
pdnsutil rectify-zone example.com4. 監視とアラート
RRSIGの有効期限を監視して、期限切れ前にアラートを出します。
監視項目：
- RRSIGの存在確認
- 有効期限のチェック
- 検証の成功/失敗
セキュリティのポイント
1. 秘密鍵の保護
RRSIGを生成する秘密鍵は、厳重に管理します。
保護方法：
- ファイルパーミッション：600（所有者のみ読み書き可）
- ディレクトリパーミッション：700
- HSM（Hardware Security Module）の使用（大規模環境）
2. 定期的な鍵ローテーション
推奨頻度：
- ZSK：1〜3ヶ月
- KSK：1〜2年
鍵を交換することで、万が一の漏洩リスクを軽減します。
3. 時刻同期
RRSIGの有効期限チェックには、正確な時刻が必要です。
NTPで時刻同期：
sudo apt install ntp
sudo systemctl enable ntp
sudo systemctl start ntp4. バックアップ
秘密鍵とゾーンファイルは、定期的にバックアップします。
トラブルシューティング
問題1：RRSIGが見つからない
症状：
dig example.com A +dnssecRRSIGレコードが返ってこない。
原因：
- DNSSECが有効化されていない
- 署名が失敗している
- DNSサーバーの設定ミス
解決策：
1. DNSSECの有効化を確認：
# BIND
grep "auto-dnssec" /etc/bind/named.conf
# PowerDNS
pdnsutil check-zone example.com2. 署名の実行：
# BIND（手動）
dnssec-signzone -o example.com example.com.zone Kexample.com.+008+12345
# PowerDNS
pdnsutil rectify-zone example.com3. サーバーの再起動：
sudo systemctl restart bind9
# または
sudo systemctl restart pdns問題2：署名の検証が失敗する
症状：
delv example.com A
; broken trust chain resolving 'example.com/A/IN': signature verification failed原因：
- RRSIGとDNSレコードの不一致
- 秘密鍵と公開鍵のミスマッチ
- DNSレコードが署名後に変更された
解決策：
1. 再署名：
dnssec-signzone -o example.com example.com.zone Kexample.com.+008+123452. 鍵の確認：
# 秘密鍵と公開鍵のペアが正しいか確認
dnssec-verify -o example.com example.com.zone.signed3. DNSKEYの確認：
dig example.com DNSKEY公開鍵が正しく公開されているか確認します。
問題3：RRSIGの期限切れ
症状：
; broken trust chain resolving 'example.com/A/IN': expired signature原因：
- 自動更新が機能していない
- 手動署名を忘れた
- 時刻のずれ
解決策：
1. 即座に再署名：
dnssec-signzone -o example.com example.com.zone Kexample.com.+008+12345
sudo systemctl reload bind92. 自動更新の設定確認：
# named.conf
sig-validity-interval 30 7;
auto-dnssec maintain;3. 時刻同期の確認：
timedatectl statusNTPが正しく動作しているか確認します。
問題4：パフォーマンスの問題
症状：
DNS応答が遅い。
原因：
- 大量のRRSIGレコード
- 署名生成の負荷
- 検証の負荷
解決策：
1. 軽量なアルゴリズムを使用：
RSAからECDSA（アルゴリズム13）に変更します。
2. サーバースペックの向上：
CPU/メモリを増強します。
3. キャッシュDNSの活用：
検証済みの結果をキャッシュします。
問題5：DS レコードとの不整合
症状：
; broken trust chain resolving 'example.com/A/IN': no valid DNSKEY原因：
親ゾーンのDSレコードとDNSKEYが一致していない。
解決策：
1. DSレコードの生成：
dnssec-dsfromkey Kexample.com.+008+54321.key2. 親ゾーン（レジストラ）に登録：
生成されたDSレコードをレジストラの管理画面で登録します。
3. 確認：
dig @8.8.8.8 example.com DSDSレコードが正しく公開されているか確認します。
よくある質問
Q1: すべてのDNSレコードにRRSIGが必要？
A: はい、DNSSECを有効にすると、すべてのレコードタイプにRRSIGが生成されます。
対象レコード：
- A、AAAA
- MX、NS
- CNAME、TXT
- DNSKEY自体
例外：
RRSIG自体には、RRSIGは付きません（無限ループを防ぐため）。
Q2: RRSIGは誰でも見られる？
A: はい、公開情報です。
RRSIGは、DNSの公開レコードなので、誰でも取得できます。
秘密情報は含まれていません：
- 公開鍵（DNSKEY）で検証できるように設計されている
- 秘密鍵は、サーバー側だけが保持
Q3: RRSIGのサイズはどのくらい？
A: アルゴリズムによります。
サイズ例：
- RSA 2048ビット：約256バイト
- ECDSA P-256：約64バイト
- Ed25519：約64バイト
ECDSAやEd25519の方が軽量です。
Q4: RRSIGが原因でDNSパケットが大きくなる？
A: はい、増加します。
影響：
- UDP/512バイトを超える場合がある
- EDNS0（拡張DNS）が必要
- 場合によっては、TCPにフォールバック
対策：
- 軽量なアルゴリズム（ECDSA）を使用
- DNSレコード数を減らす
Q5: CloudflareやRoute 53を使っている場合、RRSIGは自動？
A: はい、自動的に生成・管理されます。
Cloudflare：
DNSSECを有効化すると、自動でRRSIGが生成されます。
Route 53：
DNSSEC signingを有効化すると、AWSが自動管理します。
ユーザーは、RRSIGを意識する必要がありません。
まとめ
RRSIG（Resource Record Signature）は、DNSレコードに対する電子署名で、DNS応答が本物であり改ざんされていないことを証明する、DNSSECの核心技術です。
この記事のポイント：
- RRSIGはDNSレコードの電子署名
- 秘密鍵で署名、公開鍵（DNSKEY）で検証
- すべてのレコードタイプに対して生成される
- 有効期限があり、定期的な更新が必要
- 自動署名の設定が推奨される
- digやdelvコマンドで検証可能
- DNSキャッシュポイズニングや改ざんを防ぐ
- 期限切れに注意（サイトが表示されなくなる）
- CloudflareやRoute 53では自動管理される
- ECDSAやEd25519が軽量で推奨される
RRSIGは、インターネットのセキュリティを根本から強化する重要な技術です。DNSKEYとペアで機能し、DNS応答の完全性と真正性を保証します。
設定は少し複雑ですが、自動署名を有効にすれば、ほぼ手間なく運用できます。CloudflareやRoute 53などのマネージドDNSサービスを使えば、さらに簡単です。
特に、金融機関、電子商取引サイト、セキュリティが重要なサービスでは、DNSSECとRRSIGの導入を強く推奨します。ユーザーを偽サイトから守り、信頼性を高めることができますよ。
RRSIGとDNSSECをマスターして、より安全なインターネットを実現していきましょう！
コメント