NSEC / NSEC3

概要

NSEC（Next Secure） と NSEC3（Next Secure version 3） は、DNSSEC において「レコードが存在しない」ことを署名付きで証明するリソースレコードです。NSEC は RFC 4034（2005年）で、NSEC3 は RFC 5155（2008年）で定義されています。

DNSSEC は DNS 応答にデジタル署名を付与してデータの完全性を保証しますが、存在するレコードへの署名だけでは不十分です。攻撃者がリゾルバーに「レコードは存在しない」という偽の応答を返した場合、その応答の正当性を検証する手段がなければ、正規の DNS レコードを隠蔽できてしまいます。NSEC / NSEC3 は「存在しないこと」に対しても署名を付与し、否定応答の改ざんを防ぎます。この仕組みを「認証付き不在証明（Authenticated Denial of Existence）」と呼びます。

NSEC はシンプルな設計ですが、ゾーン内のすべてのレコード名を列挙できる「ゾーンウォーキング」という副作用があります。NSEC3 はレコード名をハッシュ化することでこの問題を軽減しました。

仕組み

NSEC はゾーン内のレコード名を辞書順チェーンで証明し、NSEC3 はハッシュ化によってゾーンウォーキングを防止する改良を加えています。

NSEC の動作

NSEC はゾーン内のレコード名を辞書順（正規順序）に並べ、各名前から「次の名前」へのポインターを署名付きで保持します。

ゾーン内のレコード名（辞書順）:
  alpha.example.com.
  beta.example.com.
  gamma.example.com.

NSEC チェーン:
  alpha.example.com.  NSEC  beta.example.com.   A RRSIG NSEC
  beta.example.com.   NSEC  gamma.example.com.  A MX RRSIG NSEC
  gamma.example.com.  NSEC  alpha.example.com.  A TXT RRSIG NSEC
                            ↑ 最後は先頭に戻る（循環リスト）

bravo.example.com を問い合わせた場合、権威サーバーは「alpha.example.com の次は beta.example.com であり、その間にレコードは存在しない」ことを NSEC レコードで証明します。この NSEC レコードには RRSIG が付いているため、リゾルバーは署名を検証して否定応答が改ざんされていないことを確認できます。

NSEC レコードの最後のフィールド（A RRSIG NSEC の部分）はタイプビットマップと呼ばれ、その名前に存在するレコードタイプの一覧を示します。タイプビットマップを参照することで、NODATA 応答（ドメインは存在するが要求したレコードタイプが存在しない場合）も証明できます。

ゾーンウォーキングの問題

NSEC の「次の名前」へのポインターを順に辿ると、ゾーン内の全レコード名を列挙できます。

問い合わせ: aaa.example.com → NSEC で alpha.example.com を得る
問い合わせ: alpha1.example.com → NSEC で beta.example.com を得る
問い合わせ: beta1.example.com → NSEC で gamma.example.com を得る
...

この手法をゾーンウォーキングと呼びます。ゾーン内のサブドメイン一覧が取得されることは、セキュリティ上好ましくない場合があります。社内システムのサブドメイン名（staging.example.com、admin.example.com など）が外部に漏洩するリスクがあります。

NSEC3 の動作

NSEC3 はレコード名を暗号学的ハッシュ関数（SHA-1）で変換してから辞書順に並べます。

元のレコード名          ハッシュ値（SHA-1）
alpha.example.com.  →  1AVVQN7F1NR6ER8BST...
beta.example.com.   →  8N2FJO7DI7M2U3O7B...
gamma.example.com.  →  T3RGK2Q7L...

NSEC3 チェーン（ハッシュ値の辞書順）:
  1AVVQN7F...  NSEC3  8N2FJO7D...   A RRSIG
  8N2FJO7D...  NSEC3  T3RGK2Q7...   A MX RRSIG
  T3RGK2Q7...  NSEC3  1AVVQN7F...   A TXT RRSIG

ハッシュ値から元のレコード名を逆算することは困難（計算量的に非現実的）なため、ゾーンウォーキングによるレコード名の列挙が防止されます。ただし、辞書攻撃（一般的なサブドメイン名のハッシュを事前に計算して照合する手法）には脆弱です。

NSEC3 のパラメーター

NSEC3 レコードにはハッシュの設定パラメーターが含まれます。

example.com.  IN  NSEC3PARAM  1 0 10 AABBCCDD

フィールド	内容
1	ハッシュアルゴリズム（1 = SHA-1）
0	フラグ（0 = Opt-Out なし）
10	追加イテレーション回数
AABBCCDD	ソルト（ハッシュ計算に使う固定値）

RFC 9276（2022年）は NSEC3 のパラメーター設定に関する最新のガイダンスを提供しています。この RFC では、追加イテレーション回数を 0 に、ソルトを空（-）にすることを推奨しています。イテレーション回数を増やしても辞書攻撃への耐性向上は限定的で、権威サーバーの負荷だけが増加するためです。

NSEC3 Opt-Out

RFC 5155 は「Opt-Out」フラグも定義しています。Opt-Out が有効な場合、DNSSEC 未署名の委任（Insecure Delegation）を NSEC3 チェーンから除外できます。.com のような大規模 TLD ゾーンでは、署名されていないドメインが大多数を占めるため、Opt-Out でゾーンサイズと署名コストを削減できます。

Opt-Out のデメリットは、未署名の委任に対する不在証明が提供されない点です。攻撃者が未署名のドメインの存在を偽装できるリスクがあります。

確認方法

dig コマンドで存在しないドメインを問い合わせると、NSEC または NSEC3 レコードが AUTHORITY SECTION に返ります。

# 存在しないサブドメインを問い合わせ、NSEC/NSEC3 を確認
dig A nonexistent.example.com +dnssec

;; AUTHORITY SECTION:
example.com.		300	IN	SOA	ns1.example.com. admin.example.com. ...
1AVVQN7F...example.com.  300  IN  NSEC3  1 0 0 - 8N2FJO7D... A RRSIG
1AVVQN7F...example.com.  300  IN  RRSIG  NSEC3 13 3 300 ...

NSEC3PARAM レコードを問い合わせると、ゾーンの NSEC3 パラメーターを確認できます。

dig NSEC3PARAM example.com

NSEC を使っているゾーンと NSEC3 を使っているゾーンの判別は、否定応答に含まれるレコードタイプで行います。AUTHORITY SECTION に NSEC レコードが返れば NSEC、NSEC3 レコードが返れば NSEC3 です。

外部の視点からも確認したい場合は、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 検証はリゾルバー側で自動的に行われ、NSEC / NSEC3 による不在証明の検証もリゾルバーが処理するため、存在しないドメインに対する API リクエストでは records が null で返ります。

よくある問題

NSEC / NSEC3 の選択やパラメーター設定の不備は、ゾーン情報の漏洩やサーバー負荷の増大を招きます。

NSEC によるゾーン列挙

NSEC を使用しているゾーンでは、攻撃者がゾーン内の全レコード名を列挙できます。セキュリティが求められる環境では NSEC3 への移行を検討してください。ただし、ゾーンの内容がすべて公開情報である場合（企業の外部向け DNS など）、ゾーン列挙が実際にセキュリティリスクになるかは環境によります。

NSEC3 のイテレーション回数が高すぎる

古い設定で NSEC3 のイテレーション回数を高く設定（100 以上など）しているゾーンがあります。RFC 9276 の推奨は 0 です。高いイテレーション回数は権威サーバーとリゾルバーの両方に CPU 負荷をかけ、DoS 攻撃の増幅要因になります。一部のリゾルバーは高イテレーション回数の NSEC3 レコードに対して検証を拒否し、Insecure（未検証）扱いにすることがあります。

NSEC3 でもゾーン情報が推測される

NSEC3 のハッシュは辞書攻撃に対して脆弱です。www、mail、ftp、staging など一般的なサブドメイン名のハッシュを事前計算し、NSEC3 レコードのハッシュ値と照合することで、サブドメインの存在を推測できます。ツール（nsec3walker、nsec3map など）がこの攻撃を自動化しています。RFC 9276 がソルトの廃止（空ソルト）を推奨しているのは、ソルトが辞書攻撃の防止にほとんど効果がないためです。