JAPAN REGISTRY SERVICESＪＰＲＳ トピックス＆コラム

No. 016■ＤＮＳＳＥＣに関するよくある質問と回答（技術仕様編—２０１５年１月版）
ＤＮＳＳＥＣの技術仕様に関する質問と回答をＱ＆Ａ形式でまとめました。ＪＰＲＳホームページ(http://jprs.jp/dnssec/)でオンライン版を公開していますので、併せてご利用ください。
■DNSSEC の技術仕様について

Q3 「ゾーンの列挙」とは何ですか？

Q1 DNSSEC の基本仕様を定めている RFC はどれですか？

前述の通り DNSSEC では、不在証明を前後の名前とRR の存在によって検証するという特徴があります。

DNSSEC の基本仕様は 2005 年に発行された、RFC4033、4034、4035 により定められています。

そのためこの特徴を利用し、DNSSEC に対応したゾーンに存在する NSEC レコードを外部から順にたどるこ

これに加え、キャッシュ DNS サーバーの円滑な運用とにより、そのゾーン内のドメイン名の一覧を外部からに必要なトラストアンカーの自動更新の仕様を定めた入手することが可能になります。この行為は「ゾーンのRFC 5011 が 2007 年に、ゾーンの列挙（後述）を困難に列挙（Zone enumeration）」と呼ばれます（図２）。

するための NSEC3 と TLD における段階的な DNSSEC■ゾーン列挙の例

Q2 DNSSEC では名前や RR（リソースレコード）が存

TLD.
IN NSEC 00000000.TLD. NS SOA TXT RRSIG NSEC DNSKEY
00000000.TLD. IN NSEC 00000001.TLD. NS RRSIG NSEC
00000001.TLD. IN NSEC 00000002.TLD. NS RRSIG NSEC:
example1.TLD. IN NSEC example2.TLD. NS DS RRSIG NSEC
example2.TLD. IN NSEC example3.TLD. NS RRSIG NSEC
example3.TLD. IN NSEC example4.TLD. NS DS RRSIG NSEC::NS DS RRSIG NSEC
zzzzzzzz.TLD. IN NSEC TLD.

在しないこと（不在証明）を、どのように検証している■ゾーン列挙の手順と特徴の導入を容易にする Opt-Out の仕様を定めた RFC
5155 が 2008 年に、それぞれ発行されました。
その後、仕様の明確化と実装のための注意点をまとめた RFC 6840 が 2013 年に発行されています。

①そのゾーン自体（上記の例ではTLD）のNSECを検索する②検索結果中の「次の名前」のNSECを検索する③以下同じ手順を繰り返し、NSECを順にたどる④次の名前としてそのゾーン自体が示されたら終了のですか？
電子署名では存在する情報に対して署名を付加し権威DNSサーバーの問い合わせログを監視することで、ゾーンの列挙の試行を検出することはある程度可能であるが、DNSSECのプロトコルの仕様上、行為を完全に防止することはできないます。このため、そのままでは名前が存在しないことは検証できません。

図２：ゾーンの列挙（Zone enumeration）

DNSSEC では、ゾーンの内容を大文字にした上で1ASCII コード（アルファベット）順に整え 、対象の名前のゾーンの列挙はゾーンウォーキング（Zone walking）

前後の名前と RR の種別を NSEC レコードで提示するこまたは DNS ウォーキング（DNS walking）などとも呼ばれとにより、存在しないことを検証しています（図１）。ており、特に.jp や.com/.net などといった TLD において■NSECレコードの例
sec1.example.jp. IN NSEC sec3.example.jp. NS DS RRSIG NSEC

■上記の意味アルファベット順でsec1.example.jpの次に存在するのはsec3.example.jpであり、sec1.example.jpにはNS、DS、RRSIG、NSECの各RRが存在しているは 、セ キ ュリテ ィやプラ イバ シー など の観 点から 、DNSSEC 導入の障害となっていました2。
そ の た め IETF は こ の 問 題 を 解 決 す る た め に■使用例1：「その名前は存在しない」
sec2.example.jpのAレコードの問い合わせに対し上記のNSECレコードを提示することで、sec1.example.jpとsec3.example.jpの間には名前が存在しないことを、問い合わせ元に提示できる■使用例2：「名前そのものは存在するが、そのRRは存在しない」
sec1.example.jpのAレコードの問い合わせに対し上記のNSECレコードを提示することで、sec1.example.jpにはAレコードが存在しないことを、問い合わせ元に提示できる

DNSSEC の仕様を改良し、RFC 5155 で定義されるNSEC3（次で説明）として定めました。

図１：NSEC レコードによる不在証明2

RFC 4034 の「Canonical DNS Name Order」で定義されています。

例えば、入手したドメイン名の一覧を利用して spam メールを無差別に送信する、といった迷惑行為が考えられます。

Copyright © 2015 株式会社日本レジストリサービス※掲載内容は2015年1月現在のものです。

11

JAPAN REGISTRY SERVICES
Q4 NSEC3 とは何ですか？
DNSSEC による不在証明を従来の NSEC から、名前情報をハッシュした結果を利用する NSEC3 に変更する

ただし ANY レコードに対する応答だけは例外で、DNSSEC の導入と同時にキャッシュ DNS サーバーからの応答サイズが、無条件に大きくなります。
現時点において、メール配送ソフトウェアである qmail

ことで、名前情報の列挙を困難にするための拡張方式をいいます（図３）。
■NSEC3レコードの例
ae98fav0k.TLD. IN NSEC3 1 1 12 1234ABCD j543aeadi NS DS RRSIG

1.03 がこの影響を受ける可能性があることが報告されており3、パッチの適用などの対応が必要になります。

Q7 DNSSEC 検証に失敗した場合どうなりますか？

■NSEC3レコードの生成方法
ハッシュソート
sec1.TLD
r32jf3jda
5v3zvdwf3
dj013jf12
sec2.TLDae98fav0k
5v3zvdwf3
dj013jf12
sec3.TLD
ae98fav0k
j543aeadi
sec4.TLD
j543aeadi
r32jf3jda
sec5.TLD■NSEC3による不在証明
存在しない名前であるsec2.TLDを検索すると、sec2.TLDをハッシュした「dj013jf12」の前後に存在する「ae98fav0k」と「j543aeadi」がNSEC3レコードとして応答され、受信側でsec2.TLDが存在しないことを検証できる
注：上記例は原理の説明で、ハッシュ値は実際のものとは異なる

DNSSEC 検証に失敗した場合、キャッシュ DNS サー
バーは DNS クライアント側に、名前解決に失敗したことを示す「Server failure」エラーを返します。
このエラーは、いわゆる Lame delegation や権威 DNS
サーバーの設定不備・サーバーダウンなどにより、名前解決が失敗した場合と同じものです。そのため、エラーを受け取った Web ブラウザーなどの DNS クライアントは

図３：NSEC3 レコードの概要

従来の場合と同様、「指定された Web ページが表示で.jp や.com/.net などの主要な TLD では、NSEC3 をきない」といったエラーメッセージを表示します（図４）。

用いた DNSSEC の導入が図られています。

■DNSSEC検証失敗時の動作

Q5 従来の NSEC はもう使われないのですか？
ゾーンの管理者は不在証明の方式として NSEC また同じエラーが表示されるは NSEC3 のいずれかを、それぞれのゾーン単位で自由に選択できます。
従来の NSEC ではゾーンの列挙を抑制することはで

DNS設定不備・サーバーダウンなどきませんが、NSEC3 と比較した場合にゾーン情報の管DNSSEC検証失敗

DNSSEC検証に失敗した場合、キャッシュDNSサーバーは従来のDNSエラーと同様「Server failure」エラーを返す

理運用が容易で、ゾーン情報を管理する権威 DNS サ

WebブラウザーなどのDNSクライアントは、従来と同様のエラーメッセージを表示する

ーバー、DNSSEC を検証するキャッシュ DNS サーバーの双方の負荷を低くできるという特徴があります。そのため、ゾーンの内容が既知であるルートゾ ーンや

図４：DNSSEC 検証に失敗した場合の動作

in-addr.arpa や ip6.arpa といった DNS 逆引き用ゾーン

Q8 DNSSEC 導入後にキャッシュポイズニング攻撃

では NSEC3 ではなく、従来の NSEC による DNSSEC のによる偽情報の注入が成功したらどうなりますか？
DNSSEC の導入によりキャッシュポイズニング攻撃の導入が図られています。

Q6 DNSSEC が導入されることで動作に影響の出る検知が可能になります。BIND 9 や Unbound などの現在既存のソフトウェアはありますか？の主なキャッシュ DNS サーバーの実装では、「Server一般的な DNSSEC の導入では DNS クライアントとキャッシュ DNS サーバー間における DNS 問い合わせ・応failure」エラーを返すことで、偽サイトへの誘導を防止しています。

答のやり取りは変化しないため、各種 DNS クライアント（クライアント PC や各種サーバーソフトウェアなど）における特別の対応は、基本的に必要ありません。

3

詳細については JPRS 公開文書「qmail/netqmail における 512 バイトを超える DNS 応答の不適切な取り扱いについて」を参照。
http://jprs.jp/tech/notice/2011-03-03-inappropriate-handling-for-lon
g-dns-packet.html

Copyright © 2015 株式会社日本レジストリサービス ※すべてのコラムは http://jprs.jp/related-info/guide/ でご覧いただけます。 2