Describe DNS/DNSSEC/キャッシュサーバ here.

1. 警告

DNSSEC対応したキャッシュサーバを使っても毒盛されないことにはなりません。

キャッシュサーバをDNSSEC対応させたと宣伝している業者のいうことには眉に唾をつけて聞きましょう。

DNSSEC対応の有無にかかわらず、公開キャッシュサーバは毒盛の危険を抱えています。

DNSSEC以外のしっかりした毒盛対策をしているか、確認しましょう。

sannet は正しく説明していますが、読む側がきちんと受け取っているかは別です。

DNSキャッシュサーバをDNSSECに対応させたことで、
DNSSEC対応のドメインに関しては
キャッシュポイズニング型のフィッシングから会員を守ることができます。

2. バリデータ

DNSSECキャッシュがどういう手順でDNS RRのintegrityを検証しているのかを調べる。../query

大原則

DNSSEC権威サーバからの返答であるとしても、ResourceRecordSet毎にRRSIGがついているので、
それらを個々に検証する必要がある。当然ながら、RRSIGがついていないものは検証できない。

DNSSEC対応ドメインの例として iij.ad.jp を使うことにする。

DNSSEC対応のキャッシュとしては Googl DNS (8.8.8.8)を使う。

root の trust anchor は正しく設定されているものと信じる（しかない）。

いつ、誰がやるのか。　すでに、 trust anchor にあるのか。

検証例：

% dig . dnskey | grep -w 257 > root.key; dnssec-dsfromkey -2 root.key

で得られるDSとIANAで公開されているDSとを比較せよ。

$ 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 のものとして検証できたとする。（検証方法はあとで追記する）

毒の可能性のあるNS、Aではあるが、試してみることになる。（毒だと分かったなら、捨てればいい。というのが、DNSSECの立場）

身元確認するために、JPサーバのDNSKEYを問い合わせてみる。

$ dig +cd +multi jp dnskey @203.119.1.1

前節でroot サーバからもらったDSレコードとKSK = [DNSKEY 257]のハッシュ値とが一致するか調べる。

NS, A をRRSIGとZSKを使って検証する。

ここまででやっと、JPサーバがDNSSEC検証できた。

JPサーバの一台が検証できたので、やっと、iij.ad.jp のサーバを教えてもらう順番がやってきた。

root サーバにJPサーバのNSなどを問い合わせたときと同様。