NSEC/NSEC3とは？DNSSECで「存在しない」を証明する技術を徹底解説

「DNSの応答が本物かどうか、どうやって確認すればいいの？」

「DNSキャッシュポイズニング攻撃から守る方法は？」

こうした問題を解決するのが、DNSSEC（DNS Security Extensions）という技術です。

そして、その中核を担うのがNSEC（Next Secure）とNSEC3というレコードタイプ。これらは「存在しないドメインが確かに存在しない」ことを証明する、独特な役割を持っています。

この記事では、NSEC/NSEC3レコードについて、DNSSECの基礎から実装まで、初心者にも理解できるよう丁寧に解説します。

少し高度な内容ですが、一つずつ見ていけば理解できますよ。

DNSSECの基本：なぜ必要なのか？
なぜNSEC/NSEC3が必要？「存在しない」の証明
NSECレコードの仕組み
NSEC3レコードの仕組み
NSECとNSEC3の比較
NSEC3のオプトアウト機能
DNSSECとNSEC/NSEC3の実装
NSEC/NSEC3の確認方法
トラブルシューティング
よくある質問（Q&A）
まとめ：DNSSECとNSEC/NSEC3で安全なDNSを

DNSSECの基本：なぜ必要なのか？

NSEC/NSEC3を理解するには、まずDNSSECの基本を知る必要があります。

従来のDNSの問題点

通常のDNSには、セキュリティ上の大きな問題があります。

問題1：応答の真正性が確認できない

DNSの問い合わせと応答は、暗号化されておらず、署名もありません。

そのため、以下のような攻撃が可能です：

DNSスプーフィング：偽の応答を送りつける
キャッシュポイズニング：DNSキャッシュサーバーに偽の情報を注入
中間者攻撃：通信を傍受して改ざん

問題2：データの完全性が保証されない

応答が途中で改ざんされても、検出する方法がありません。

問題3：送信元の認証ができない

応答が本当に正規の権威DNSサーバーから来たのか、確認できません。

DNSSECの登場

DNSSEC（DNS Security Extensions）は、これらの問題を解決するために開発されました。

DNSSECの仕組み

DNSSECは、公開鍵暗号を使って、DNSレコードにデジタル署名を追加します。

署名の作成：権威DNSサーバーが秘密鍵でレコードに署名
署名の配布：署名（RRSIGレコード）とともにレコードを配布
署名の検証：受信側が公開鍵（DNSKEYレコード）で署名を検証

DNSSECの効果

真正性の保証：応答が改ざんされていないことを確認
送信元の認証：正規の権威サーバーからの応答であることを確認
完全性の保証：データが途中で変更されていないことを確認

ただし、DNSSECは暗号化ではありません。通信内容は依然として平文です。

DNSSECで追加されるレコードタイプ

DNSSECを有効にすると、以下の新しいレコードタイプが追加されます。

RRSIG：各レコードのデジタル署名
DNSKEY：公開鍵
DS（Delegation Signer）：子ゾーンの公開鍵のハッシュ
NSEC / NSEC3：存在しないドメインの証明（本記事の主題）

なぜNSEC/NSEC3が必要？「存在しない」の証明

ここからが本題です。

「存在の証明」は簡単

ドメインが存在することを証明するのは簡単です。

例えば、www.example.comが存在することを示すには、そのAレコードと署名を返せばいいだけ。

www.example.com.  IN  A      192.0.2.1
www.example.com.  IN  RRSIG  A 7 3 3600 ...（署名データ）

「存在しない」の証明は難しい

問題は、ドメインが存在しないことを証明する場合です。

例えば、nonexistent.example.comという存在しないドメインを問い合わせたとき：

通常のDNS：

「そんなドメインはありません」という応答（NXDOMAIN）が返ります。

でも、この応答に署名を付けることはできません。なぜなら、存在しないドメインのレコードに署名するという概念が矛盾しているから。

DNSSECの課題：

「存在しないドメインへの応答」をどうやって認証するか？

偽のNXDOMAIN応答を送られても、それが正しいかどうか判断できません。

NSECとNSEC3の役割

NSEC（Next Secure）とNSEC3は、この問題を解決します。

「このドメインは存在しない」と直接証明するのではなく、「このドメインとこのドメインの間には何も存在しない」という範囲を証明します。

まるで辞書のように、「aardvark（ツチブタ）の次はabacus（そろばん）で、その間には何もありませんよ」と証明するイメージです。

NSECレコードの仕組み

NSECは、DNSSECで最初に導入された方式です。

NSECレコードとは

NSEC（Next Secure）レコードは、次に存在するドメイン名を指し示します。

基本的な構造

owner-name  IN  NSEC  next-domain-name  types

owner-name：現在のドメイン名
next-domain-name：次に存在するドメイン名
types：このドメインに存在するレコードタイプのリスト

具体例で理解する

ゾーンexample.comに以下のドメインがあるとします：

example.com
a.example.com
b.example.com
z.example.com

NSECレコードの例

example.com.    IN  NSEC  a.example.com.  A NS SOA MX RRSIG NSEC DNSKEY
a.example.com.  IN  NSEC  b.example.com.  A RRSIG NSEC
b.example.com.  IN  NSEC  z.example.com.  A RRSIG NSEC
z.example.com.  IN  NSEC  example.com.    A RRSIG NSEC

読み方：

example.comの次はa.example.com
a.example.comの次はb.example.com
b.example.comの次はz.example.com
z.example.comの次はexample.com（循環）

存在しないドメインの証明

c.example.comという存在しないドメインを問い合わせた場合：

b.example.comのNSECレコードが返される
このレコードは「次はz.example.com」と示している
つまり、bとzの間には何も存在しない
したがって、c.example.comは存在しない

証明の流れ：

b.example.com < c.example.com < z.example.com

b.example.comのNSECレコード：
"次はz.example.comです（間には何もありません）"

これで、c.example.comが存在しないことが証明されました。

NSECレコードの署名

NSECレコード自体も、RRSIGレコードで署名されます。

b.example.com.  IN  NSEC   z.example.com. A RRSIG NSEC
b.example.com.  IN  RRSIG  NSEC 7 3 3600 ...（署名データ）

これにより、NSEC レコード自体が改ざんされていないことも保証されます。

NSECの問題点：ゾーンウォーキング

NSECには、重大なプライバシー問題があります。

ゾーンウォーキング攻撃

NSECレコードを辿ることで、ゾーン内のすべてのドメイン名を列挙できてしまいます。

攻撃手順：

example.comのNSECを取得 → 次はa.example.com
a.example.comのNSECを取得 → 次はb.example.com
b.example.comのNSECを取得 → 次はz.example.com
…繰り返す

これにより、攻撃者は以下の情報を得られます：

すべてのサブドメイン名
サーバーの命名規則
ネットワーク構成のヒント
攻撃対象の候補

例：

企業がdev.example.com、staging.example.com、admin.example.comのような内部用サブドメインを持っている場合、これらがすべて露呈します。

NSECのメリットとデメリット

メリット

シンプル：仕組みが分かりやすい
効率的：検証が高速
レスポンスサイズが小さい

デメリット

ゾーンウォーキング攻撃が可能：最大の問題点
プライバシーの欠如：すべてのドメイン名が列挙可能
セキュリティリスク：攻撃者に情報を提供

NSEC3レコードの仕組み

NSEC3は、NSECの問題点を改善した新しい方式です。

NSEC3レコードとは

NSEC3（Next Secure version 3）は、ドメイン名をハッシュ化してからチェーンを構築します。

基本的な考え方

ドメイン名を直接使う代わりに、暗号学的ハッシュ関数（SHA-1など）でハッシュ化します。

example.com → ハッシュ化 → 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom

このハッシュ値を使ってNSECと同様のチェーンを構築します。

NSEC3レコードの構造

hashed-owner-name  IN  NSEC3  hash-algorithm flags iterations salt next-hashed-name types

hash-algorithm：ハッシュアルゴリズム（通常は1 = SHA-1）
flags：オプトアウトフラグ（通常は0）
iterations：ハッシュの繰り返し回数
salt：ソルト（ランダムな値）
next-hashed-name：次のハッシュ値
types：存在するレコードタイプ

具体例で理解する

同じゾーンexample.comで、NSEC3を使った場合：

; example.comのハッシュ
0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example.com.  IN  NSEC3  1 0 10 AABBCCDD 2t7b4g4vsa5smi47k61mv5bv1a22bojr A NS SOA RRSIG DNSKEY NSEC3PARAM

; a.example.comのハッシュ
2t7b4g4vsa5smi47k61mv5bv1a22bojr.example.com.  IN  NSEC3  1 0 10 AABBCCDD 8fbr9mub68v8mgc8qt8gn82huk4ujko0 A RRSIG

; b.example.comのハッシュ
8fbr9mub68v8mgc8qt8gn82huk4ujko0.example.com.  IN  NSEC3  1 0 10 AABBCCDD r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG

; z.example.comのハッシュ
r53bq7cc2uvmubfu5ocmm6pers9tk9en.example.com.  IN  NSEC3  1 0 10 AABBCCDD 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom A RRSIG

パラメータの説明：

1：SHA-1を使用
0：フラグ（オプトアウトなし）
10：ハッシュを10回繰り返す
AABBCCDD：ソルト（16進数）

ハッシュの計算方法

NSEC3のハッシュは、以下の手順で計算されます：

ドメイン名を小文字に変換
ソルトを追加
SHA-1でハッシュ化
これを指定回数（iterations）繰り返す
Base32でエンコード

疑似コード：

hash = SHA-1(domain_name + salt)
for i = 1 to iterations:
    hash = SHA-1(hash + salt)
result = Base32(hash)

存在しないドメインの証明（NSEC3版）

c.example.comが存在しないことを証明する場合：

c.example.comをハッシュ化
計算されたハッシュ値：a1b2c3d4...（仮）
このハッシュ値を含む範囲のNSEC3レコードを探す
例えば、8fbr...とr53b...の間にハッシュ値がある場合
その範囲のNSEC3レコードが返される
ハッシュ値が範囲内にあるが、実際のレコードは存在しない
したがって、c.example.comは存在しない

ゾーンウォーキング攻撃への対策

NSEC3では、ドメイン名がハッシュ化されているため、簡単には元の名前を知ることができません。

攻撃者の視点：

NSEC3レコードを辿ることはできる
しかし、ハッシュ値から元のドメイン名を復元するのは困難
総当たり攻撃（ブルートフォース）は可能だが、時間がかかる

注意：

NSEC3は完璧ではありません。以下の場合、攻撃は可能です：

辞書攻撃：一般的なサブドメイン名をハッシュ化して照合
高速なハッシュ計算：iterations（繰り返し回数）が少ない場合
ソルトなし：同じドメイン名は常に同じハッシュになる

そのため、適切なiterations値（10〜150）とランダムなソルトの使用が推奨されます。

NSEC3PARAMレコード

NSEC3を使用する場合、NSEC3PARAMレコードも必要です。

example.com.  IN  NSEC3PARAM  1 0 10 AABBCCDD

このレコードは、ゾーン全体で使用されるNSEC3のパラメータ（アルゴリズム、フラグ、iterations、ソルト）を定義します。

NSECとNSEC3の比較

2つの方式を比較してみましょう。

比較表

項目	NSEC	NSEC3
ゾーンウォーキング	容易	困難（完全には防げない）
プライバシー	低い	高い
レスポンスサイズ	小さい	やや大きい
計算負荷	低い	高い（ハッシュ計算が必要）
検証速度	速い	やや遅い
実装の複雑さ	シンプル	複雑
標準化	RFC 4034, 4035	RFC 5155

どちらを選ぶべき？

NSEC3を推奨：

現代のDNSSEC実装では、NSEC3の使用が推奨されています。

理由：

プライバシー保護
ゾーンウォーキング攻撃への耐性
セキュリティ強化

NSECが適している場合：

プライバシーが問題にならない（公開情報のみ）
低リソース環境（組み込みシステムなど）
シンプルさを優先

NSEC3のパラメータ選択

NSEC3を使う場合、適切なパラメータ設定が重要です。

Iterations（繰り返し回数）

推奨値：

一般的な用途：10〜50
高セキュリティ：50〜150
極端に高い値は避ける：検証に時間がかかりすぎる

2024年の推奨（RFC 9276）：

RSA-2048/SHA-256の場合：最大100
ECDSA-P256/SHA-256の場合：最大50

Salt（ソルト）

推奨：

8〜16バイトのランダムな値
定期的に変更（年に1回程度）

空のソルト：

セキュリティは下がりますが、キャッシュ効率が上がります。

近年は、空のソルト（-）を使用することも推奨されています（RFC 9276）。

NSEC3のオプトアウト機能

NSEC3には、特殊な「オプトアウト」機能があります。

オプトアウトとは

大規模なゾーンで、一部のドメイン（特に委譲されたサブドメイン）に対してNSEC3レコードを作成しないオプションです。

背景

大企業や大学では、数万〜数百万のサブドメインが存在することがあります。

すべてにNSEC3レコードと署名を作成すると：

ゾーンファイルが巨大になる
署名の更新に時間がかかる
サーバーのリソースを大量に消費

オプトアウトの仕組み

フラグビットを1に設定すると、そのNSEC3レコードは「委譲されたゾーン」をカバーしません。

hash.example.com.  IN  NSEC3  1 1 10 AABBCCDD next-hash NS
                                 ↑
                                フラグ=1（オプトアウト）

オプトアウトの影響

メリット：

ゾーンのサイズが小さくなる
署名の更新が速くなる

デメリット：

委譲されたサブドメインの「存在しない」証明ができない
セキュリティが若干低下

使用例：

大学の.eduドメインや、大企業のグループドメインなど、大量の委譲が発生する場合。

DNSSECとNSEC/NSEC3の実装

実際にDNSSECを有効にする方法を見ていきましょう。

必要な準備

DNSSECに対応したDNSサーバー：BIND、PowerDNS、Knot DNSなど
鍵の生成：秘密鍵と公開鍵のペア
ゾーンへの署名：すべてのレコードに署名を追加
DSレコードの登録：親ゾーン（レジストラ）に登録

BINDでのNSEC3設定例

ステップ1：鍵の生成

# ZSK（Zone Signing Key）の生成
dnssec-keygen -a RSASHA256 -b 2048 -n ZONE example.com

# KSK（Key Signing Key）の生成
dnssec-keygen -a RSASHA256 -b 4096 -f KSK -n ZONE example.com

ステップ2：NSEC3パラメータの設定

ゾーンファイルに追加：

example.com.  IN  NSEC3PARAM  1 0 10 AABBCCDD

または、dnssec-signzoneコマンドで指定：

dnssec-signzone -3 AABBCCDD -H 10 -o example.com zone.file

パラメータの説明：

-3 AABBCCDD：ソルト（16進数）
-H 10：iterations（繰り返し回数）
-o example.com：ゾーン名

ステップ3：ゾーンへの署名

dnssec-signzone -3 AABBCCDD -H 10 -o example.com -K /path/to/keys zone.file

これにより、署名済みゾーンファイル（zone.file.signed）が生成されます。

ステップ4：BIND設定ファイルの更新

zone "example.com" {
    type master;
    file "/var/named/zone.file.signed";
    auto-dnssec maintain;
    inline-signing yes;
};

ステップ5：BINDの再読み込み

rndc reload example.com

自動署名の設定

BINDのauto-dnssec機能を使えば、自動的に署名を更新できます。

zone "example.com" {
    type master;
    file "/var/named/zone.file";
    auto-dnssec maintain;
    inline-signing yes;
    key-directory "/var/named/keys";
};

DSレコードの登録

生成されたDSレコードを、レジストラ（ドメイン登録業者）の管理画面で登録します。

DSレコードの取得

dnssec-dsfromkey Kexample.com.+008+12345.key

出力例：

example.com. IN DS 12345 8 2 A1B2C3D4E5F6...

このDSレコードを、親ゾーン（.comの管理者）に登録することで、信頼の連鎖が確立されます。

NSEC/NSEC3の確認方法

設定が正しく機能しているか確認しましょう。

digコマンドでの確認

NSECレコードの確認

dig @8.8.8.8 nonexistent.example.com +dnssec

存在しないドメインを問い合わせると、NSECレコードが返されます。

NSEC3レコードの確認

dig @8.8.8.8 example.com NSEC3PARAM +short

NSEC3が有効な場合、パラメータが表示されます。

dig @8.8.8.8 example.com NSEC3 +dnssec

NSEC3レコードのリストが表示されます。

DNSSECの検証

検証を有効にして問い合わせ

dig @8.8.8.8 example.com +dnssec +multiline

adフラグ（Authenticated Data）が立っていれば、検証成功です。

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
          ↑↑
          ad フラグ

オンラインツール

Verisign DNSSEC Debugger（https://dnssec-debugger.verisignlabs.com/）：

ドメイン名を入力するだけ
DNSSECの設定状況を詳細に表示
エラーがあれば原因を説明

delv（Domain Entity Lookup & Validation）

BINDに含まれる検証専用ツールです。

delv @8.8.8.8 example.com

DNSSECの検証プロセスを詳細に表示します。

トラブルシューティング

よくある問題と解決方法です。

問題1：DNSSEC検証が失敗する

症状

SERVFAILエラーが返される。

原因

署名が期限切れ
DSレコードが正しくない
鍵のローテーションに失敗

解決策

署名の有効期限を確認
DSレコードが親ゾーンに正しく登録されているか確認
ゾーンを再署名

問題2：NSEC3のiterations値が高すぎる

症状

検証に時間がかかる、タイムアウトする。

解決策

iterations値を下げる（10〜50程度に）。

dnssec-signzone -3 AABBCCDD -H 10 -o example.com zone.file

問題3：ゾーンウォーキングができてしまう

症状

NSEC3を使っているのに、ドメイン名が列挙できる。

原因

iterations値が低すぎる
ソルトが設定されていない
辞書攻撃に弱い命名規則

解決策

iterations値を増やす（50程度）
ランダムなソルトを使用
予測しにくいサブドメイン名を使用

よくある質問（Q&A）

NSEC/NSEC3について、よくある質問にお答えします。

Q1：DNSSECは必須？

A：必須ではありませんが、推奨されます。

特に以下の場合は重要：

金融機関、政府機関
オンラインショッピングサイト
重要なインフラ

個人のブログなどでは、必須ではありません。

Q2：NSECとNSEC3、どちらが良い？

A：NSEC3を推奨します。

プライバシー保護の観点から、NSEC3の方が優れています。

ただし、パフォーマンスが重要な場合や、プライバシーが問題にならない場合は、NSECでも問題ありません。

Q3：NSEC3で完全にゾーンウォーキングを防げる？

A：いいえ、完全には防げません。

辞書攻撃やブルートフォース攻撃は可能です。

ただし、NSECに比べて格段に困難になります。

Q4：DNSSECでDNS通信は暗号化される？

A：いいえ、暗号化されません。

DNSSECは「署名」であり、「暗号化」ではありません。

通信内容は平文のままです。

DNS通信を暗号化したい場合は、DNS over HTTPS（DoH）やDNS over TLS（DoT）を使用してください。

Q5：DSレコードとは何？

A：親ゾーンに登録する、子ゾーンの公開鍵のハッシュです。

DNSSECの信頼の連鎖（Chain of Trust）を確立するために必要です。

DSレコードがないと、DNSSECの検証ができません。

Q6：署名の有効期限はどれくらい？

A：通常は1ヶ月程度です。

有効期限が切れる前に、自動的に再署名する設定が推奨されます。

BINDのauto-dnssec maintain機能を使えば、自動化できます。

Q7：小規模サイトでもDNSSECは必要？

A：必須ではありませんが、検討する価値があります。

メリット：

セキュリティ向上
信頼性の向上
将来を見据えた対応

デメリット：

設定と管理が複雑
サーバーリソースを消費
トラブルシューティングが難しい

まとめ：DNSSECとNSEC/NSEC3で安全なDNSを

NSEC/NSEC3について、理解できましたか？

この記事の重要ポイント：

DNSSECはDNSのセキュリティを強化する技術
NSECは「次のドメイン」を示して存在しないことを証明
NSEC3はドメイン名をハッシュ化してプライバシーを保護
ゾーンウォーキング攻撃への対策としてNSEC3が有効
NSEC3のiterations値とソルトが重要
完全な防御は不可能だが、NSEC3で大幅に改善
実装にはDNSSEC対応サーバーと適切な設定が必要
DSレコードの登録で信頼の連鎖を確立

DNSSECとNSEC/NSEC3は、インターネットのセキュリティを支える重要な技術です。

設定は少し複雑ですが、一度理解すれば、より安全なDNS運用が可能になります。

この記事を参考に、DNSSECの導入を検討してみてくださいね！