なぜ、DNSはキャッシュポイズニング攻撃の危険に（まだ）さらされるのか
なぜ、DNSはキャッシュポイズニング攻撃の危険に（まだ）さらされるのか：管理者、そしてユーザーにできる対策は？（1/2 ページ） 日本レジストリサービス（JPRS）は2014年4月15日に、「キャッシュポイズニング攻撃の危険性増加に伴うDNSサーバーの設定再確認について」という緊急注意喚起を公開した。この文書の背景とDNSサーバーに求められるセキュリティ対策について、JPRSに聞いた。 2014年4月15日、日本レジストリサービス（JPRS）が「キャッシュポイズニング攻撃の危険性増加に伴うDNSサーバーの設定再確認について」という緊急の注意喚起を公開した（関連記事）。この注意喚起の意味するところは幾つか考えられるが、最も重要なのは、今もなお10％程度残っていると発表された危険なキャッシュDNSサーバーの存在であろう。 今も残っている危険なキャッシュDNSサーバー 今回公開された注意喚起は、
デュアルスタック環境での名前解決（前編）
（2）DNSサーバ側の問題点の確認 次に、DNSサーバの状態について、以下のポイントを確認しましょう。 自動的に登録されるAAAAレコードと手動登録が必要なAAAAレコード 逆引きゾーンの必要性 DNSサーバ、dc001に登録されているリソースレコードを確認します。WindowsのActive Directory環境では、デフォルトでダイナミックDNS（DNS動的更新）機能が有効化されています。このため、リンクローカル以外のIPv6アドレスがWindowsコンピュータに自動または手動で割り当てられると、図2のようにAおよびAAAAリソースレコードも自動的に登録されます。しかし、ネットワークデバイスはダイナミックDNSに対応していないため、ネットワークデバイスのリソースレコードは登録されません。 次に、現在のゾーンを確認します。DNSでは、ホスト名を基にIPアドレスを調べるときに使うゾーンを
第7回 IPv6とDNSサーバ
ホスト名からIPv6アドレスを求めたり、その逆を行うには、IPv6に対応したDNSサーバを利用する。Windows ServerのDNSサーバでIPv6を扱う方法を解説する。特に逆引きゾーンの設定方法に注意する。 連載目次 前回は、LLMNRというWindows OS独自の名前解決機能について紹介した。今回は、より汎用性の高いDNSv6を使った名前解決について取り上げる。 IPv6のDNSとは？ IPv6の名前解決手段として、前回は「LLMNR（Link-Local Multicast Name Resolution）」を取り上げた。これは、単一のネットワーク・セグメント上でのIPv6マルチキャストを使った簡易な名前解決メカニズムである。利用にあたっては何の準備もいらず、名前解決のためのサーバなどを用意する必要もない。 だがLLMNRは簡便だが、ルータを越えたネットワークをまたいで名前解決
LinkedInでアクセス障害、原因はDNSハイジャックとの指摘
6月20日、ビジネス向けSNSのLinkedInが、「DNSの問題」により約1時間にわたってアクセスできなくなる事態が発生した。障害発生時はLinkedInにアクセスしてもドメイン販売用のページが表示される状態になっていたが、現在ではほぼ復旧しているという。 LinkedInはこれまでのところ、Twitterでの発言以外には詳細を明らかにしていない。 app.netの共同創設者、Bryan Berg氏はその原因を「DNSハイジャック」によるものではないかと指摘している。Berg氏は、「その間LinkedInにアクセスしたユーザーのトラフィックは、Confluence-Networksがホスティングしていたネットワークに送信されていた」と述べ、しかもサイトではSSLを利用していなかったことから、長い有効期限が設定されていたCookieが平文のまま送信された可能性があるとしている。 SANSは
NAT64でIPv6端末をIPv4サーバにつなげよう（1/2） - ＠IT
最終回 NAT64でIPv6端末をIPv4サーバにつなげよう A10ネットワークス株式会社 山村剛久 2012/5/29 これまでのIPv4アドレス在庫で「枯渇の日」を乗り切ったとしても、もう新たな割り当てはありません。この連載では、徐々に顕在化してくると思われるIPv4アドレス枯渇問題を乗り切り、段階的にIPv6対応を進めていく手助けとなるIPv6移行ソリューションを紹介します。（編集部） 一台二役を果たす「NAT64/DNS64」 前回の記事では、SLB-PT（IPv6→IPv4）という手法を用いてIPv6端末からIPv4サーバにアクセスする方法を説明しました。意外と簡単にIPv4サーバをIPv6化できることを実感いただけたかと思います。 ただSLB-PTの場合、IPv4サーバはSLB-PTをサポートしたロードバランサの配下に設置し、かつSLBにサーバのIPv4アドレスを設定しなければ
権威DNSサーバのDNSSEC対応
インターネットの重要な基盤技術の1つであるDNSに対して新たな攻撃手法が公開され、その安全性が脅かされている。DNSにセキュリティ機能を提供するための技術であり、普及が進んでいるDNSSECについて、仕組みと運用方法を紹介する。（編集部） 古くから検討されてきたDNSSEC 近年注目を集めているDNSSECだが、実はその検討は1993年ごろから始まっている。また、最初の標準としてRFC 2065が発行されたのは1997年のことである。 それから継続して検討が進められ、現在のDNSSECの技術仕様は、2005年に発行されたRFC 4033、RFC 4034、RFC 4035（注1）がベースとなっている。これに加え、第3回でも触れたキャッシュDNSサーバにおけるトラストアンカーの自動更新の仕様を定めたRFC 5011が2007年に、またゾーンの列挙を困難にするためのNSEC3拡張を定めたRFC
始めてみよう、Amazon Route 53（1/2） － ＠IT
設定ファイルと格闘せずにDNSを運用管理 始めてみよう、Amazon Route 53 並河 祐貴 株式会社サイバーエージェント 2011/6/23 Amazon Web Services（AWS）の「Amazon Route 53」は、API経由でDNSの運用管理を可能にするサービスです。Firefoxのアドオン「R53 Fox」を使って、その導入、設定を行う方法を紹介します（編集部） Webサイト運用に欠かせないDNS 今日、一般に公開されているWebサイトでは、IPアドレスを直接公開するケースはほとんどありません。多くのケースでは、ドメイン名（「google.co.jp」や「yahoo.co.jp」など）を公開し、ユーザーはそのドメイン名を基にブラウザでURLを入力したり、検索したりしてアクセスすることとなります。 そのためWebサイトの運用に当たり、ドメイン名とIPアドレスをひも付
キャッシュ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ページを開く
