## page was renamed from DNS/DNSSEC/なにがまずいのか <> = 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/ == RFC == 4033,4034,4035を読め。 http://www.dnssec.net/rfc DNS関連RFC（DNS関連技術情報） [[../用語]] [[../なにができるのか]] [[../疑問の数々]] 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という中央集権的構造を残したいがためにやっているように見える。 ---- DNSキャッシュの毒盛対策に効果があるとしても、より複雑な機構をもちこむことにより、 管理運用の間違いを増やしていいとは思えない。 __委譲が正しく行われている__という前提が成り立つならば、 　[[DNSCurve]] のように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 }}} === 採用のメリットが見えない === 直接のメリットは見えないだろうから、 DNSSECを採用しているというステータス表示がどれくらいのものか、評価してから実施するのでも遅くない。 　手間（コスト）をかけるだけの意義があるか、よく考えるべき。 自前のDNSサーバを運用するメリットがなくなるほどのデメリットがありそう。 すべてのドメインがDNSSEC対応しないかぎり、DNSは安心して使えるようにはならない。 　つまり、使う側での判断による責任はいつまでも残る。判断時の材料にはなるが。 == なにがまずいのか == 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 DOビットをONにするキャッシュサーバ: dnssec-enableのyes/noは無関係 === 長い返答が通るか === 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" }}} ---- === 運用がむずかしいらしい === 権威サーバの運用はかなり面倒だ。　[[../運用]] どれくらい分かって書いているかはしらないが、こういうページもある。 http://ya.maya.st/d/201102b.html#d20110218 ==== 定期的な鍵の更新が必要 ==== DNSSECではないDNSの運用すら問題が多い状況なのに、 複雑な手順で「定期的に鍵を更新しなくてはならない」というのでは実施するドメインは多くないだろう。 実施しても、正しく運用される可能性は少ない。 　正しい手順で行わないと、ドメインがなくなったように見えてしまう。 移転の複雑さも今とは比べものにならない。[[DNS/移転]] セカンダリサーバの運用も難しくなるだろう。 http://www.opendnssec.jp/ [[../DS]] JP での登録状況