「DNSの浸透」という表現が結構よく使われています。 DNSに設定された情報を更新したけれど、その結果がなかなか反映されずに誰かに相談すると「DNSの浸透には時間がかかります」と説明されて納得してしまうという事例が多いようです。 しかし、うまく準備を行えば、実際の切り替え処理は、いつ完了するのかが不明な「DNSの浸透」を待つのではなく、事前に計画した時間通りに完了させることが可能です。 さらに、本来であればDNS情報の設定者(ゾーン情報の設定者)は、いつまでに世界中のキャッシュが更新されるかを知ることができる環境にあり、それ以降も更新がされていなければ「何かがおかしい」とわかるはずです。 DNSにおける設定内容(DNSのリソースレコード)には、その情報をキャッシュとして保持し続けても良い期間であるTTL(Time To Live)という要素がありますが、TTLはDNS情報設定者が自分で設定
ここ数日、8.8.8.8や8.8.4.4というIPv4アドレスを持つGoogle Public DNSに関する話題が盛り上がっているのですが、多くの人が「よくわからないけど設定変更したら早い!」と言っているので、そこら辺の話を調査してみました。 昨日、Twitterとブログでtracerouteやdigによる調査協力のお願いを発信し、8.8.8.8へのtracerouteを37件、8.8.8.8とISP DNSへのtraceroute比較及びAkamaiキャッシュサーバへのtraceroute比較を21件、日本各地及び海外のいくつかの地点からご協力頂けました(皆様ありがとうございました!)。 それらのデータをもとに、Google Public DNSを利用した場合の通信経路と、それによる遅延に関する検証を行いました。 Google Public DNSに対する私の感想 まず最初に。 調査前
Netの世界に転がる、様々なネタを見ては楽しむ、「Newsサイト」として、最近ほぼ毎日拝見している 「Gizmodo Japan」 のエントリーに、妙な記事が載っていた。 WWWへのアクセス権を持つ7人 http://www.gizmodo.jp/2010/07/seven-people-have-been-entrusted-with-the-keys-to-the-internet.html 抜粋: 上の画にあるこのカード。世界で7人だけが保持している、大災害時にWold Wide Webを再起動させる力を持つカードなのです。 んなアホな、Netの世界にシングルエンドポイントSingle Point of Failure(SPOF)(1箇所のシステムがサービスを提供できなくなると、システム全体が止まる)がある訳無いし、ましてやWWW−http/httpsプロトコル限定とか有り得ない!
computerworld.jpは3月17日に『2010年に最も警戒すべきセキュリティ脅威は「DNSリバインディング」』と題した記事を公開したが、一部誤報があるので訂正する。 米国White Hat Securityの研究者らがまとめた2010年版の深刻なセキュリティ脅威トップ10では、DNSリバインディングが1位となった。同社では、2006年から毎年、脅威トップ10を発表している。 http://www.computerworld.jp/news/sec/177029.html 当初、この記事を読んで違和感を覚えた。DNSリバインディングという攻撃手法そのものは以前から知られているものであるし、この記事で説明されている脅威の内容についても、以前から知られているものと違わない。このタイミングでなぜ、DNSリバインディングがもっとも警戒すべきなのか。このため、この記事の裏を取ってみようと思っ
昨日のTwitterクラック事件はDNSに不正な値を設定されたことが原因でした。 Twitter公式ブログでも以下のようにDNSが原因であり、本体が乗っ取られたわけではないと記述されています。 「Twitterブログ: 昨日のDNS障害についての追加情報」 この攻撃の間、われわれはDNSプロバイダのDynectと直接連絡を取り続けました。そしてDNSをできるだけ素早くリセットするよう緊密に作業しました。 これを見たときに「ああ、やっぱりDynectが原因だったか」と思いました。 恐らくTwitterは自分でネットワークやサーバをほとんど運営しておらず、DNS部分はCDN事業者のDynIncのサービスを購入していると推測されます(参考:Twitterのネットワーク構成を調べてみた)。 さらに、「CDN事業者のDynectにとってTwitterでの事件は経営に凄く大きな打撃を与えるのでは?」と
前回書いたGoogle Public DNSに関する記事があまりに説明不足なので、補足文章を書く事にしました。 今回のGoogle Public DNSは、単なるオープンDNSサービスでは留まらず滅茶苦茶凄過ぎていて、ある意味インターネット全体のありかたを変えてしまう可能性さえあると個人的には思っています。 何故そう思っているかを含めて、色々書いてみました。 以下の文章は多くが公式発表からの引用ではなく、その他の外部観測情報を元にした推測や個人的な妄想が入り交じっているので、内容に関しては各自で考えて判断をお願いします。 Google Public DNSでウェブ閲覧が高速化するの? とりあえず、背景や技術はどうでも良いから「高速化するかしないかだけ知りたい」という方々が非常に多い気がするので、個人的なGoogle Public DNS高速化に関しての考えを最初に書きます。 「Google
Google Public DNSが発表されていました。 「Official Google Blog: Introducing Google Public DNS」 本当は書籍執筆〆切に追われていて首が回ってないはずなのですが、あまりに面白そうなので思わず調べてしまいました。 これって、DNSキャッシュのクラウド化なのだろうと思います。 利点は? 利点は「パフォーマンス向上」と「セキュリティ向上」の2つがあるようです。 パフォーマンス Performance Benefits http://code.google.com/intl/ja/speed/public-dns/docs/performance.html 原稿〆切がヤバくて、ざっと流し読みをしただけなのであまり自信がありませんが、どうも世界規模で運用して、世界的にQueryが多い所を優先的にキャッシュ更新しておくので、非常に効率が
米国Googleが、先日、Google Public DNSの提供を実験的に開始した。昨日、日本のユーザーが、Googleの無料IMEで盛り上がったように、海外(米国)ユーザーは、この話題で盛り上がっているようだ。 これは、OpenDNSのようなサービスで、プロバイダが提供するDNSの代わりに使う事ができ、公式ブログでは、高速なGoogleのPublic DNSを使う事で、頻繁に発生するDNSルックアップの遅延が解消され、ブラウザの速度などを上げる事ができるなどとしている。 但し、これは米国の場合であって、対象を日本などは考慮していない。OpenDNSの場合も、距離が遥かに遠い海外サーバーにまでDNSを参照すれば、結果的に日本では遅く、使い難いなどの指摘もある。 そこで、日本では、Google Public DNSが速いかどうか試して見た。 Google Public DNSの設定法 以下
自宅で Mac Book Air を使い始めた当初、一番イライラしていたのが「ブラウザの読み込みが遅い」という問題で、それを解決してくれていたのは dolipo というプロキシソフトでした。 ウェブを閲覧するときに「・・・のアドレスを解決しています」とブラウザのステータスバーに出るのですが、dolipo を使っている場合はそのメッセージの表示時間が短く、使っていない場合はすごく長く表示されていました。 なので、ボトルネックになっていたのは DNS ルックアップのところなんだろうなぁと思っていたのです。 そんな DNS ルックアップが遅いという問題を強力に解決してくれるのが、 Google Public DNS です。 早速 DNS サーバーのアドレスに「8.8.8.8」と「8.8.4.4」を設定して、dolipo を切って接続してみたところ、まるで dolipo を使ってるかのような速さに
IPv6とDNS DNSのIPv6対応には、2つのポイントがあります。IPv6パケットで、問い合わせを処理できるか、つまりIPv6トランスポートに対応しているかという点と、IPv6対応のレコードに対応しているかという点です。 今は、ほとんどのサーバで実装されているので、どちらも問題ありません。 DNSのサーバは、大きく2つに分けられます。ゾーン情報を保持しているコンテンツサーバと、クライアントの参照に利用されているキャッシュサーバです。 参照用のキャッシュサーバは、IPv6トランスポートにさえ対応すれば、名前解決してくれます。コンテンツ側はトランスポートの対応の他、IPv6対応のレコードを記述する必要があります。 IPv6では、正引きにAAAAレコードを、逆引きにはPTRレコードを利用します。正引きは、これまで通り設定したいホスト名にAAAAレコードでIPv6アドレスを設定すれば完了です。
先日IIJの一日インターンに行ってきました。 NDAがあるので、事細かに書くことは出来ないのですが、教育的なプログラムが組まれていて非常に面白かったです。 そこで、色々お話しして、その中でDNSポイズニングがなかなか対応されない理由、当たり前の理由が聞けたので、「DNSポイズニングって何がヤヴァイのか良くわかんね」って人に向けた簡単な解説とあわせて書きたいと思います。 まず、DNSキャッシュポイズニングの何が怖いか? 簡単に言うと、 「googleに繋いだはずが全く別サイトに繋がっちゃう!」 って話です。 本当に繋ぎたいサイトと違うサイトに繋いじゃう事が出来るので、例えば 実在するショッピングサイトそっくりの偽サイト作って、ショッピングさせて。クレジットカードの番号ゲットしちゃったり、住所ゲットしちゃったり。 夢が広がる怖い事が出来ちゃいます。 きちんとしたセキュリティ対策していれば大丈夫
馬鹿じゃないのか。このようなセキュリティに関わる情報公開ページは https:// で提供する(閲覧者が望めば https:// でも閲覧できるようにする)のが当然なのに、携帯電話会社ともあろうものが、そろいもそろってこんな認識なのだ。 (8月2日追記: ソフトバンクモバイルについては「7月27日の日記に追記」参照のこと。) それをまた、ケータイWeb関係者の誰ひとり、疑問の声をあげていないことがまた、信じ難い。何の疑問も抱かずにこれをそのまま設定しているのだろう。 こんな状態では、ケータイWebの運営者は、DNSポイゾニング等で偽ページを閲覧させられても、気付かずに、偽アドレス入りの帯域表を信じてしまうだろう。 つまり、たとえば、example.jp というケータイサイトを運営している会社が example.co.jp であるときに、攻撃者は、example.co.jp のDNSサーバに
フィッシング詐欺などでよくあるDNSの書き換えに対してより安全で、なおかつDNS解決の速度が素早いのでネットの閲覧が快適になり、さらに「~~.com」を「~~.cmo」とミスって入力しても正しいサイトに誘導してくれる、らしい。 利用は無料。設定方法などの詳細は以下の通り。 OpenDNS | Providing A Safer And Faster DNS http://www.opendns.com/ 優先DNSを「208.67.222.222」にして、代替DNSを「208.67.220.220」にするだけ。ブロードバンドルータの設定画面で参照するDNSをこの2つに変更すればOK。プロバイダから提供されているDNSがあるなら速度だけで考えればそちらの方が早いと思われますが、プロバイダの方でDNSを提供してくれない場合にはこれを設定することで確かに反応速度の上昇は見込めます。 速度について
7月初旬からインターネットとセキュリティ業界を騒がせていたDNS(Domain Name System)に関する脆弱性について7月24日(米国時間)、同脆弱性の発見者であるDan Kaminsky氏がその詳細について解説した。このDNSで発見された脆弱性は、BINDからMicrosoft製品、Cisco IOSに至るまで、インターネット上で稼働しているほとんどのシステムに影響を及ぼすもの。その存在はKaminsky氏によって7月9日に公にされ、ネットワーク管理者らに対して至急ベンダーからリリースされた対策パッチを充てるように通達が出されていた。脆弱性の詳細についてはハッカーらの悪用を避けるために8月初旬に米ネバダ州ラスベガスで開催される「Black Hat」まで公開されない予定だったが、22日になり別の研究者により脆弱性の内容がオープンにされてしまったこともあり、急遽24日での情報公開とな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く