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

1. 警告

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 を使うことにする。

DNSSEC対応のキャッシュとしては Googl DNS (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

/jp

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

/jp-keys

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

2.4. JP サーバにNSレコードを問い合わせる

/jp-ns

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

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

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

2.5. JP サーバに iij.ad.jp サーバを問い合わせる

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

/jp-iij