■ JPRSに対する都道府県型JPドメイン名新設に係る公開質問 JPRSから以下のプレスリリースが出ていた。 「JPRSが、地域に根ざした新たなドメイン名空間「都道府県型JPドメイン名」の新設を決定」, 株式会社日本レジストリサービス, 2011年9月26日 内容を見て仰天。都道府県ドメインに第3レベルでの登録を認める「都道府県型JPドメイン名」を新設するという。そこで以下の公開質問状を送った。 株式会社日本レジストリサービス御中 都道府県型JPドメイン名新設に係る公開質問 東京都〓〓区〓〓〓〓〓 高木 浩光 2011年9月27日 貴社2011年9月26日報道発表の「JPRSが、地域に根ざした新たなドメイン名空間「都道府県型JPドメイン名」の新設を決定」について、Webのセキュリティ及び可用性の観点から、公共の利益に影響を及ぼす懸念があると思料するため、貴社に対し、以下の通り、公開を前提と
公開: 2011年9月3日19時50分頃 モバツイ (www.movatwi.jp)の作者えふしんさんと、Twitterでこんなやりとりをしました。 OperaってDNSのTTL考慮してない?!多くのブラウザは安全性のために短すぎるTTLを無視したりしますが (DNS Pinning)、それとはまた違う話でしょうか?AWSのElastic Load Balancingで、動的にロードバランサーのサーバが増えたり減ったりするようで、夜明けのOperaがよく全然違うサービスに繋がってしまうことがあるんですよね。少なくともクッキーは送っちゃってますよね...あー、なるほど。それはまずいですね。これは盲点でした……。 OperaやIEなどは、DNSのTTLが短く設定されていても無視してキャッシュし続ける事があります。これはDNSの負荷を減らすというだけはでなく、セキュリティ上の意味もあり、「DNS
--------------------------------------------------------------------- ■(緊急)Windows DNSサーバーの脆弱性を利用した攻撃について - セキュリティ更新プログラムの適用を強く推奨 - 株式会社日本レジストリサービス(JPRS) 初版作成 2011/08/11(Thu) --------------------------------------------------------------------- ▼概要 Windows Server 2003、2008及び2008 R2のWindows DNSサーバーには実装上 の不具合があり、リモートからのサービス不能(DoS)攻撃、またはサーバー 上における任意のコードの実行が可能になる脆弱性が存在することが、開発 元のMicrosoftより発表されました。本脆弱
--------------------------------------------------------------------- ■BIND 9.8.xのResponse Policy Zones(RPZ)機能の実装上のバグによる namedのサービス停止について - バージョンアップを強く推奨 - 株式会社日本レジストリサービス(JPRS) 初版作成 2011/07/05(Tue) 更新 2011/07/08(Fri) (ISCの日本語情報/JPCERT/CCの注意喚起へのリンク追加) --------------------------------------------------------------------- ▼概要 BIND 9.8.xのResponse Policy Zones(RPZ)機能には実装上のバグがあり、 namedのリモートからのクラッシュ(サービ
--------------------------------------------------------------------- ■(緊急)BIND 9.xの脆弱性を利用したサービス不能(DoS)攻撃について - キャッシュ/権威DNSサーバーの双方が対象、バージョンアップを強く推奨 - 株式会社日本レジストリサービス(JPRS) 初版作成 2011/07/05(Tue) 更新 2011/07/08(Fri) (ISCの日本語情報/JPCERT/CC/JPNICの注意喚起へのリンク追加) --------------------------------------------------------------------- ▼概要 BIND 9.xには実装上の不具合があり、namedに対するリモートからのサービ ス不能(DoS)攻撃が可能であることが、開発元のISCより発表され
今回は、DNSSECの検証機能を有効にしたキャッシュDNSサーバを構築・運用する方法について解説する。 DNSSECにおけるキャッシュDNSサーバの役割 キャッシュDNSサーバは、名前解決を依頼するクライアントと権威DNSサーバの間に立ち、反復検索を行うサーバである。DNSSECにおいて検証を担当するものを「バリデータ(Validator)」と呼び、多くの場合キャッシュDNSサーバがバリデータを担当する。 第2回でも簡単に説明したが、DNSSECの検証を行うためには信頼の連鎖の起点となる情報が必要となる。これを「トラストアンカー(Trust Anchor)」と呼ぶ。バリデータとなるキャッシュDNSサーバは、トラストアンカーを起点に、DNSSECの信頼の連鎖を検証していくことになる。 DNSの階層構造における委任の起点がルートゾーンであることから、一般的にはルートゾーンの公開鍵情報をトラスト
--------------------------------------------------------------------- ■(緊急)BIND 9.xのネガティブキャッシュ機能の実装上のバグによる namedのサービス停止について - バージョンアップを強く推奨 - 株式会社日本レジストリサービス(JPRS) 初版作成 2011/05/27(Fri) 更新 2011/06/01(Wed) (ISC発表文書の更新を反映) --------------------------------------------------------------------- ▼概要 BIND 9.xのネガティブキャッシュの取り扱いには実装上のバグがあり、 namedのリモートからのクラッシュ(サービス停止)が可能であることが、 開発元のISCより発表されました。本脆弱性により、提供者が意図し
DNSSECが提供するもの 第1回で説明したとおり、DNSSEC(Domain Name System Security Extensions:DNSセキュリティ拡張)を導入すれば、DNSの応答が「本当に正しい」ことを検証できる。 「本当に正しい」とは、どういう状態を意味するのだろうか? 正しいことを検証するには、以下の2つの事項を検証できればよい。 ・データの出自認証(Data origin authentication) →ゾーンの管理者が登録したとおりの内容であること ・データの完全性(Data integrity) →通信途中で応答が書き換えられたり、応答の一部が損失したりしていないこと DNSSECの機能は、従来のDNSの仕組みを拡張する形で実装しており、従来のDNSと上位互換性を保っている。具体的な仕組みは後述するが、DNSSECに対応した権威DNSサーバおよびゾーンの検証は、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く