本日、JPRSが緊急の注意喚起を公表しました。 緊急）キャッシュポイズニング攻撃の危険性増加に伴うDNSサーバーの設定再確認について（2014年4月15日公開）- 問い合わせUDPポートのランダム化の速やかな確認・対応を強く推奨 それに対して、2月中旬に脆弱性を発見してJPRSへと報告していた鈴木氏(脆弱性は前野氏との共同発見)が、JPRSの注意喚起では「危険性をよく理解して対策をとるにあたって十分な情報が含まれているとはいえません」として、以下の情報を公開しています。 開いたパンドラの箱 - 長年放置されてきたDNSの恐るべき欠陥が明らかに キャッシュポイズニングの開いたパンドラの箱 キャッシュポイズニングの開いたパンドラの箱 - 2 - 本来であれば、より上位からの正規の回答が優先されなければならないはずなのに、下位側が優先される仕様になっているので、偽装されたデータが優先されてしまう

今日(4月30日頃)、一部の人々の間で「うちのWebサイトで使ってる.inの名前解決が出来なくなった！」という悲鳴が聞こえています。 数年前、インドのccTLD(country code Top Level Domain)である「.in」を日本国内のWebサービスで使うのが流行しました。 「.in」は「イン」と読めるため語呂が良く、個人が気軽にWebサイトを作ったときに、ドメイン名も同時に登録するというのが流行ったわけですが、そのときにwhoisで世界に向けて連絡先(個人であれば氏名住所電話番号の場合もあり)を公開されるのは嫌だということで、whois情報公開代行サービス(もしくはプライバシー保護サービス)を使うというのが割と一般的に行われていました。 しかし、その.inのレジストリであるINRegistryが、whois情報公開代行サービスを利用しているドメイン名を次々と停止しているよう

DNS Summer Days 2013の初日最後のセッションで面白い話が公表されていました。 JPCERT/CCに対して「うちのDNSが攻撃されています。助けて下さい」という問い合わせが来ることがあるらしいのですが、調べてみるとその大半がDDoSの踏み台として使われているのであって、実際は攻撃に加担してしまっているというものでした。 他者を攻撃するトラフィックを生成することで、自身の回線やサーバに負荷がかかってしまっている状態が凄くよくあるそうです。 「助けて！」と言っている人が、意図せずに誰でも使えるオープンリゾルバとして設定されており、攻撃者の踏み台にされているというものです。 キャッシュDNSサーバの設定を変更し、オープンリゾルバをやめると問題が解決することが多いとのことでした。 今年に入ってから、オープンリゾルバがDDoS攻撃の踏み台にされる話がインターネット通信業界で話題です。

先週、忍者ツールズ全サービスが一時的に利用できなくなりました。 株式会社サムライファクトリー：忍者ツールズ全サービスが表示不可となる障害につきまして お名前.com：忍者ツールズ全サービスが表示不可となる障害につきまして 本の虫: DNSの終焉が垣間見える、ぶっ飛んでて危険すぎるお名前.comの検閲事件 その理由として、株式会社サムライファクトリー(忍者ツールズ)のプレスリリースには以下のようにあります。 忍者ツールズのサービスを利用したユーザーサイトの一部に、お名前.comの約款に抵触するサイトがあり、お名前.comへのお問い合わせが複数あったため、約款に基づきお名前.comでは一時的にドメインの停止措置をとる対応を行いました 個人的な感想としては、忍者ツールズのドメイン停止措置事件は今までにない新しいタイプのものであると思いました。 まず、お名前.comとninja.co.jpに関して

「浸透いうな！」という掛け声が一部界隈で有名な「DNS浸透問題（もしくは、DNS浸透いうな問題）」ですが、今年2月にDNS浸透問題の原因の一つとなっている現象と同じものに起因する新たな脆弱性が発表されました。 その名は「幽霊ドメイン名脆弱性(ghost domain names)」です。 一見、DNS浸透問題とは全く別の問題のように思える「幽霊ドメイン名脆弱性」ですが、それが発生する原因と状況をよく見ると、「あ！これってDNS浸透問題で言ってた話と同じ原因だよね！？」とわかります。 実際、後述する通り、幽霊ドメイン名脆弱性の発想をDNS浸透問題と組み合わせることで、他人のDNS引っ越しを妨害するDoS攻撃も可能になります。 そう考えると、問題発生原因を調べずに「DNSの浸透をお待ち下さい」で済ませてしまうのは脆弱性の放置であるという考え方もできそうです(*1)。 ここでは、幽霊ドメイン名脆

さきほど「DNSの浸透」に関して書いたのですが、それに対して「でもTTLを無視するDNSキャッシュサーバがいるから仕方がない」というような反応が一定数登場しています。 「浸透」の話になると、そのような話がほぼ必ず登場するのですが、実際に「この製品がTTLを無視する」とか「このISPで運営されているDNSキャッシュサーバはDNSプロトコルに違反している」という具体例をいまのところ見た事がありません。 「そういう困ったDNSキャッシュサーバも居るんだよ」とか「でもTTLを越えたあとも旧IPアドレスにアクセスあるもん」という感じの主張が多いです。 そんなところにsumikawaさんから以下のようなTweetを頂きました。 確かに、DNSの世界におけるTTL情報はアプリケーションには届かないので、権威DNSサーバのTTLを事前に小さくしたとしても、アプリケーションが持っているキャッシュは制御ができ

「DNSの浸透」という表現が結構よく使われています。 DNSに設定された情報を更新したけれど、その結果がなかなか反映されずに誰かに相談すると「DNSの浸透には時間がかかります」と説明されて納得してしまうという事例が多いようです。 しかし、うまく準備を行えば、実際の切り替え処理は、いつ完了するのかが不明な「DNSの浸透」を待つのではなく、事前に計画した時間通りに完了させることが可能です。 さらに、本来であればDNS情報の設定者(ゾーン情報の設定者)は、いつまでに世界中のキャッシュが更新されるかを知ることができる環境にあり、それ以降も更新がされていなければ「何かがおかしい」とわかるはずです。 DNSにおける設定内容(DNSのリソースレコード)には、その情報をキャッシュとして保持し続けても良い期間であるTTL(Time To Live)という要素がありますが、TTLはDNS情報設定者が自分で設定

以前、オーム社開発部の出版体制を取材しましたが、今回、私自身がそのシステムを使って本を書きました。 Subversionでバージョン管理をしつつLaTeXで本を書く形式です。 複数人で本を書く時にバージョン管理ツールを使わないと、誰がどこをどういじったのかがわからなくなったり編集箇所が競合する場合が多いのですが、Subversionを使うことでそれらが解決可能です。 さらに、筆者か編集者のうちの誰かがsvn commitを行って最新版を更新すると、それに連動して最終原稿として印刷所に入稿されるものと同じ形のPDFが自動的に生成され、DTP作業がゼロになるとともに、筆者がアウトプットを細かく確認ができるという特徴もあります。 しかも、Subversionのコミットメールを編集者側も見ていて、該当部分に対する編集やコメントがすぐに投入され、こちらが文章を書いた数分後に編集側意見が含まれるPDF

最近良くわからないことがあります。 学生に対して「できるうちに勉強して技術を身につけといた方がいいよ」というアドバイスをするときに、「何故技術を身につけるの？」というのを明確に説明する方法です。 あまりに話が漠然としてしまうので、結果として単なるうるさい小言のようになってそうな気がしてます。 恐らく、こういう話は文章にしてまとめた方が考えが述べやすいと思ったので、文章にしてみました。 新卒エンジニアを取り巻く環境 最近は昔よりも大学在学中に求められるものが大きくなっている雰囲気を感じています。 いくつかの企業の方々からお話を伺う機会があり、エンジニア採用の現場は徐々に変わって来てるんだなぁというのが感想です。 まず、ある一定規模以上の企業の方々は大抵「採用できない。いいエンジニアが来てくれない」という話をしているイメージがあります。 先月、エンジニア採用に関して以下のようなニュースが話題に

先日の「中国国内ルートDNS停止事件 雑感」の続報です。 I Root Serversを運用管理するNetNod社CEOのLindqvist Kurt Erik氏がdns operationsメーリングリストに調査の経過に関する情報を送信しました。 まだ調査は続行中のようですが、ひとまずNetNod社が把握している状況が声明として公開された形です。 「[dns-operations] Odd behaviour on one node in I root-server (facebook, youtube & twitter)」 これを読んだ感想ですが、思ったよりもややこしい話になるかも知れませんね。 場合によっては、中国からi.root-servers.netが撤退せざるを得ない状況が生まれてしまうのかも知れません。 以下、中国のDNSルートサーバ事件のその後と、それに関する私の妄想です

先日、「中国国内に配置される、DNS ルート･サーバーが閉鎖された？: Agile Cat ― Azure & Hadoop ― Talking Book 」が、はてなブックマーク上で話題になっていました。 さらに、「インターネットインフラ界のネタフル」的存在だと勝手に私が考えているyebo blogさんの記事も話題になっていました「中国にあるDNSルートサーバが不審な動きをして停止」。 最初にニュースを見た時には、結構衝撃を受けたのですが、今回の事件に関して色々調べてみた結果、実はかなりショボイ事件なのではないかと思い始めました。 今回の事件は、何か新しいものというわけではなく、単なるオペミスで数年前から存在している体制が漏れただけっぽい気がします。 個人的な私の雑感ですが今回の件は、「中国国内用のインターネット検閲システムが中国国外に漏れた結果、チリのISPに影響が出た。I DNSルー

３回目のgTLD追加は、過去２回のように個別のgTLDを発表するのではなく、申請者が任意のgTLDを申請できるようにするという方向性でした。 これにより、過去２回とは異なり、募集期間が区切られなくなり、gTLD数の上限も撤廃されました。 申し込みに必要な条件が従来に比べて大幅に緩和されたという特徴もあります。 このようなgTLD導入プログラムの勧告がICANNに提出されたのが2007年9月で、ICANN理事会にて承認されたのが2008年6月です。 その後、「新たなgTLD応募者用ガイドブック草案(Draft Applicant Guidebook、現在はバージョン３)」が公開／改訂されていきました。 このgTLD導入プログラムの申請開始は今年中に行われる予定のようです。 gTLDにも、意義申し立てや紛争処理などの仕組みはありますが、基本的にクレームが発生した後の対応となります。 ドメインの

ネット接続サービス事業者に海賊版を自動検出する技術の導入を義務付けすることを検討するための作業部会設置され、来月中間報告が発表されるようです。 まだ、詳細な資料を知らないので、以下の文章は単なる私の妄想ではありますが、これって結構影響範囲がデカイ気がします。 「ネット接続サービス事業者(プロバイダー)」という単語を見て「なんだISPだけなんだ」と思うかも知れませんが、プロバイダ責任制限法的な視点では「特定電気通信役務提供者」としてWebホスティング業者やWeb管理者も含まれます。 さらに、「特定電気通信役務提供者」が個人か法人かも問いません。 そのため、この作業部会の議論が下手な方向に行くと日本国内でCGM(Consumer Generated Media)を運用するには海賊版対策が必須となる可能性もありそうだと思いました。 記事が非常に短いので全文転載になってしまいますが、以下が日経の記

先月発表されたGoogle Public DNSですが、課題であったCDNとの相性問題を解決すべくGoogleが、IETFでDNSに関連する標準規格提案を開始しました。 「DNS問い合わせメッセージの中にユーザ(クライアント)のIPアドレスを埋め込めるような追加を行おう！」という内容のものです。 先月サービスを発表してから次の月にはもう標準化を開始するという、このスピード感は凄いと思います。 「Google code blog : A proposal to extend the DNS protocol」 Google Public DNSそのものに関して「Google Public DNS解説と個人的妄想」を記事として書きましたが、その中でも「DNSを活用した他者CDNとの相性」という部分でGoogle Public DNSが抱えている課題を解説しています。 今回のInternet D

IT業界って怖いですね～（棒読み） 何でそうなった？ そもそもの発端は、私が現在執筆中のLinuxネットワークプログラミング書に書いているコラムのための質問でした。 Wiresharkやtcpdumpを利用したパケットキャプチャによる通信プログラムのデバッグを解説する際にプロミスキャスモードとは何かという話を書いていたのですが、その最後にちょっとしたコラムを書くためのブレストとしてTwitterで質問をしました。 で、結局出来上がった原稿は以下のような感じです。 Twitterでコラムの内容を見たいと発言されている方がいらしたので、出版前ですが晒してしまいます。 コラム：ぁゃιぃ UNIX用語 (☆ 「あやしい」の部分は、xa xya イオタ xi です。) プロミスキャスモードを「無差別モード」と訳す場合が多いのですが、この「Promiscuos」という単語は性的な意味を含む英単語なので

昨日のTwitterクラック事件はDNSに不正な値を設定されたことが原因でした。 Twitter公式ブログでも以下のようにDNSが原因であり、本体が乗っ取られたわけではないと記述されています。 「Twitterブログ: 昨日のDNS障害についての追加情報」 この攻撃の間、われわれはDNSプロバイダのDynectと直接連絡を取り続けました。そしてDNSをできるだけ素早くリセットするよう緊密に作業しました。 これを見たときに「ああ、やっぱりDynectが原因だったか」と思いました。 恐らくTwitterは自分でネットワークやサーバをほとんど運営しておらず、DNS部分はCDN事業者のDynIncのサービスを購入していると推測されます(参考：Twitterのネットワーク構成を調べてみた)。 さらに、「CDN事業者のDynectにとってTwitterでの事件は経営に凄く大きな打撃を与えるのでは？」と

15時頃からTwitterがクラックされてました。 詳しい事はわかりませんが、個人的には大規模なDNSキャッシュポイズニングか、twitter.comのDNS権威サーバが乗っ取られたような気がします。(追記：文章公開後に色々時間をかけて考えると公開した文章の矛盾点が浮かんできました。キャッシュポイズニングじゃない気がしてきました。ということで、このエントリ、色々信用できないかも知れません。書いて公開しておいて申し訳ありませんが、各自の判断で内容を読んで下さい。) 追記：Twitterクラック事件の原因？ HTML 偽twitter.comにアクセスしたときに以下のようなHTMLが返ってきていました。 (ただし、画面内に収まるように一部改行コード追加) <html> <head> <meta http-equiv="Content-Language" content="en-us"> <me

前回書いた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キャッシュのクラウド化なのだろうと思います。 利点は？ 利点は「パフォーマンス向上」と「セキュリティ向上」の２つがあるようです。 パフォーマンス Performance Benefits http://code.google.com/intl/ja/speed/public-dns/docs/performance.html 原稿〆切がヤバくて、ざっと流し読みをしただけなのであまり自信がありませんが、どうも世界規模で運用して、世界的にQueryが多い所を優先的にキャッシュ更新しておくので、非常に効率が

日本時間10月13日昼頃(現地時間21:19-22:43)にスウェーデンのインターネットが壊れました。 今年の2月に「今朝、インターネットが壊れました」と書いた時はBGPの障害でしたが、今回はDNSです。 「.se」のccTLD(country code Top Level Domain,国別コードトップレベルドメイン)での設定ミスが原因のようです。 スウェーデン国内のWebやメールなど様々なものが停止してしまったそうです。 DNSが国単位で引けなくなるのは、悪夢ですよね。。。 詳しくは以下の英文記事にて説明されているので、是非原文をご覧下さい。 「Royal Pingdom : Sweden’s Internet broken by DNS mistake」 この英文記事によると、「.se」を管理しているレジストリが間違ったDNSレコードを24時間のTTL(Time To Live)で大