（緊急）BIND 9.xの脆弱性（DNSサービスの停止）について（2015年7月8日公開）
--------------------------------------------------------------------- ■（緊急）BIND 9.xの脆弱性（DNSサービスの停止）について（2015年7月8日公開） - DNSSEC検証が有効に設定されている場合のみ対象、バージョンアップを強く推奨 - 株式会社日本レジストリサービス（JPRS） 初版作成 2015/07/08（Wed） --------------------------------------------------------------------- ▼概要 BIND 9.xにおける実装上の不具合により、namedに対する外部からのサービ ス不能（DoS）攻撃が可能となる脆弱性が、開発元のISCから発表されました。 本脆弱性により、提供者が意図しないサービスの停止が発生する可能性があ ります。 該当
BIND 9.7.x/9.8.xのトラストアンカー自動更新機能の実装上のバグについて
--------------------------------------------------------------------- ■BIND 9.7.x/9.8.xのトラストアンカー自動更新機能の実装上のバグについて - バージョンアップを推奨 - 株式会社日本レジストリサービス（JPRS） 2011/09/01（Thu） --------------------------------------------------------------------- ▼概要 BIND 9.7.x/9.8.xでは実装上のバグにより、DNSSECバリデーター（キャッシュ DNSサーバー）におけるトラストアンカー自動更新の処理において不具合が 発生する可能性があったことが、開発元のISCより発表されました。該当す るBIND 9において本機能を有効に設定している場合、ルートサーバーにおい て
キャッシュDNSサーバのDNSSEC対応
今回は、DNSSECの検証機能を有効にしたキャッシュDNSサーバを構築・運用する方法について解説する。 DNSSECにおけるキャッシュDNSサーバの役割 キャッシュDNSサーバは、名前解決を依頼するクライアントと権威DNSサーバの間に立ち、反復検索を行うサーバである。DNSSECにおいて検証を担当するものを「バリデータ（Validator）」と呼び、多くの場合キャッシュDNSサーバがバリデータを担当する。 第2回でも簡単に説明したが、DNSSECの検証を行うためには信頼の連鎖の起点となる情報が必要となる。これを「トラストアンカー（Trust Anchor）」と呼ぶ。バリデータとなるキャッシュDNSサーバは、トラストアンカーを起点に、DNSSECの信頼の連鎖を検証していくことになる。 DNSの階層構造における委任の起点がルートゾーンであることから、一般的にはルートゾーンの公開鍵情報をトラスト
DNSSECの役割と動作の概要
DNSSECが提供するもの 第1回で説明したとおり、DNSSEC（Domain Name System Security Extensions：DNSセキュリティ拡張）を導入すれば、DNSの応答が「本当に正しい」ことを検証できる。 「本当に正しい」とは、どういう状態を意味するのだろうか？ 正しいことを検証するには、以下の2つの事項を検証できればよい。 ・データの出自認証（Data origin authentication） →ゾーンの管理者が登録したとおりの内容であること ・データの完全性（Data integrity） →通信途中で応答が書き換えられたり、応答の一部が損失したりしていないこと DNSSECの機能は、従来のDNSの仕組みを拡張する形で実装しており、従来のDNSと上位互換性を保っている。具体的な仕組みは後述するが、DNSSECに対応した権威DNSサーバおよびゾーンの検証は、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
2011年 | 技術レポート・ライブラリ | 研究・開発 | IIJ
ドメイン名やDNSの解説 | ドメイン名関連情報 | JPRS
