## page was renamed from DNSSEC <> http://jprs.jp/tech/notice/2011-07-29-jpdns-dnskey-and-rrsig-change.html JP DNSサーバーに設定されるDNSSEC関連情報の内容一部変更について ---- DNSSECの設定については書いてありません。 　DNSSECを検討する前にDNSの設定が大丈夫か、よく検討してください。 DNSSEC [[/関連ページ]] [[/good-bad]] スライド Nanog51 tutorial http://www.nanog.org/meetings/nanog51/abstracts.php?pt=MTcyMSZuYW5vZzUx&nm=nanog51 = DNSSECには手を出さないのがいい = 手間（コスト）がかかり、将来の負担も大きいものをあわてていれる必要はありません。 　毒盛防止なら、現状でも十分に実用的な対策があります。DNSSECによる効果はわずかなものですし、 　推進の主張を裏付けるだけの説明も証明も不十分です。 10年たったら、考え直すかもしれませんが。 -- ToshinoriMaeno <> DNSSEC推進者の脅迫的宣伝にはのせられないように注意しましょう。（twitter: beyondDNS) 　DNSSEC売り込みの唯一の宣伝文句[キャッシュへの毒盛を防ぐ]の意味する「[[DNS/キャッシュサーバへの毒盛]]」を理解していますか。 DNSSECの前にやることがいくつかあります。 ---- qmail.jp ドメインは[[DNS/DNSCurve]]に対応しています。 == ページ作成の背景 == DNSSECの欺瞞を明らかにして欲しいという話があって、調べたことを書きました。 DNSSECを使わせたい（売り込みたい）グループの宣伝はいろいろ見つかりますが、評価については少ない状態です。 　運用に関してのノウハウはほとんどありません。まずい点は多数あり、解決策はこれから考えよう、だそうです。 推進の本音かも： http://news.livedoor.com/article/detail/5307158/ まずい話が出てきています。 http://togetter.com/li/126480 DNSSECを推進する話（毒盛されるぞという脅しも）が多い中で、 {{{ DNSSECの運用にはとても資源（人手とお金）がかかる。その割には得られるものがない。 }}} という話が気になりました。なんのためにDNSSECをやるのかの説明もあいまいです。 一部のDNSプロバイダは[[/金儲けの機会]]だと考えているでしょうけど、とんでもない負担を将来に背負わせることになります。 現在のDNSSEC採用状況では、毒盛対策としての効果はほとんどありません。そして、運用失敗時の損害は大きなものになります。 http://jpinfo.jp/topics-column/ http://jprs.jp/dnssec/faq.html [[/JPRS]] DNSSEC対応のドメインの移転はできないと覚悟してください。 [[http://jpinfo.jp/topics-column/|ドメイン名やDNSの解説コラム]] (JPRS) == DNSSEC は署名を検証する == 署名のないもの、例えば委譲のための情報は検証できません。 [[/delegation]] [[/FAQ]] 　委譲されたドメインが署名をしていれば、そのデータは検証できます。(上位サーバに登録されたDSレコードが必要です。） 　　DNSSEC対応していないドメインはInsecureと呼ばれます。 == 現状はまだテスト段階です == 今はTLDに署名がつき始めて、そのTLD下のドメインでテストができるようになった段階だと判断できます。 http://jpinfo.jp/topics-column/ 　 http://jpinfo.jp/topics-column/015.pdf No.15 DNSSECの円滑導入と安定運用の実現のために～考えなければならない「対応と現実」～（2011年02月24日更新） {{{ ■DNSSEC の安定運用の実現に向けて このように DNSSEC の安定運用のためには、多くの関係者における相互協力や標準的な運用管理手法の確立が必要です。 JPRS では今後も各方面の関係者と協力しながら、DNSSEC の導入を推進していきます。 }}} 運用の問題は山積です。　http://internet.watch.impress.co.jp/docs/event/iw2010/20101126_409677.html 　DNSをきちんと理解していて（皮肉です）、評価してみようという事業者だけが導入している段階です。 {{{ 今後はDNSを運用する事業者の力量が問われるようになるのは確実なようだ。 }}} 「DNSSECが世界の流れ」というのはあやしい。DNSSECを使わないというのもりっぱな見識です。 　なんでも推進すればいいというものではない。新しいことをやるなら、IPv6の方が先でしょう。いっしょにやったら悲惨です。 http://www.ciojp.com/contents/?id=00006568;t=0 http://rs.impressrd.jp/e/2010/03/26/702?page=0,6 DNSSECの導入・普及における課題(2010/03/26) [[DNS/RFC/3833]] DNSへの脅威の分析 ----- 「DNSSECはキャッシュへの毒入れ攻撃に対処するための技術です。」　[[/dnssec.jp]] だが、（すべての）毒入れを阻止できると思ったら、間違いです。（業者の団体が業者を騙してどうする。） 　　すべてのドメインでDNSSECが採用されたなら、という条件が隠れています。 それにはやるべきこと(手間）がたくさんありすぎです。 　　[[DNS/毒入れ対策]]はいま（すぐ）やれることをまずやるべきです。それで十分ではないでしょうか。 {{{ Kaminsky の black hat での講演スライドやその亜流の説明を見て、毒が入ると思った人は勉強不足です。 }}} HOSTING-PRO 2010での資料：http://hosting-pro.jp/image2010/W1_minda.pdf Kaminsky 型の攻撃は「画期的な毒入れ手法（成功率ほぼ100%)」 は嘘です。 　　なんらかの前提があれば別ですが、それなら100%とはいわない。 こういう記事もありました： [[http://www.e-ontap.com/blog/20091004.html|DNSSECいうな]] {{{ (根本的に）毒盛を防ぐ方法はDNSSECだけではありません。 }}} 　 DNSSECの理想と現実　−そのIPアドレス管理への影響− (太田 昌孝/東京工業大学) 資料： http://venus.gr.jp/opf-jp/opm18/jpopm18-05.pdf 　　第18回 JPNIC オープンポリシーミーティングプログラム (2010.6.11版) 　　　http://venus.gr.jp/opf-jp/opm18/opm18-program.html WIDE: http://member.wide.ad.jp/draft/wide-draft-dns-dnssec-deployment-discussion-01.txt http://www.wide.ad.jp/project/document/reports/pdf2004/part16.pdf http://www.soi.wide.ad.jp/class/20090020/slides/13/22.html IPA研究報告(2008) 　http://www.ipa.go.jp/security/fy20/reports/tech1-tg/2_02.html == 警告 == DNSSECを権威サーバに適用するなら、最低でもRFC4033, 4034, 4035 を読んで、理解して、疑問を解明しておくべきです。 　トラブルが起きてからでは遅いと思います。（勉強中のものがアドバイスするのは僭越ですが。） DNSSECによって、DNSSECを使わないDNS運用にも影響がでることを知りました。 　現在、気づいているのはCNAME利用についての制限が少し緩和されたことだけです。 　 『「qmailでメイルが送れない」のはDNSSECのせいではない』 (なら、なんでそんなことを声高にいうの） ---- スタート資料：http://www.nic.ad.jp/ja/newsletter/No43/0800.html 　これくらいは目を通しておいてください。一通りの説明があります。 　　ただし、「DNSSECでなにができないか」（限界）は書いてありません。 === ISC 隠蔽の始まり === https://www.isc.org/software/bind/advisories/cve-2008-1447 {{{ DNS Cache Poisoning Issue ("Kaminsky bug") Summary: A weakness in the DNS protocol may enable the poisoning of caching recurive resolvers with spoofed data. DNSSEC is the only full solution. New versions of BIND provide increased resilience to the attack. }}} 問い合わせ元portを固定した問い合わせをしておきながら、DNS protocol の欠陥だとし、 DNSSECが唯一の解決策であるかの宣伝をしている。 === キャッシュ毒盛の危険性が誘導に使われている === Kaminsky の警告でキャッシュ毒盛が広く知られるようになりました。 　でも、その説明の多くは間違っています。port固定や、公開キャッシュサーバが危険であることは正しいのですが、 　16bitのtransaction IDが一致しただけでは毒は注入できません。（Kaminskyの例題も同じ誤りを含んでいる。） DNS Day(2008) [[http://internet.watch.impress.co.jp/cda/event/2008/11/26/21655.html|カミンスキーアタック]] DNSSECは毒盛を防ぐと宣伝されていますが、ほかの危険性を持ち込むことはないのでしょうか。 　すべての毒盛を防げるのでしょうか。 　　技術ですべて解決できると思うのは技術バカです。 毒盛を防ぐ方法はDNSSECだけではありません。 DNSSECだけでDNSの抱える問題が解決するわけではありません。[[/限界]] 宣伝文句「セキュリティ向上」としての効果がでるのは何年先でしょうか。 　それまでに、弊害の方がよく知られることとなるでしょう。 == DNSを管理する責任 == DNS管理の責任はDNS(サーバとデータを）管理する側にあるのです。 DNSSECを動かせばいいというものではありません。 http://emasaka.blog65.fc2.com/blog-entry-722.html http://hosting-pro.jp/image2010/W1_minda.pdf http://www.sphere.ne.jp/dnssec/ {{{ DNSキャッシュポイズニング(※)による被害の防止を理由に、 DNSSECに対応することでセキュリティを強化したキャッシュDNSサーバの提供を開始いたします。 }}} 共用のキャッシュサーバだから、やらざるを得ない。でも、 {{{ なお、DNSSECによる署名が行われていないドメインのレコード情報については、 従来のキャッシュDNSサーバと同様に検証などを行いません。 }}} なんだから、まずは他の対策をきちんとやるべき。（共用キャッシュサーバをアクセス制限するなど） ところで、署名が行われているドメインか、行われていないドメインかの区別が利用者側できちんとつくのだろうか。 あなたのキャッシュDNSサーバー、DNSSECしてますか？ http://internet.watch.impress.co.jp/docs/special/20101007_398082.html 　キャッシュDNSサーバにしたから、安心というものではないことは上にある通り。 これを読んでDNSSECのなにかが分かるのだろうか。 http://www.jpnap.net/press/2011/20110117.html == DNSSEC == http://jprs.jp/dnssec/ JPRS DNSSEC 関連資料 === RFC === 4033,4034,4035を読め。 http://www.dnssec.net/rfc DNS関連RFC（DNS関連技術情報） http://jprs.jp/dnssec/documents2.html === wikipedia === 英語:　http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions {{{ The original design of the Domain Name System (DNS) did not include security; instead it was designed to be a scalable distributed system. The Domain Name System Security Extensions (DNSSEC) attempts to add security, while maintaining backwards compatibility. RFC 3833 attempts to document some of the known threats to the DNS and how DNSSEC responds to those threats. }}} DNSにはsecurityはない。DNSSECでもいくつかの脅威（主キャッシュへの毒盛）に対応しただけ。と、読める。 いつのことを言っているのか。BINDのセキュリティ修正はなんのためだったのか。 　 [[https://datatracker.ietf.org/doc/rfc3833/|RFC3833]]は2004年に出たもの。 　根本がセキュリティに配慮していないというのはインターネットも同じではないか。 　使う側、末端が気をつけるというのが現状だが、末端には技術力はない。祈るだけ？ 日本語版には見当たらない: http://ja.wikipedia.org/wiki/DNS_Security_Extensions {{{ DNSSECはドメイン登録情報にデジタル署名を付加することで、 正当な管理者によって生成された応答レコードであること、また応答レコードが改竄されていないことを保証する。 }}} ドメイン登録情報とはなにか。（日本語版は意味不明な用語が多い） 　そのためにどれほどの努力を強いられるのだろうか。 [[http://stats.research.icann.org/dns/tld_report/|TLD DNSSEC Report (2011-03-01)]] === 用語 === [[/用語]] == なにができるのか == [[/なにができるのか]] DNSSECにより得られるものはなにか。その利点を享受するのは誰か。 {{{ DNSSEC対応キャッシュサーバ（バリデータ）を使っていれば、 「DNSSEC対応サーバから入手したDNSレコードの偽造が検出できる。」 }}} ただし、DNSSEC設定が間違っているドメインは見えなくなる。（ソフトウェアの不良を含む:-) === DNSSECが普及すれば === デジタル証明書をDNSレコード中に格納する技術も可能だ。 === 疑問 === UDPを使うことで毒盛が容易になり、それを検出するためにDNSSECを使えということなのだが、 DNSを使うことで、パケットが大きくなり、UDPでは間に合わなくなって、TCPを使うことになりそうだ。 TCPを使うなら、それだけで毒盛は十分防げるはずだ。そのことに言及しないのはなぜか。 DNSCurveのようにパケットを暗号化すれば、DNS通信内容の秘密も守れる。 == なにがまずいのか == [[/なにがまずいのか]] trouble : http://download.nominet.org.uk/dnssec-cpe/DNSSEC-CPE-Report.pdf 現状でも移譲(NS)が正しくないドメインが目立つのに、DSが正しく上位サーバに登録されるか、という心配もある。 　DSは上位サーバ側の承認が必要なレコードなので、NSレコードほどひどくはならないと期待されるが。 すべてのドメインがDNSSEC対応しないかぎり、DNSが安心して使えるようにはならない。 　つまり、使う側での判断による責任はいつまでも残る。判断時の材料にはなるが。 === 運用がむずかしいらしい === [[/gtld-servers]] の運用にも疑問がある。 [[http://www.opendnssec.org/|OpenDNSSEC]] の署名は確認できた。 .com は作業中らしい。-- ToshinoriMaeno <> http://www.nic.ad.jp/ja/mailmagazine/backnumber/2010/vol748.html ==== 定期的な鍵の更新が必要 ==== http://www.opendnssec.jp/ 時計の管理が必要とか。 [[JPRS資料から]] http://jprs.jp/dnssec/ JPRS DNSSEC 関連資料 [[/鍵の更新]] === 移転は非常に困難 === [[http://dnssec.jp/wp-content/uploads/2010/11/20101122-techwg-registrar-transfer-guideline.pdf|DNSSECレジストラ移転ガイドライン]] という文書がある。 　移転と言っても、 　「レジストラとDNSプロバイダとが同一業者」の時の移転というモデルしか扱っていない。 そういう場合にトラブルが起きやすいからなのか。 dnssec.jp は業者の団体だからだろう。 レジストラとDNSプロバイダが異なる場合は「ドメイン名所有者（登録者）自身が作業する必要があるだろう。」となっている。 　[[/移転]]で議論してみる。 推進する業者でも移転は非常に困難であることが自覚されてきている。 === DNSSECの副作用 === qmail の不良を顕在化させた DNSSEC: 　ずっと以前から分かっていた問題ですが、対策していないサイトではDNSSECで顕在化しました。 　qmailの問題であって、DNSSECには責任がないという人がなぜqmailユーザに警告するのでしょう。 　運用性の問題という言葉をご存じだからでしょう。 http://jprs.jp/tech/notice/2011-03-03-inappropriate-handling-for-long-dns-packet.html 　DNS情報を取り込むためのバッファはどれくらい用意すれば十分でしょうか。 　　Any で query を出していることや、その理由をご存知ですか。そちらに対応するパッチが必要とは思いませんか。 　　 10年以上前のソフトウェアがなんの問題もなく動いていたのなら、すごいことだとは思いませんか。 == JP での登録状況 == [[/DS]] nic.ad.jp はまだのようですね。 == DNSSEC対応キャッシュサーバ == [[/バリデータ]] [[/キャッシュサーバ]] BINDの最近の版 　http://d.hatena.ne.jp/carme-264pp/20110121/1295599232 root のトラストアンカー（信頼の出発点）をきちんと確認することが重要です。 unboundも対応しているらしい。 http://unbound.net/documentation/howto_anchor.html djbdnsは当然対応しません。（代わりにDNSCurveがあります。） ブラウザに表示させる： http://d.hatena.ne.jp/carme-264pp/20110122/1295709722 ----- == さて、どうするか == DNSSECは素晴らしい、と言えればよかったのだが、ちょっと調べただけでも技術的問題山積です。 　その上、運用上の問題は不明、ノウハウの蓄積もない。DNS毒盛だって、突然発覚したというものではない。 　　対応にどれだけの手間と金がかかるかわからない。 　DNSSECの研究者ならともかく、DNSを運用しなければならない立場であれば、当面はDNSSECに関わっている 　時間はないでしょう。宣伝に振り回されることなく、じっくり勉強してから、試してみるのが順序というものです。 もしあなたがDNSのエキスパートだと思っているなら、このページを読み続けているでしょうか。 　DNSに自信があると思っていても、設定運用に不安があるから、ここを見ているのでしょう。 　　それなら、まずはDNSSECの勉強をしてください。 もし、DNSプロバイダでDNSを仕事にしている（担当させられている）のなら、 きちんとDNSの勉強をしてください。それができないなら、他の仕事を探すことを勧めます。 趣味でDNSサーバを動かしているなら：好きなようにすればいいですが、試すならDNSCurveを勧めます。 == DNSSECを推進している方へ == DNSSECを普及させたいなら、DNSSECの問題を指摘している人たちに真摯に対応してください。 　さまざまな疑問が答えられないままになっています。インターネットなんてそんなものだというなら、そう説明してください。 とくに、DNS毒盛の危険性がどの程度だと思っておられるのか、定量的な評価をお願いします。 　危険性に対応するためにDNSSECにどれほどの資源を割くべきか、判断材料をお願いします。 == KaminskyとDJB == http://dankaminsky.com/2011/01/05/djb-ccc/ {{{ a somewhat surprising consensus has taken hold between myself, IETF WG’s, and DJB. Essentially, we all agree that: 1) Authentication and encryption on the Internet is broken, 2) Fixing both would be a Big Deal, 3) DNS is how we’re going to pull this off. }}} DJB: "Breaking DNSSEC" http://cr.yp.to/talks/2009.08.10/slides.pdf 日本語訳 http://www.unixuser.org/~euske/doc/cr.yp.to/2009.08.10.slides.html == DNSCurve == DJBはなにをしようとしているのか。 http://news.ycombinator.com/item?id=291110