Contents

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

1. DNSSECでなにがまずいのか

http://www.e-ontap.com/dns/criticism/

https://news.ycombinator.com/item?id=8894902

https://www.reddit.com/r/netsec/comments/2jrrt3/djb_making_sure_crypto_remains_insecure_slides/

1.1. RFC

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

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

../用語

../なにができるのか

../疑問の数々

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 

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

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

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

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

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

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.1.1. 採用のメリットが見えない

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

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

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

1.2. なにがまずいのか

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

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

DNSSECをサポートできるキャッシュサーバの挙動
 * キャッシュサーバは、権威サーバへ問い合わせる際DOビットを必ずONにする
 * RFC 3225  Indicating Resolver Support of DNSSECSection 3より抜粋
A recursive DNSSEC-aware server MUST set the DO bit on recursive requests, 
regardless of the status of the DO bit on the initiating resolver request.
 * よって、権威サーバはゾーン情報がDNSSECで署名されていれば、必ずRRSIG付で応答

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

1.2.1. 長い返答が通るか

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"

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

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

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

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

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

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

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

http://www.opendnssec.jp/

../DS JP での登録状況