このページは2011年1月24日に作成された古いものです。
DNSSECの仕組み
DNSSECは、DNSの生みの親として広く知られているポール・モッカペトリス（Paul Mockapetris）氏によって提案されました。
ゾーン情報の信頼性を確保する方法としては、ゾーン情報そのものを暗号化して改ざんを防ぐ手段も考えられます。
しかし、それではDNS応答のたびに暗号の解読コストが発生し、効率が大きく低下します。
そこでより手ごろな手段として、ハッシュ関数を組み合わせるのです。ハッシュ関数でゾーン情報のハッシュ値を求め、そのハッシュ値を公開鍵暗号方式で暗号化したものを署名としてゾーン情報に添付します。
ゾーン情報と比べてハッシュ値はごく小さなデータであるため、解読に掛かるコストも少なくなります。
ゾーン情報を受け取った側は、受信したゾーン情報のハッシュ値を計算し、さらに署名を解読して送信時のゾーン情報のハッシュ値を求めます。ゾーン情報が改ざんされたものでなければ、両ハッシュ値が一致するというわけです。
正当性の保障
DNSSECは、権威サーバからキャッシュサーバに 転送されるデータに電子署名を付与することで、
転送データの正当性（クラッカに よって作成された偽の情報でないこと）を保証する。
電子署名
DNSSECでは、公開鍵暗号方式と呼ばれる暗号方式を利用した電子署名を転送データに 付与している。
署名と検証方法
①権威サーバに秘密鍵（データの送信者のみが保持する鍵）、キャッシュサーバに 公開鍵（データの受信者に配布する鍵）を持たせておく。
②続いて、転送データを ハッシュ値と呼ばれる値に変換（ハッシュ化）する。
③さらに、ハッシュ値を 権威サーバの持っている秘密鍵で暗号化し、
この暗号化データを署名として転送データに 付与する。
④署名付きの転送データを受け取ったキャッシュサーバは、受信したゾーン情報のハッシュ値を求めます。
⑤キャッシュサーバは 公開鍵を用いて署名を復号し、ゾーン情報のハッシュ値を求めます。
⑥ ④と⑤で得られたハッシュ値を比較し一致していることで、転送データの正当性を証明する。
※このとき、転送データに署名するための鍵を ZSK（Zone Signing Key）、
ZSKに署名するための鍵をKSK（Key Signing Key）と呼ぶ。
正当性って
公開鍵そのものが改ざんされる可能性を考えてみましょう。
公開鍵が改ざんされても、秘密鍵が変わっていなければ署名の機能は果たされます。
なぜなら、秘密鍵で暗号化したデータは、その秘密鍵と対をなす公開鍵でしか復号できないからです。
しかし、DNSサーバが乗っ取られて、秘密鍵・公開鍵ともに差し替えられてしまえば
ゾーン情報の改ざんは侵入者の思いのままです。
公開鍵の署名
そこで、作成した鍵を第三者に承認してもらう必要があります。
ベリサインなどの専門のCA機関を利用することも考えられますが、
RFC 2535方式のDNSSECでは上位ゾーンのDNSサーバを利用する方法が提案されています。
example.comドメイン管理者が作成した公開鍵を基に、上位ゾーンであるcomドメイン管理者が
comドメインの秘密鍵を使って署名を作成し、それを example.comドメイン管理者に送り返します。
example.jpドメイン管理者は、自身の公開鍵の署名としてcomゾーンの管理者から送られた署名を利用します。
疑問
example.comドメインのゾーン情報の検証に、comドメインが利用している公開鍵を使用しています。
また、comドメインの検証を行うために.（ルート）ドメインの公開鍵を使用します。
そこで、.（ルート）ドメインの検証はどの鍵で行うのでしょうか？
ドメインツリーを利用する以上、その根（ルート）に帰結することは必至です。
.（ルート）ゾーンを検証する鍵はマスター鍵として、あらかじめ配布されたものをDNS問い合わせを行う全サーバに登録しておく必要があります。
では、.（ルート）ゾーンがDNSSECに対応していなければ、自身のゾーン情報にDNSSECを実装することは無意味でしょうか？
不特定多数のDNSクライアントまでサービス対象とする場合は、.（ルート）ゾーンのみならず、ドメインツリー経路上すべてのドメインでのDNSSEC対応が必須になります。もちろん、DNSクライアント自身もDNSSEC対応の問い合わせができる必要があります。
しかし、サービス対象を特定のDNSクライアントに限るなら、これらの条件は必須ではありません。
その特定のDNSクライアントに、ドメインツリー経路途 中のDNSサーバが持っている公開鍵を信頼済み鍵として登録することで、そのDNSサーバを頂点とする新しいセキュリティルートを確保することができます。
DS方式
RFC 2535方式は公開鍵の署名を上位ゾーンに依頼し、上位ゾーンから送り返される公開鍵署名をゾーン情報に登録する必要があります。そこで、上位のゾーン情報に下位ゾーンの公開鍵の署名を登録するDS（Delegation Signer）方式が検討されています。
DS方式では、NSレコードなどの資源レコードの1つとしてDSレコードを設け、これに下位ゾーンの公開鍵のハッシュ値と鍵idを登録します。下位ゾーン の管理者は、公開鍵署名が上位ゾーンから送り返されるのを待たずに、いままでNSレコードにDNSサーバを登録してもらっていた要領でDSレコードの登録 を上位ゾーンに依頼できます。
DS方式を採用することで、DSレコードがなければ、そのゾーンはDNSSECで保護されていないことが分かり、 DNSSEC問い合わせをする必要がなくなりす。
これは、ドメインツリー上の全ドメインで一斉にDNSSECに対応する必要性をなくし、jpや comなどのTLDでDNSSECを導入しやすくします。
ただ現在、多くのTLDは一般庶民のDS登録を受け付けてくれません。
DLV方式
BINDの開発元であるISCではDLV(Dnssec Look-aside Validation Redstry)というサービスを無償提供しています。
DLVはPKI証明書に似たモデルで、DLVを提供する事業者により各組織の 鍵情報(DS)が署名されます。そのため、DLV提供事業者のポリシー次第ですが一 般庶民でも鍵情報の登録を受け付けてもらえます。
自サーバー(自前のDNSコンテンツサーバー)でKSK鍵、ZSK鍵を作成します。
ISC DLV pageにアクセス
Registarでアカウント生成
Manage Zones
Add Zoneで、ゾーン追加
Add DNSKEY RecordでDNSKEY(公開鍵)=ZSK.keyを登録
dlv.ドメイン名 に TXT を追加すると認証するといわれるのでゾーンファイルに追記して署名
reloadします
しばらく待つと ドメイン名.dlv.isc.org にDLV RRが追加されます
参考にさせていただいたサイト
小規模なDNSSEC遊び --- 私のDNSSEC対応 ---
dnsseczonetool 作者の藤原和典殿に感謝いたします。
DLV方式で設定してみました
実際に問合せを行ってみましょう
$ dig +dnssec www.iij.ad.jp
; <<>> DiG 9.7.2-P3 <<>> +dnssec www.iij.ad.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6335
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.iij.ad.jp. IN A
;; ANSWER SECTION:
www.iij.ad.jp. 286 IN A 210.130.137.80
www.iij.ad.jp. 286 IN RRSIG A 8 4 300 20110222151005 20110123151005 55020 iij.ad.jp. DLPXrRpDwC7QO+qhJ7kBhDgkdZcRzK2/y4qo5tNzx7F9aKtJtRkeeEly j/4EgQpVWPbQQ26HIP7dnOzsLuNnQMxNx6RNb+ven9VDvgj7SKFicqGz 6su7Rm7llVLoxi8byZjPhS36IYSuUwNhZE/YywDkdGSw2wZeCbyc6lQ5 qRU=
;; AUTHORITY SECTION:
iij.ad.jp. 72937 IN NS dns1.iij.ad.jp.
iij.ad.jp. 72937 IN NS dns0.iij.ad.jp.
iij.ad.jp. 86392 IN RRSIG NS 8 3 86400 20110222151005 20110123151005 55020 iij.ad.jp. mdWTXn7PQITDWb8v64jt87jC+LYSP+kfuyrGu1hfJ0FHyGq0Ouoz2W+H aGeRFbvFtQZBsRrdVyb/P8k7Q4N2APrXrQ4szJfQM676KUQF0x4sfJcl tnOYgd+d87Fn0LZzjgNJWvznw4ahDPRxvDiRQOnDQYu8RZOrjNB/PLal gV8=
$ dig txt dlv.iij.ad.jp
; <<>> DiG 9.7.2-P3 <<>> txt dlv.iij.ad.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 52825
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;dlv.iij.ad.jp. IN TXT
;; AUTHORITY SECTION:
iij.ad.jp. 900 IN SOA bh0.iij.ad.jp. postmaster.iij.ad.jp. 1295799005 3600 1800 1209600 3600
さすがISPですね
一般庶民はどうでしょうか
$ dig +dnssec www.xn--estw0hpyhbtcjyw.com
; <<>> DiG 9.7.2-P3 <<>> +dnssec www.xn--estw0hpyhbtcjyw.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61400
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 5
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.xn--estw0hpyhbtcjyw.com. IN A
;; ANSWER SECTION:
www.xn--estw0hpyhbtcjyw.com. 771 IN A 203.141.xxx.xxx
www.xn--estw0hpyhbtcjyw.com. 771 IN RRSIG A 5 3 3600 20110220052103 20110121052103 47451 xn--estw0hpyhbtcjyw.com. BKacGzqLLHL+ppUIU3sFSQB9K5s23JixvggMxmzALDp4nYYOlYDcCc+X 0TeigluSGKT5ho7Uk0E+eqFiP+gwcDQt2uz1Z6iXXNcnuDGs9jaLzdF2 ZPTb2RctENbJeCzcrfZCKexm2IGx+vSiP+rUIGHaLGNlFpRHg7CykrCr mLI=
;; AUTHORITY SECTION:
xn--estw0hpyhbtcjyw.com. 771 IN NS ns.ishige-jp.com.
xn--estw0hpyhbtcjyw.com. 771 IN NS ns.fangpi.net.
xn--estw0hpyhbtcjyw.com. 3379 IN RRSIG NS 5 2 3600 20110220052103 20110121052103 47451 xn--estw0hpyhbtcjyw.com. JoWe8YhikEC2K5i3NR90hXsZ6AjmCB+UZRDOBKDHGiulU5TQB90+AwUj r7YPCO5Rt0vSM+Rxpos9ErnE4uEix+BagQtHBvqlKMpjjmpGhhDGyGWr znWPelqHdcdnAmYEnSKj4tRCzqzQqZ8sT/gt98Nbugv9y2buczXMLDBb ioo=