Describe DNS/DNSSEC/キャッシュサーバ here.
1. 警告
DNSSEC対応したキャッシュサーバを使っても毒盛されないことにはなりません。
- DNSSEC対応したコンテンツサーバにあるドメインだけが保護されるからです。
キャッシュサーバをDNSSEC対応させたと宣伝している業者のいうことには眉に唾をつけて聞きましょう。
- 役に立たない機能を買いたがる客にも問題があります。
DNSSEC対応の有無にかかわらず、公開キャッシュサーバは毒盛の危険を抱えています。
DNSSEC以外のしっかりした毒盛対策をしているか、確認しましょう。
sannet は正しく説明していますが、読む側がきちんと受け取っているかは別です。
DNSキャッシュサーバをDNSSECに対応させたことで、 DNSSEC対応のドメインに関しては キャッシュポイズニング型のフィッシングから会員を守ることができます。
この記事も自分でよく考えてみよう： http://internet.watch.impress.co.jp/docs/special/20101007_398082.html
2. バリデータ
DNSSECの世界では../バリデータと言われる。 DNSSEC/validating-resolvers
http://d.hatena.ne.jp/carme-264pp/20110121/1295599232
DNSSECキャッシュがどういう手順でDNS RRのintegrityを検証しているのかを調べる。../query
大原則
DNSSEC権威サーバからの返答であるとしても、ResourceRecordSet毎にRRSIGがついているので、 それらを個々に検証する必要がある。当然ながら、RRSIGがついていないものは検証できない。
DNSSEC対応ドメインの例として iij.ad.jp を使うことにする。
- jp やルートがDNSSEC対応していることは当然の前提である。
DNSSEC対応のキャッシュとしては Googl DNS (8.8.8.8)を使う。
- （当面は8.8.8.8 からの返答に毒は入っていないとする。）
root の trust anchor は正しく設定されているものと信じる（しかない）。
2.1. root server の DNSKEY の入手
いつ、誰がやるのか。 すでに、 trust anchor にあるのか。
検証例：
% dig . dnskey | grep -w 257 > root.key; dnssec-dsfromkey -2 root.key
で得られるDSとIANAで公開されているDSとを比較せよ。
2.2. JPサーバのNSレコードを入手する
$ dig +dnssec jp ns @a.root-servers.net
answer section にはNS,DS, RRSIG(DS)がある。 additional section には A, AAAA がある。 (optional の検証用の root DNSKEY はついていないし、あっても使えないから、trust anchorのものを使う。）
この時点では NS, A, AAAA には署名がない。 毒入りの可能性がある。 RRSIG があるDSだけは検証可能である。
DSの署名RRSIGはroot server のものとして検証できたとする。（検証方法はあとで追記する）
2.3. JPサーバを確認する
毒の可能性のあるNS、Aではあるが、試してみることになる。（毒だと分かったなら、捨てればいい。というのが、DNSSECの立場）
身元確認するために、JPサーバのDNSKEYを問い合わせてみる。
$ dig +cd +multi jp dnskey @203.119.1.1
前節でroot サーバからもらったDSレコードとKSK = [DNSKEY 257]のハッシュ値とが一致するか調べる。
- 一致したら、KSKが検証できたことにして、このKSKを使って、ZSK[DNSKEY 256]を検証する。
- 検証がすめば、身元確認できたことになる。 そうしたら、確認できたJPサーバにNSなどを問い合わせてみる。
2.4. JP サーバにNSレコードを問い合わせる
NS, A をRRSIGとZSKを使って検証する。
ここまででやっと、JPサーバがDNSSEC検証できた。
- 途中でひとつでも失敗すると、JPサーバはDNSSECの世界からは消滅する。:-)
JPサーバの一台が検証できたので、 やっと、iij.ad.jp のサーバを教えてもらう順番がやってきた。
2.5. JP サーバに iij.ad.jp サーバを問い合わせる
root サーバにJPサーバのNSなどを問い合わせたときと同様。