DNSSECに関するよくある質問と回答（技術仕様編-2015年1月版）

DNSSECの技術仕様に関する質問と回答をQ&A形式でまとめました。
http://jprs.jp/dnssec/でも公開していますので、併せてご利用ください。

DNSSECの基本仕様は2005年に発行された、RFC4033、4034、4035により定められています。
これに加え、キャッシュDNSサーバーの円滑な運用に必要なトラストアンカーの自動更新の仕様を定めたRFC5011が2007年に、ゾーンの列挙（後述）を困難にするためのNSEC3とTLDにおける段階的なDNSSECの導入を容易にするOpt-Outの仕様を定めたRFC5155が2008年に、それぞれ発行されました。
その後、仕様の明確化と実装のための注意点をまとめたRFC6840が2013年に発行されています。

Q2 DNSSECでは名前やRR（リソースレコード）が存在しないこと（不在証明）を、どのように検証しているのですか？

電子署名では存在する情報に対して署名を付加します。このため、そのままでは名前が存在しないことは検証できません。
DNSSECでは、ゾーンの内容を大文字にした上でASCIIコード（アルファベット）順に整え（*1）、対象の名前の前後の名前とRR の種別をNSECレコードで提示することにより、存在しないことを検証しています（図１）。

図 1 NSECレコードによる不在証明

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

前述の通りDNSSECでは、不在証明を前後の名前とRRの存在によって検証するという特徴があります。
そのためこの特徴を利用し、DNSSEC に対応したゾーンに存在するNSECレコードを外部から順にたどることにより、そのゾーン内のドメイン名の一覧を外部から入手することが可能になります。この行為は「ゾーンの列挙（Zone enumeration）」と呼ばれます（図 2）。

図 2 ゾーンの列挙（Zone enumeration）

ゾーンの列挙はゾーンウォーキング（Zone walking）またはDNSウォーキング（DNS walking）などとも呼ばれており、特に.jpや.com/.netなどといったTLDにおいては、セキュリティやプライバシーなどの観点から、DNSSEC導入の障害となっていました（*2）。
そのためIETF はこの問題を解決するためにDNSSEC の仕様を改良し、RFC 5155 で定義されるNSEC3（次で説明）として定めました。

Q4 NSEC3 とは何ですか？

DNSSECによる不在証明を従来のNSECから、名前情報をハッシュした結果を利用するNSEC3に変更することで、名前情報の列挙を困難にするための拡張方式をいいます（図 3）。

図 3 NSEC3レコードの概要

.jpや.com/.netなどの主要なTLDでは、NSEC3を用いたDNSSECの導入が図られています。

Q5 従来のNSEC はもう使われないのですか？

ゾーンの管理者は不在証明の方式としてNSECまたはNSEC3のいずれかを、それぞれのゾーン単位で自由に選択できます。
従来のNSECではゾーンの列挙を抑制することはできませんが、NSEC3と比較した場合にゾーン情報の管理運用が容易で、ゾーン情報を管理する権威DNS サーバー、DNSSECを検証するキャッシュDNSサーバーの双方の負荷を低くできるという特徴があります。そのため、ゾーンの内容が既知であるルートゾーンやin-addr.arpaやip6.arpaといったDNS逆引き用ゾーンではNSEC3ではなく、従来のNSECによるDNSSECの導入が図られています。

Q6 DNSSECが導入されることで動作に影響の出る既存のソフトウェアはありますか？

一般的なDNSSECの導入ではDNSクライアントとキャッシュDNSサーバー間におけるDNS 問い合わせ・応答のやり取りは変化しないため、各種DNSクライアント（クライアントPCや各種サーバーソフトウェアなど）における特別の対応は、基本的に必要ありません。
ただしANYレコードに対する応答だけは例外で、DNSSEC の導入と同時にキャッシュDNS サーバーからの応答サイズが、無条件に大きくなります。
現時点において、メール配送ソフトウェアであるqmail1.03がこの影響を受ける可能性があることが報告されており（*3）、パッチの適用などの対応が必要になります。

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

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

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

Q8 DNSSEC 導入後にキャッシュポイズニング攻撃による偽情報の注入が成功したらどうなりますか？

DNSSECの導入によりキャッシュポイズニング攻撃の検知が可能になります。BIND9やUnboundなどの現在の主なキャッシュDNSサーバーの実装では、「Server failure」エラーを返すことで、偽サイトへの誘導を防止しています。

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

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

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

掲載内容は2015年1月のものです。

DNSSECに関するよくある質問と回答（技術仕様編-2015年1月版）

目次