MoinQ:

Contents

  1. DNSSECには手を出さないのがいい
    1. ページ作成の背景
    2. DNSSEC は署名を検証する
    3. 現状はまだテスト段階です
    4. 警告
      1. ISC 隠蔽の始まり
      2. キャッシュ毒盛の危険性が誘導に使われている
    5. DNSを管理する責任
    6. DNSSEC
      1. RFC
      2. wikipedia
      3. 用語
    7. なにができるのか
      1. DNSSECが普及すれば
      2. 疑問
    8. なにがまずいのか
      1. 運用がむずかしいらしい
        1. 定期的な鍵の更新が必要
      2. 移転は非常に困難
      3. DNSSECの副作用
    9. JP での登録状況
    10. DNSSEC対応キャッシュサーバ
    11. さて、どうするか
    12. DNSSECを推進している方へ
    13. KaminskyとDJB
    14. DNSCurve
http://jprs.jp/tech/notice/2011-07-29-jpdns-dnskey-and-rrsig-change.html

DNSSECの設定については書いてありません。

DNSSEC /関連ページ /good-bad スライド

Nanog51 tutorial http://www.nanog.org/meetings/nanog51/abstracts.php?pt=MTcyMSZuYW5vZzUx&nm=nanog51

1. DNSSECには手を出さないのがいい

手間（コスト）がかかり、将来の負担も大きいものをあわてていれる必要はありません。

10年たったら、考え直すかもしれませんが。 -- ToshinoriMaeno 2011-04-23 23:22:02

DNSSEC推進者の脅迫的宣伝にはのせられないように注意しましょう。（twitter: beyondDNS)

DNSSECの前にやることがいくつかあります。

qmail.jp ドメインはDNS/DNSCurveに対応しています。

1.1. ページ作成の背景

DNSSECの欺瞞を明らかにして欲しいという話があって、調べたことを書きました。

DNSSECを推進する話（毒盛されるぞという脅しも）が多い中で、 

DNSSECの運用にはとても資源（人手とお金）がかかる。その割には得られるものがない。

という話が気になりました。なんのためにDNSSECをやるのかの説明もあいまいです。

現在のDNSSEC採用状況では、毒盛対策としての効果はほとんどありません。そして、運用失敗時の損害は大きなものになります。

http://jpinfo.jp/topics-column/ http://jprs.jp/dnssec/faq.html /JPRS

DNSSEC対応のドメインの移転はできないと覚悟してください。

ドメイン名やDNSの解説コラム (JPRS)

1.2. DNSSEC は署名を検証する

署名のないもの、例えば委譲のための情報は検証できません。 /delegation /FAQ

1.3. 現状はまだテスト段階です

今はTLDに署名がつき始めて、そのTLD下のドメインでテストができるようになった段階だと判断できます。 

■DNSSEC の安定運用の実現に向けて
このように DNSSEC の安定運用のためには、多くの関係者における相互協力や標準的な運用管理手法の確立が必要です。
JPRS では今後も各方面の関係者と協力しながら、DNSSEC の導入を推進していきます。

今後はDNSを運用する事業者の力量が問われるようになるのは確実なようだ。

「DNSSECが世界の流れ」というのはあやしい。DNSSECを使わないというのもりっぱな見識です。

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 

Kaminsky の black hat での講演スライドやその亜流の説明を見て、毒が入ると思った人は勉強不足です。

HOSTING-PRO 2010での資料：http://hosting-pro.jp/image2010/W1_minda.pdf

こういう記事もありました： DNSSECいうな 

  (根本的に）毒盛を防ぐ方法はDNSSECだけではありません。

DNSSECの理想と現実　−そのIPアドレス管理への影響− (太田 昌孝/東京工業大学)

WIDE:

IPA研究報告(2008)

1.4. 警告

DNSSECを権威サーバに適用するなら、最低でもRFC4033, 4034, 4035 を読んで、理解して、疑問を解明しておくべきです。

DNSSECによって、DNSSECを使わないDNS運用にも影響がでることを知りました。

スタート資料：http://www.nic.ad.jp/ja/newsletter/No43/0800.html

1.4.1. 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が唯一の解決策であるかの宣伝をしている。

1.4.2. キャッシュ毒盛の危険性が誘導に使われている

Kaminsky の警告でキャッシュ毒盛が広く知られるようになりました。

DNS Day(2008) カミンスキーアタック

DNSSECは毒盛を防ぐと宣伝されていますが、ほかの危険性を持ち込むことはないのでしょうか。

DNSSECだけでDNSの抱える問題が解決するわけではありません。/限界

宣伝文句「セキュリティ向上」としての効果がでるのは何年先でしょうか。

1.5. DNSを管理する責任

DNS管理の責任はDNS(サーバとデータを）管理する側にあるのです。

http://emasaka.blog65.fc2.com/blog-entry-722.html

http://www.sphere.ne.jp/dnssec/ 

DNSキャッシュポイズニング(※)による被害の防止を理由に、
DNSSECに対応することでセキュリティを強化したキャッシュDNSサーバの提供を開始いたします。

共用のキャッシュサーバだから、やらざるを得ない。でも、 

なお、DNSSECによる署名が行われていないドメインのレコード情報については、
従来のキャッシュDNSサーバと同様に検証などを行いません。

なんだから、まずは他の対策をきちんとやるべき。（共用キャッシュサーバをアクセス制限するなど）

ところで、署名が行われているドメインか、行われていないドメインかの区別が利用者側できちんとつくのだろうか。

あなたのキャッシュDNSサーバー、DNSSECしてますか？ http://internet.watch.impress.co.jp/docs/special/20101007_398082.html

これを読んでDNSSECのなにかが分かるのだろうか。 http://www.jpnap.net/press/2011/20110117.html

1.6. DNSSEC

http://jprs.jp/dnssec/ JPRS DNSSEC 関連資料

1.6.1. RFC

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

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

1.6.2. 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でもいくつかの脅威（主キャッシュへの毒盛）に対応しただけ。と、読める。

日本語版には見当たらない: http://ja.wikipedia.org/wiki/DNS_Security_Extensions 

DNSSECはドメイン登録情報にデジタル署名を付加することで、
正当な管理者によって生成された応答レコードであること、また応答レコードが改竄されていないことを保証する。

ドメイン登録情報とはなにか。（日本語版は意味不明な用語が多い）

TLD DNSSEC Report (2011-03-01)

1.6.3. 用語

/用語

1.7. なにができるのか

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

DNSSEC対応キャッシュサーバ（バリデータ）を使っていれば、
  「DNSSEC対応サーバから入手したDNSレコードの偽造が検出できる。」

ただし、DNSSEC設定が間違っているドメインは見えなくなる。（ソフトウェアの不良を含む:-)

1.7.1. DNSSECが普及すれば

デジタル証明書をDNSレコード中に格納する技術も可能だ。

1.7.2. 疑問

UDPを使うことで毒盛が容易になり、それを検出するためにDNSSECを使えということなのだが、 DNSを使うことで、パケットが大きくなり、UDPでは間に合わなくなって、TCPを使うことになりそうだ。

TCPを使うなら、それだけで毒盛は十分防げるはずだ。そのことに言及しないのはなぜか。

DNSCurveのようにパケットを暗号化すれば、DNS通信内容の秘密も守れる。

1.8. なにがまずいのか

/なにがまずいのか

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

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

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

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

/gtld-servers の運用にも疑問がある。

OpenDNSSEC の署名は確認できた。

.com は作業中らしい。-- ToshinoriMaeno 2011-03-04 13:50:31

http://www.nic.ad.jp/ja/mailmagazine/backnumber/2010/vol748.html

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

http://www.opendnssec.jp/

時計の管理が必要とか。

JPRS資料から http://jprs.jp/dnssec/ JPRS DNSSEC 関連資料

1.8.2. 移転は非常に困難

DNSSECレジストラ移転ガイドライン という文書がある。

そういう場合にトラブルが起きやすいからなのか。 dnssec.jp は業者の団体だからだろう。

レジストラとDNSプロバイダが異なる場合は「ドメイン名所有者（登録者）自身が作業する必要があるだろう。」となっている。

推進する業者でも移転は非常に困難であることが自覚されてきている。

1.8.3. DNSSECの副作用

qmail の不良を顕在化させた DNSSEC:

http://jprs.jp/tech/notice/2011-03-03-inappropriate-handling-for-long-dns-packet.html

10年以上前のソフトウェアがなんの問題もなく動いていたのなら、すごいことだとは思いませんか。

1.9. JP での登録状況

/DS

nic.ad.jp はまだのようですね。

1.10. DNSSEC対応キャッシュサーバ

/バリデータ /キャッシュサーバ

BINDの最近の版

unboundも対応しているらしい。 http://unbound.net/documentation/howto_anchor.html

djbdnsは当然対応しません。（代わりにDNSCurveがあります。）

ブラウザに表示させる： http://d.hatena.ne.jp/carme-264pp/20110122/1295709722

1.11. さて、どうするか

DNSSECは素晴らしい、と言えればよかったのだが、ちょっと調べただけでも技術的問題山積です。

もしあなたがDNSのエキスパートだと思っているなら、このページを読み続けているでしょうか。

もし、DNSプロバイダでDNSを仕事にしている（担当させられている）のなら、 きちんとDNSの勉強をしてください。それができないなら、他の仕事を探すことを勧めます。

趣味でDNSサーバを動かしているなら：好きなようにすればいいですが、試すならDNSCurveを勧めます。

1.12. DNSSECを推進している方へ

DNSSECを普及させたいなら、DNSSECの問題を指摘している人たちに真摯に対応してください。

とくに、DNS毒盛の危険性がどの程度だと思っておられるのか、定量的な評価をお願いします。

1.13. 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

1.14. DNSCurve

DJBはなにをしようとしているのか。