JAPAN REGISTRY SERVICES
No. 014ＪＰＲＳ トピックス＆コラム■ＤＮＳＳＥＣに関するよくある質問と回答（基礎技術編―２０１１年２月版）

ＤＮＳＳＥＣに関するよくある質問と回答をＱ＆Ａ形式でまとめました。オンライン版はＪＰＲＳ
ホームページ(http://jprs.jp/dnssec/)で公開されていますので、併せてご利用ください。
■DNSSEC の基本について
Q1 DNSSEC とは何ですか？
DNSSEC は、DNS サーバーから受信した DNS 応答が「本当に正しい」ということを受信側で検証可能にするための、DNS の拡張機能です。

Q2 「本当に正しい」というのはどういうことですか？

データは相手の秘密鍵以外では復号できません。
そして、暗号化に使った公開鍵に対応する秘密鍵を持っているのは通信相手のみであるため、より安全な暗号通信を行うことができます（図１）。
共有鍵暗号① 本当にその相手が作成したものであること（データ出自の認証）

同じ鍵を共有こんにちは

相手の公開鍵で暗号化

公開鍵
暗号② 通信途中で書き換えられたり、一部が失われたり自分の秘密鍵で復号

○△※□×

○△※□×

公開鍵 秘密鍵

こんにちは

していないこと（データの完全性）
つまり「正しい相手から」「そのままの形で」の二つが、○△※□×

こんにちは受信したデータについて以下の二つが確認できた
場合、そのデータは「本当に正しい」と検証できます。

○△※□×

こんにちは

図１：共有鍵暗号と公開鍵暗号

Q5 署名とは何ですか？

「本当に正しい」の検証における必要条件となります。

公開鍵暗号の仕組みを応用することにより、そのデQ3 DNSSEC では DNS 応答の偽造をどのように防いータが「本当に正しい」ことを検証できるデジタル署名でいるのですか？

（以下、単に「署名」とします）を実現できます。

DNSSEC では応答送信の際に公開鍵暗号を利用し公開鍵暗号を用いてデータに署名する場合、送信た署名を付加します。受信側で付加された署名を検証

者は自分の秘密鍵で作成した署名をデータと共に、相することによりデータの出自認証と完全性を確認でき、手に送信（あるいは広く公開）します。このデータは送DNS 応答の偽造を防ぐことができます。

信者の公開鍵で検証できるため、誰でも元のデータのQ4 公開鍵暗号とは何ですか？

正しさを検証できます（そのため、データの秘匿性はあ

データの暗号化と復号に異なる一対の鍵（公開鍵と秘密鍵）を用いる暗号方式をいいます。

りません）。しかし、それ以外の鍵では検証できません。
つまり、データに署名したのは検証に使った公開鍵

公開鍵暗号方式では、外部に広く公開する公開鍵とに対応する秘密鍵を持っている送信者以外になく、か作成者が秘匿する秘密鍵の２種類の鍵を利用します。

つデータが途中で書き換えられていない、つまり｢本当公開鍵と秘密鍵は必ず一対になっており、一方の鍵でに正しい｣ということが証明できます（図２）。

暗号化したデータは、他方の鍵でのみ復号できるようの鍵では復号できません）。
公開鍵暗号による暗号通信では、通信相手の公開受信者発信者になっています（暗号化に使った鍵そのものも含め、別秘密鍵で作成

データ

データ

データ

署名署名署名公開鍵で検証

図２：公開鍵暗号による署名鍵でデータを暗号化してから相手に送信します。このCopyright © 2011 株式会社日本レジストリサービス※掲載内容は2011年2月現在のものです。

1

JAPAN REGISTRY SERVICES
Q6 署名の際に使われるハッシュ値とは何で、何のために使われるのですか？

Q9 カミンスキー型攻撃手法とは何ですか？
キャッシュポイズニング攻撃を高効率で成立させるた

実際の署名検証ではデータそのものに代え、事前にめの攻撃方法です。DNS プロトコル上の脆弱性に起因決められた方法（ハッシュ関数）によりデータから計算ししており、根本的な対策として DNSSEC の導入が有効た「ハッシュ値」と呼ばれる数値を使用します。になります。

送信者は計算したハッシュ値に自分の秘密鍵で署

カミンスキー型攻撃手法の詳細については JPRS トピ名したもの（ハッシュ値に対する署名）を、元のデータとックス＆コラム No.9「新たなる DNS キャッシュポイズニン

共に送信します。受信者は受信したデータからハッシュグの脅威」をご参照ください。

値を計算し、相手の公開鍵で検証したハッシュ値と照■DNSSEC の機能について合します。二つの値が一致した場合、受信したデータ

Q10 DNSSEC で実現されることは何ですか？

が「本当に正しい」ことを検証できます(図３)。

DNSSEC の導入により、受け取った DNS 応答が「本このように、署名対象をデータそのものから、より短い当に正しい」ことを受信側で検証できるようになります。

数値であるハッシュ値に変更することにより、署名検証

そのため、前述したキャッシュポイズニング攻撃の防止にかかる負荷を軽減できます。

に対し有効です。
受信者

発信者
データ

データ
署名

ハッシュ

秘密鍵

DNSSEC では DNS 応答の暗号化を行いません2。

データ

DNSSEC は DNS に対する付加機能であり、HTTP な

ハッシュハッシュ値照合

ハッシュ値

ハッシュ値

署名

検証

署名

Q11 DNSSEC では実現されないことは何ですか？

公開鍵

署名

図３：ハッシュ値の照合による署名の検証

Q7 RSA 暗号とは何ですか？
公開鍵暗号を実現するために 1977 年に開発された暗号方式で、DNSSEC を含む多くの分野で使われていどの DNS 以外の通信の安全性を保証するためには、IPsec や SSL などの技術を別途用いる必要があります。
DNSSEC では、ドメイン名の見間違いや打ち間違いを狙うタイプのフィッシングには対応できません。

Q12 DNSSEC と SSL の違いは何ですか？
DNSSEC では、相手との通信開始前に必要となる、名前解決の安全性を保証します。
これに対し SSL では、相手との通信時の本人証明、ます。「RSA」という名前は、この方式を発明した３人の及び通信データの暗号化を行っています。

暗号研究者の頭文字に由来しています。

Q13 私は既に SSL を導入しています。DNSSEC をQ8 キャッシュポイズニング攻撃とは何ですか？

追加導入する必要がありますか？

偽の DNS 応答をキャッシュ DNS サーバーに記憶さ

DNSSEC と SSL は双方とも、暗号技術により利用者のせることにより、フィッシングや電子メールの盗み見など安全性を高めるための技術です。しかし DNSSEC と

1

SSL では保護の対象が異なっており、他方の機能を包を図る攻撃方法をいいます 。
キャッシュポイズニング攻撃そのものは古くから知ら含するものではありません。そのため SSL が導入済みれていましたが、2008 年に発表されたカミンスキー型であっても、DNS の名前解決の安全性を確保するため攻撃手法により、攻撃のリスクが飛躍的に高まりました。には DNSSEC を別途導入する必要があります。

1 誤認に基づくフィッシングと異なり、ブラウザーのアドレスバーに正当な Web サイトと全く同じ URI が表示されるため、危険性が高くなります。

Copyright © 2011 株式会社日本レジストリサービス

2 DNS 登録情報は公開情報であり、暗号化を必要としません。

※全てのコラムは http://jpinfo.jp/topics-column/ でご覧いただけます。 2