[B! DNSSEC] yunohitoのブックマーク

DNSの権威・Cricket Liu氏に聞く - DNSセキュリティ対策とIPv6の現状

サーバ管理者やネットワーク管理者にとって、ネームサーバの管理は頭の痛い問題の1つだ。DNSやIPの仕組みはネットワークシステムの根幹であり、小さな設定ミスが大きな問題に発展しかねないからだ。今回、Infoblox社のVP of Architecture & Techno logyでO'Reillyの『DNS & BIND』の著者として知られるClicket Liu氏とInfoblox社のChief IPv6 EvangelistのTom Coffeen氏に、現在のネットワーク管理における課題であるDNSのセキュリティ対策とIPv6の導入について聞いた。 2つの課題とは、DNSのセキュリティ対策とIPv6の導入である。それに加えて、両氏が現在所属するInfobloxがこれらの問題への対策として提供するソリューションについても語っていただいた。左から、Tom Coffeen氏(Infoblox

yunohito 2011/11/10

リンク

ZabbixでDNSSECの有効期間を監視してみた – Aimless

yunohito 2011/11/06

リンク

Truth of Kaminsky Bug

実験目的 Kaminsky が示した毒入れ手法は DNSプロトコルの欠陥によるものであり、非常に危険なものであるという論を根拠に DNSSEC が推進されている。しかし、BlackHat USA 2008 における Kaminsky の講演のスライドに示されている方法にはいろいろな点で疑義がある(Finchなど)。qmail.jp の前野氏からあれで毒が入ると思うかとの指摘を受けたこともあり、散々考えたが、私には Kaminsky のスライドどおりに毒が入ることがどうしても納得いかなかった。そして、Kaminskyが間違っている(あるいは嘘をついている)、あるいは、BIND には毒が入るバグがあって Kaminsky の攻撃手法が成功するというのではないかという仮説が引き出せる。これは前野氏が当初から洞察していたことであった。この仮説に基づくと、Kaminsky の発表から3年経った今、そ

yunohito 2011/10/30

リンク

キャッシュDNSサーバのDNSSEC対応

今回は、DNSSECの検証機能を有効にしたキャッシュDNSサーバを構築・運用する方法について解説する。 DNSSECにおけるキャッシュDNSサーバの役割キャッシュDNSサーバは、名前解決を依頼するクライアントと権威DNSサーバの間に立ち、反復検索を行うサーバである。DNSSECにおいて検証を担当するものを「バリデータ（Validator）」と呼び、多くの場合キャッシュDNSサーバがバリデータを担当する。第2回でも簡単に説明したが、DNSSECの検証を行うためには信頼の連鎖の起点となる情報が必要となる。これを「トラストアンカー（Trust Anchor）」と呼ぶ。バリデータとなるキャッシュDNSサーバは、トラストアンカーを起点に、DNSSECの信頼の連鎖を検証していくことになる。 DNSの階層構造における委任の起点がルートゾーンであることから、一般的にはルートゾーンの公開鍵情報をトラスト