Contents

  1. DNSSECでなにができるのか
    1. RFC
    2. なにができるのか
      1. 採用のメリット
    3. なにがまずいのか
      1. 運用がむずかしいらしい
        1. 定期的な鍵の更新が必要

1. DNSSECでなにができるのか

1.1. RFC

4033,4034,4035を読め。 http://www.dnssec.net/rfc

DNS関連RFC（DNS関連技術情報） <http://jprs.jp/tech/index.html#dns-rfc-info>

../用語

1.2. なにができるのか

DNSSECにより得られるものはなにか。その利点を享受するのは誰か。

できるようになるのは、 

  「DNSSEC対応サーバから入手したDNSレコードの偽造が検出できる。」

だけでしょう。つまり、対応サーバ間でのやりとりの一部に毒を入れさせないことだけです。（この意味ではDNSCurveも同じ目的です。）

DNSSEC対応していないサーバからのデータ（毒の可能性）はいままで通りに受け取ることでしょう。

http://ya.maya.st/d/201103a.html#d20110309　(どさにっき 3D)

http://www.dnssec.net/ 

The Root Trust Anchor can be found at the IANA DNSSEC website.

IANA DNSSEC: https://www.iana.org/dnssec/

https://jprs.jp/doc/dnssec/jp-dps-jpn.html

trust-chain をたどって到達できたサーバは正規のサーバであるといえます。

trouble : http://download.nominet.org.uk/dnssec-cpe/DNSSEC-CPE-Report.pdf

http://diary.sshida.com/c-DNSSEC

../疑問の数々

http://www.janog.gr.jp/meeting/janog24/doc/2_dnssec.pdf

DNSSECの仕組み: http://dnssec.jp/wp-content/uploads/2010/07/20100721-whats_dnssec-sakaguchi.pdf

http://internet.watch.impress.co.jp/docs/special/20101007_398082.html

http://www.jpnap.net/press/2011/20110117.html

http://rs.impressrd.jp/e/2010/03/26/702?page=0%2C5 

ゾーンの公開鍵自体が正しいものであることを確認する術は、上位のゾーンによって提供される。
ゾーンの管理者は、ドメインの委任を行うNS情報を上位のゾーンに登録するのと同様に、
公開鍵の情報を上位のゾーンに登録し、上位のゾーンの秘密鍵で署名されることによって、
正しさの確認ができるのである。

つまり、DNSSECではドメイン名の委譲の構造と同じ仕組みで、信頼の連鎖を作り上げているのである（図7）。

これだけ読んでも、DNSSECが正しく機能しないサイトが多いだろうことが推測できる。

なぜ「委譲」にこだわるのか。

DNSという中央集権的構造を残したいがためにやっているように見える。

DNSキャッシュの毒盛対策に効果があるとしても、より複雑な機構をもちこむことにより、 管理運用の間違いを増やしていいとは思えない。

委譲が正しく行われているという前提が成り立つならば、

$ dnsq 43 jp a.root-servers.net 

43 jp:
507 bytes, 1+2+13+9 records, response, authoritative, noerror
query: 43 jp
answer: jp 86400 43 \005Y\010\001Y\342\006\003\341\273\240>\012B\377VH\245\027\375#\212\346\331
answer: jp 86400 43 \005Y\010\002\037?Jf\351T\302\177\261m\370\214\245\352\016\210\312\223\204i\013\274\343\246\267\365N\236k\312\026\233

1.2.1. 採用のメリット

直接のメリットは見えないだろうから、 DNSSECを採用しているというステータス表示がどれくらいのものか、評価してから実施するのでも遅くない。

自前のDNSサーバを運用するメリットがなくなるほどのデメリットがありそう。

1.3. なにがまずいのか

https://www.dns-oarc.net/oarc/services/replysizetest を見よ。 

Recent increases in DNSSEC deployment are exposing problems with DNS resolvers that cannot receive large responses.

The maximim reply size between a DNS server and resolver may be limited by a number of factors:

    * If a resolver does not support the Extension Mechanisms for DNS (EDNS), replies are limited to 512 bytes.
    * The resolver may be behind a firewall that blocks IP fragments.
    * Some DNS-aware firewalls block responses larger than 512 bytes.

TCPを使う可能性が高くなる。

こっちはEDNSが使えない。

%dig +short rs.dns-oarc.net txt 

rst.x476.rs.dns-oarc.net.
rst.x485.x476.rs.dns-oarc.net.
rst.x490.x485.x476.rs.dns-oarc.net.
"202.41.218.243 DNS reply size limit is at least 490"
"202.41.218.243 lacks EDNS, defaults to 512"
"Tested at 2011-02-27 15:25:07 UTC"

よく言われているのは、DOSに弱点をもつこと。EDSN0が一筋縄では動かないこと。ルータなどが関係する。

こっちではEDNSが使える。（ubuntu 10.10, buffalo router -> so-net ADSL, DNSキャッシュはgoogle経由)

$ dig +short rs.dns-oarc.net txt 

rst.x3827.rs.dns-oarc.net.
rst.x3837.x3827.rs.dns-oarc.net.
rst.x3843.x3837.x3827.rs.dns-oarc.net.
"202.238.95.10 DNS reply size limit is at least 3843"
"202.238.95.10 sent EDNS buffer size 4096"
"Tested at 2011-02-27 15:37:23 UTC"

trouble : http://download.nominet.org.uk/dnssec-cpe/DNSSEC-CPE-Report.pdf

現状でも移譲(NS)が正しくないドメインが目立つのに、DSが正しく上位サーバに登録されるか、という心配もある。

すべてのドメインがDNSSEC対応しないかぎり、DNSが安心して使えるようにはならない。

1.3.1. 運用がむずかしいらしい

権威サーバの運用はかなり面倒だ。　../運用

どれくらい分かって書いているかはしらないが、こういうページもある。 http://ya.maya.st/d/201102b.html#d20110218

1.3.1.1. 定期的な鍵の更新が必要

DNSSECではないDNSの運用すら問題が多い状況なのに、 複雑な手順で「定期的に鍵を更新しなくてはならない」というのでは実施するドメインは多くないだろう。 実施しても、正しく運用される可能性は少ない。

移転の複雑さも今とは比べものにならない。DNS/移転

セカンダリサーバの運用も難しくなるだろう。

http://www.opendnssec.jp/

../DS JP での登録状況