よくある質問
| Q1 | DNSSECとは何ですか？ |
|---|---|
| A1 | DNSSECは、DNSサーバから受信したDNS応答が「本当に正しい」ということを受信側で検証可能にするための、DNSの拡張機能です。 |
| ▲いちばん上に戻る | |
| Q2 | 「本当に正しい」というのはどういうことですか？ |
| A2 |
受信したデータについて以下の二つが確認できた場合、そのデータは「本当に正しい」と検証できます。
|
| ▲いちばん上に戻る | |
| Q3 | DNSSECではDNS応答の偽造をどのように防いでいるのですか？ |
| A3 | DNSSECでは応答送信の際に公開鍵暗号を利用した署名を付加します。受信側で付加された署名を検証することによりデータの出自認証と完全性を確認でき、DNS応答の偽造を防ぐことができます。 |
| ▲いちばん上に戻る | |
| Q4 | 公開鍵暗号とは何ですか？ |
| A4 |
データの暗号化と復号に異なる一対の鍵（公開鍵と秘密鍵）を用いる暗号方式をいいます。
公開鍵暗号方式では、外部に広く公開する公開鍵と作成者が秘匿する秘密鍵の２種類の鍵を利用します。公開鍵と秘密鍵は必ず一対になっており、一方の鍵で暗号化したデータは、他方の鍵でのみ復号できるようになっています（暗号化に使った鍵そのものも含め、別の鍵では復号できません）。
公開鍵暗号による暗号通信では、通信相手の公開鍵でデータを暗号化してから相手に送信します。このデータは相手の秘密鍵以外では復号できません。
そして、暗号化に使った公開鍵に対応する秘密鍵を持っているのは通信相手のみであるため、より安全な暗号通信を行うことができます（図１）。
 図１：共有鍵暗号と公開鍵暗号 |
| ▲いちばん上に戻る | |
| Q5 | 署名とは何ですか？ |
| A5 |
公開鍵暗号の仕組みを応用することにより、そのデータが「本当に正しい」ことを検証できるデジタル署名（以下、単に「署名」とします）を実現できます。
公開鍵暗号を用いてデータに署名する場合、送信者は自分の秘密鍵で作成した署名をデータと共に、相手に送信（あるいは広く公開）します。この署名は送信者の公開鍵で検証できるため、誰でも元のデータの正しさを検証できます（そのため、データの秘匿性はありません）。しかし、それ以外の鍵では検証できません。
つまり、データに署名したのは検証に使った公開鍵に対応する秘密鍵を持っている送信者以外になく、かつデータが途中で書き換えられていない、つまり｢本当に正しい｣ということが証明できます（図２）。
 図２：公開鍵暗号による署名 |
| ▲いちばん上に戻る | |
| Q6 | 署名の際に使われるハッシュ値とは何で、何のために使われるのですか？ |
| A6 |
実際の署名検証ではデータそのものに代え、事前に決められた方法（ハッシュ関数）によりデータから計算した「ハッシュ値」と呼ばれる数値を使用します。
送信者は計算したハッシュ値に自分の秘密鍵で署名したもの（ハッシュ値に対する署名）を、元のデータと共に送信します。受信者は受信したデータからハッシュ値を計算し、相手の公開鍵で検証したハッシュ値と照合します。二つの値が一致した場合、受信したデータが「本当に正しい」ことを検証できます(図３)。
このように、署名対象をデータそのものから、より短い数値であるハッシュ値に変更することにより、署名検証にかかる負荷を軽減できます。
 図３：ハッシュ値の照合による署名の検証 |
| ▲いちばん上に戻る | |
| Q7 | RSA暗号とは何ですか？ |
| A7 | 公開鍵暗号を実現するために1977年に開発された暗号方式で、DNSSECを含む多くの分野で使われています。「RSA」という名前は、この方式を発明した３人の暗号研究者の頭文字に由来しています。 |
| ▲いちばん上に戻る | |
| Q8 | キャッシュポイズニング攻撃とは何ですか？ |
| A8 | 偽のDNS応答をキャッシュDNSサーバに記憶させることにより、フィッシングや電子メールの盗み見などを図る攻撃方法をいいます 。 キャッシュポイズニング攻撃そのものは古くから知られていましたが、2008年に発表されたカミンスキー型攻撃手法により、攻撃のリスクが飛躍的に高まりました。 |
| ▲いちばん上に戻る | |
| Q9 | カミンスキー型攻撃手法とは何ですか？ |
| A9 | キャッシュポイズニング攻撃を高効率で成立させるための攻撃方法です。DNSプロトコル上の脆弱性に起因しており、根本的な対策としてDNSSECの導入が有効になります。 カミンスキー型攻撃手法の詳細についてはJPRSトピックス＆コラムNo.9「新たなるDNSキャッシュポイズニングの脅威」をご参照ください。 |
| ▲いちばん上に戻る | |
| Q10 | DNSSECで実現されることは何ですか？ |
| A10 | DNSSECの導入により、受け取ったDNS応答が「本当に正しい」ことを受信側で検証できるようになります。そのため、前述したキャッシュポイズニング攻撃の防止に対し有効です。 |
| ▲いちばん上に戻る | |
| Q11 | DNSSECでは実現されないことは何ですか？ |
| A11 | DNSSECではDNS応答の暗号化を行いません。 DNSSECはDNSに対する付加機能であり、HTTPなどのDNS以外の通信の安全性を保証するためには、IPsecやSSLなどの技術を別途用いる必要があります。 DNSSECでは、ドメイン名の見間違いや打ち間違いを狙うタイプのフィッシングには対応できません。 |
| ▲いちばん上に戻る | |
| Q12 | DNSSECとSSLの違いは何ですか？ |
| A12 | DNSSECでは、相手との通信開始前に必要となる、名前解決の安全性を保証します。 これに対しSSLでは、相手との通信時の本人証明、及び通信データの暗号化を行っています。 |
| ▲いちばん上に戻る | |
| Q13 | 私は既にSSLを導入しています。DNSSECを追加導入する必要がありますか？ |
| A13 | DNSSECとSSLは双方とも、暗号技術により利用者の安全性を高めるための技術です。しかしDNSSECとSSLでは保護の対象が異なっており、他方の機能を包含するものではありません。そのためSSLが導入済みであっても、DNSの名前解決の安全性を確保するためにはDNSSECを別途導入する必要があります。 |
| ▲いちばん上に戻る | |
| Q14 | DNSSECの技術仕様を定めているRFCはどれですか？ |
| A14 | DNSSECの技術仕様は2005年に発行された、RFC 4033、4034、4035の三つにより定められています。 これに加え、キャッシュDNSサーバーを円滑に運用するために必要なトラストアンカーの自動更新の仕様を定めたRFC 5011が2007年に、ゾーン列挙（Zone enumeration）（後述）を困難にするためのNSEC3拡張を定めたRFC 5155が2008年にそれぞれ発行され、現在のDNSSECの基本技術仕様となっています。 |
| ▲いちばん上に戻る | |
| Q15 | DNSSECでは名前が存在しないことを、どのように検証しているのですか？ |
| A15 |
電子署名では実在する情報に対してのみ、署名情報を付加することができます。このため、そのままでは名前が存在しないことは検証できません。
DNSSECではこの場合、ゾーンの内容を大文字にした上でASCIIコード（アルファベット）順に整え 、問い合わされた名前の前後の名前をNSECレコードにより提示し、それらの間には何もないことを示すことにより、名前が存在しないことを検証可能にしています（図１）。
 図１：NSECレコードによる不在証明 |
| ▲いちばん上に戻る | |
| Q16 | 「ゾーン列挙（Zone enumeration）」とは何ですか？ |
| A16 |
前述の通りDNSSECでは、データの不在を前後のデータの存在によって検証するという特徴があります。
そのためこの特徴を利用し、DNSSECに対応したゾーンに存在するNSECレコードを外部から順にたどることにより、そのゾーン内のドメイン名の一覧を入手することが可能になります。この行為は「ゾーン列挙（Zone enumeration）」と呼ばれます（図２）。
 図２：ゾーン列挙（Zone enumeration） ゾーン列挙はゾーンウォーキング（Zone walking）またはDNSウォーキング（DNS walking）などとも呼ばれており、特に.jpや.com/.netなどといったTLDにおいては、セキュリティやプライバシーなどの観点から、DNSSEC導入の障害となっていました 。 そのためIETFはこの問題を解決するためにDNSSECの仕様を改良し、RFC 5155で定義されるNSEC3拡張（次で説明）として定めました。 |
| ▲いちばん上に戻る | |
| Q17 | NSEC3とは何ですか？ |
| A17 |
DNSSECによる不在証明を従来のNSECから、名前情報をハッシュ化した結果を利用するNSEC3に変更することで、名前情報の列挙を困難にするための拡張方式をいいます（図３）。
 図３：NSEC3レコードの概要 .jpや.com/.netなどの主要なTLDでは、NSEC3を用いたDNSSECの導入が図られています。 |
| ▲いちばん上に戻る | |
| Q18 | 従来のNSECはもう使われないのですか？ |
| A18 | ゾーンの管理者は不在証明の方式としてNSECまたはNSEC3のいずれかを、それぞれのゾーン単位で自由に選択することができます。 従来のNSECでは名前情報の列挙を抑制することはできませんが、NSEC3と比較した場合にゾーン情報の管理運用が容易で、ゾーン情報を管理する権威DNSサーバー、DNSSECを検証するキャッシュDNSサーバーの双方の負荷を低くできるという特徴があります。そのため、ゾーンの内容が既知であるルートゾーンやin-addr.arpaやip6.arpaといったDNS逆引き用ゾーンではNSEC3ではなく、従来のNSECによるDNSSECの導入が図られています。 |
| ▲いちばん上に戻る | |
| Q19 | DNSSECが導入されることで動作に影響の出る既存のソフトウェアはありますか？ |
| A19 | 一般的なDNSSECの導入ではDNSクライアントとキャッシュDNSサーバー間におけるDNS問い合わせ・応答のやり取りは変化しないため、各種DNSクライアント（クライアントPCや各種サーバーソフトウェアなど）における特別の対応は、基本的に必要ありません。 ただしANYレコードだけは例外で、DNSSECの導入と同時にキャッシュDNSサーバーからの応答サイズが、無条件に大きくなります。 現時点において、メール配送ソフトウェアであるqmail 1.03がこの影響を受ける可能性があることが報告されており、パッチの適用などの対応 が必要になります。 |
| ▲いちばん上に戻る | |
| Q20 | DNSSEC検証に失敗した場合どうなりますか？ |
| A20 |
DNSSEC検証に失敗した場合、キャッシュDNSサーバーはDNSクライアント側に、名前解決に失敗したことを示す「Server failure」エラーを返します。
このエラーは、いわゆるLame delegationや権威DNSサーバーの設定不備、あるいはサーバーダウンなどにより、名前解決が失敗した場合と同じものとなります。そのため、このエラーを受け取ったWebブラウザーなどのDNSクライアントは従来の場合と同様、「指定されたWebページが表示できない」といったエラーメッセージを表示することになります（図４）。
 図４：DNSSEC検証に失敗した場合の動作 |
| ▲いちばん上に戻る | |
| Q21 | DNSSEC導入後にキャッシュポイズニング攻撃を受けたらどうなりますか？ |
| A21 | DNSSECの導入によりキャッシュポイズニング攻撃の検知が可能になります。BIND 9やUnboundなどの現在の主なキャッシュDNSサーバーの実装では、「Server failure」エラーを返すことで、偽サイトへの誘導を防止しています。 |
| ▲いちばん上に戻る |