カゴヤ・ジャパンは個人情報保護に関するJIS規格 (JIS Q 15001)に準拠した体制を構築。 お客様の個人情報保全に全力で努めております。
--------------------------------------------------------------------- ■BIND 9.xの脆弱性(DNSサービスの停止)について(2015年2月19日公開) - DNSSEC検証を実施しているDNSサーバーのみ対象、バージョンアップを強く推奨 - 株式会社日本レジストリサービス(JPRS) 初版作成 2015/02/19(Thu) --------------------------------------------------------------------- ▼概要 BIND 9.xにおける実装上の不具合により、namedに対する外部からのサービ ス不能(DoS)攻撃が可能となる脆弱性が、開発元のISCから発表されました。 本脆弱性により、提供者が意図しないサービスの停止が発生する可能性があ ります。 該当する
--------------------------------------------------------------------- ■(緊急)BIND 9.10.xの脆弱性(DNSサービスの停止)について(2014年6月12日公開) - キャッシュ/権威DNSサーバーの双方が対象、バージョンアップを強く推奨 - 株式会社日本レジストリサービス(JPRS) 初版作成 2014/06/12(Thu) --------------------------------------------------------------------- ▼概要 BIND 9.10.xにおける実装上の不具合により、namedに対する外部からのサー ビス不能(DoS)攻撃が可能となる脆弱性が、開発元のISCから発表されまし た。本脆弱性により、提供者が意図しないサービスの停止が発生する可能性 があります。
--------------------------------------------------------------------- ■(緊急)BIND 9.xの脆弱性(DNSサービスの停止)について(2013年7月27日公開) - キャッシュ/権威DNSサーバーの双方が対象、バージョンアップを強く推奨 - 株式会社日本レジストリサービス(JPRS) 初版作成 2013/07/27(Sat) --------------------------------------------------------------------- ▼概要 BIND 9.xにおける実装上の不具合により、namedに対する外部からのサービ ス不能(DoS)攻撃が可能となる脆弱性が、開発元のISCから発表されました。 本脆弱性により、提供者が意図しないサービスの停止が発生する可能性があ ります。 注意:既に
--------------------------------------------------------------------- ■BIND 9.8.x/9.9.xにおけるDNS64の実装上のバグによるnamedの サービス停止について(2012年12月5日公開) - バージョンアップを強く推奨 - 株式会社日本レジストリサービス(JPRS) 初版作成 2012/12/05(Wed) --------------------------------------------------------------------- ▼概要 BIND 9.8.x/9.9.xにおけるDNS64の実装上のバグにより、namedに対する外部 からのサービス不能(DoS)攻撃が可能となる脆弱性が、開発元のISCから発 表されました。本脆弱性により提供者が意図しないサービスの停止が発生す る可能性があ
RDATAフィールドの長さが0であるようなDNSのリソースレコードによって、それを処理するサーバに種々の障害が生じる可能性があります。 CVE: CVE-2012-1667 文書バージョン: 1.0 公開日付: 2012年6月4日 影響を受けるプログラム: ISC BIND 影響を受けるバージョン: すべてのバージョンの BIND 9 深刻度: 重大な(Critical) 攻撃方法: 遠隔から可能 詳細: 本問題は試験的なDNSのレコード型のテスト中に発見されました。BINDにはヌル(つまり長さが0の)RDATAを持つレコードを追加することが可能です。 このようなレコードを処理することで、想定外の結果が生じる可能性があります。キャッシュ(recursive)サーバの場合、サーバがクラッシュしたり、サーバメモリ内の情報がクライアントに開示されたりする可能性があります。セカンダリサーバの場合、
こうすることで、jpゾーンを管理するDNSサーバは、example.jpドメインのホスト情報までは知らなくても、どのDNSサーバに問い合わせれば答えが得られるかを指し示すことができます。問い合わせを行うリゾルバは、問い合わせ先DNSを変更して再度ホスト情報の問い合わせを行います。 ゾーン情報(例ではexample.jp)を持つDNSサーバのアドレスやホスト名を、その上位ドメイン(例ではjp)のゾーン情報を管理するDNSサーバに登録する手順こそが「委任」(delegation)です。 上位ドメインを管理する側(以降「親」)は、その下位ドメイン(以下「子」)のゾーン情報をすべて持たず、子のゾーン情報が得られるDNSサーバのみを把握しています。つまり、「子ゾーンに関する情報は××DNSサーバに聞いてくれ」と、権限を委譲するわけです。これにより、親サーバが子ゾーンの情報であふれることなく、また子サ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く