## page was renamed from DNS/DNSSEC/なにができるのか <> = DNSSECでなにができるのか = == RFC == 4033,4034,4035を読め。 http://www.dnssec.net/rfc DNS関連RFC（DNS関連技術情報） [[../用語]] == なにができるのか == DNSSECにより得られるものはなにか。その利点を享受するのは誰か。 できるようになるのは、 {{{ 「DNSSEC対応サーバから入手したDNSレコードの偽造が検出できる。」 }}} だけでしょう。つまり、対応サーバ間でのやりとりの一部に毒を入れさせないことだけです。（この意味ではDNSCurveも同じ目的です。） 　一部のデータには署名は付きませんので、その部分に毒を入れることは可能らしい。 DNSSEC対応していないサーバからのデータ（毒の可能性）はいままで通りに受け取ることでしょう。 　それがDNSSEC対応のドメインにどういう影響を与えるかは分かりません。 　　「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 http://jprs.jp/dnssec/doc/dnssec.pdf trust-chain をたどって到達できたサーバは正規のサーバであるといえます。 trouble : http://download.nominet.org.uk/dnssec-cpe/DNSSEC-CPE-Report.pdf 　DNSSECを使うと、巨大なパケットが返ってくることを覚悟しなければならない。　[[/query]] http://diary.sshida.com/c-DNSSEC http://dnsops.jp/bof/20101125/dnssec-or-not-03.pdf [[../疑問の数々]] 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という中央集権的構造を残したいがためにやっているように見える。 ---- 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サーバを運用するメリットがなくなるほどのデメリットがありそう。 == なにがまずいのか == 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が安心して使えるようにはならない。 　つまり、使う側での判断による責任はいつまでも残る。判断時の材料にはなるが。 === 運用がむずかしいらしい === 権威サーバの運用はかなり面倒だ。　[[../運用]] どれくらい分かって書いているかはしらないが、こういうページもある。 http://ya.maya.st/d/201102b.html#d20110218 ==== 定期的な鍵の更新が必要 ==== DNSSECではないDNSの運用すら問題が多い状況なのに、 複雑な手順で「定期的に鍵を更新しなくてはならない」というのでは実施するドメインは多くないだろう。 実施しても、正しく運用される可能性は少ない。 　正しい手順で行わないと、ドメインがなくなったように見えてしまう。 移転の複雑さも今とは比べものにならない。[[DNS/移転]] セカンダリサーバの運用も難しくなるだろう。 http://www.opendnssec.jp/ [[../DS]] JP での登録状況