なぜ「DNSの浸透」は問題視されるのか:Geekなぺーじ
「DNSの浸透」という表現が結構よく使われています。 DNSに設定された情報を更新したけれど、その結果がなかなか反映されずに誰かに相談すると「DNSの浸透には時間がかかります」と説明されて納得してしまうという事例が多いようです。 しかし、うまく準備を行えば、実際の切り替え処理は、いつ完了するのかが不明な「DNSの浸透」を待つのではなく、事前に計画した時間通りに完了させることが可能です。 さらに、本来であればDNS情報の設定者(ゾーン情報の設定者)は、いつまでに世界中のキャッシュが更新されるかを知ることができる環境にあり、それ以降も更新がされていなければ「何かがおかしい」とわかるはずです。 DNSにおける設定内容(DNSのリソースレコード)には、その情報をキャッシュとして保持し続けても良い期間であるTTL(Time To Live)という要素がありますが、TTLはDNS情報設定者が自分で設定
「DNSの浸透」とアプリケーションのキャッシュ:Geekなぺーじ
さきほど「DNSの浸透」に関して書いたのですが、それに対して「でもTTLを無視するDNSキャッシュサーバがいるから仕方がない」というような反応が一定数登場しています。 「浸透」の話になると、そのような話がほぼ必ず登場するのですが、実際に「この製品がTTLを無視する」とか「このISPで運営されているDNSキャッシュサーバはDNSプロトコルに違反している」という具体例をいまのところ見た事がありません。 「そういう困ったDNSキャッシュサーバも居るんだよ」とか「でもTTLを越えたあとも旧IPアドレスにアクセスあるもん」という感じの主張が多いです。 そんなところにsumikawaさんから以下のようなTweetを頂きました。 確かに、DNSの世界におけるTTL情報はアプリケーションには届かないので、権威DNSサーバのTTLを事前に小さくしたとしても、アプリケーションが持っているキャッシュは制御ができ
ネットが政治を動かす。SOPA/PIPAのDNSブロック条項削除へ:Geekなぺーじ
ネット上での激しい反対運動のプレッシャーを受けて、アメリカで進んでいたオンライン海賊行為防止法(SOPAおよびPIPA)に含まれていたDNSブロッキング条項が削除される方向に動いているようです。 PIPAでDNSブロッキング条項が削除される方向に流れ、その次の日にSOPAでも同様の条項が削られると発表されました。 CNET: DNS provision pulled from SOPA, victory for opponents CNET: Sen. Leahy bows to pressure, pledges to amend Protect IP bill United States Senator for Vermont - Patrick Leahy: Comment Of Senator Patrick Leahy On Internet Service Providers
インターネットが物理的に壊れる原因いろいろ:Geekなぺーじ
インターネットは物理的な回線の上に構築されているため、物理回線の故障がインターネットに影響を与えることがあります(この記事は主にLayer 1編みたいな感じです)。 意外と知られていない、あんな原因やこんな原因を紹介しようと思います。 なお、ここで紹介するものは全体の一部であり、これ以外にも色々と障害発生の原因はあります。 酔っぱらったハンター 米国では、通信回線に対する脅威の一つに「酔っぱらったハンター」が挙げられます。 2010年に行われたNANOG49の「Keynote: Worse Is Better」というセッションで、GoogleのVijay Gill氏が以下のように述べています。 アメリカには入手が容易なアルコールと、入手が容易なハイパワーなライフルを両方とも手に入れられる環境がある ハンティングシーズンに獲物を発見できずに酒を飲んだハンターが、暇つぶしに露出している光ファイ
svn＋TeXでcommitするとPDF - オーム社開発部の出版システムでの書籍執筆:Geekなぺーじ
以前、オーム社開発部の出版体制を取材しましたが、今回、私自身がそのシステムを使って本を書きました。 Subversionでバージョン管理をしつつLaTeXで本を書く形式です。 複数人で本を書く時にバージョン管理ツールを使わないと、誰がどこをどういじったのかがわからなくなったり編集箇所が競合する場合が多いのですが、Subversionを使うことでそれらが解決可能です。 さらに、筆者か編集者のうちの誰かがsvn commitを行って最新版を更新すると、それに連動して最終原稿として印刷所に入稿されるものと同じ形のPDFが自動的に生成され、DTP作業がゼロになるとともに、筆者がアウトプットを細かく確認ができるという特徴もあります。 しかも、Subversionのコミットメールを編集者側も見ていて、該当部分に対する編集やコメントがすぐに投入され、こちらが文章を書いた数分後に編集側意見が含まれるPDF
Geekなぺーじ : IPv4枯渇〜これからのインターネットの変化とデータセンター〜＠HOSTING-PRO
秋葉原で行われたHOSTING-PRO 2011で、日本データセンター協会 IPv4アドレス枯渇WG chairの仲西亮子氏によって「IPv4枯渇～これからのインターネットの変化とデータセンター～」という発表が行われました。 内容は、IPv4アドレス枯渇、IPv6対応、IPv4/IPv6変換の必要性、これからのインターネットの変化、というものでした。 最初に、IPv4アドレスのIANAプール枯渇までの流れの解説や、アドレス配分の仕組み、などのおさらいがありました。 APNIC/JPNICにおける「枯渇」とは何か？ 次に解説されたのが、APNIC/JPNICにおける「枯渇」の定義です(JPNICはAPNICと在庫を共有しているので、APNIC/JPNICと表現されています)。 IANAプールの「枯渇」の定義は、全ての/8ブロックがRIRへと割り振りされて、IPアドレスの中央在庫がゼロになるこ
日本のIPv4アドレスが枯渇:Geekなぺーじ
本日、アジア太平洋地域及び日本のIPv4アドレスが枯渇しました。 具体的には、アジア太平洋地域のRIR(Regional Internet Registry)であるAPNICのIPv4アドレス在庫が枯渇しました。 「APNICにおけるIPv4アドレス在庫枯渇のお知らせおよび枯渇後のJPNICにおけるアドレス管理ポリシーのご案内」 「あれ？この前も枯渇のニュースがあったような。。。」という人もいるかも知れませんが、2月に枯渇したのは中央在庫と呼ばれるIANA在庫です。 IANA在庫の枯渇のアナロジーとしては「IPv4アドレス製造工場で製造中止された状態」のようなものです(IANAはIPv4アドレスを作っているわけではないので製造工場というよりも巨大倉庫ですが、そこら辺は愛嬌ということで許して下さい)。 IANAからのIPv4アドレスブロックは世界5つのRIR(Regional Interne
Geekなぺーじ : 世界のWebトラフィック3割を配信するAkamaiの創設者Tom Leighton博士インタビュー
2月17日に赤坂で、Akamai Technologies社の創設者であり、MIT教授でもあるTom Leighton 博士によるプレス発表会が開催されました。 そこで発表された内容のうち、個人的に興味を持ったのは以下の項目です。 IPv6サービスに関して Ericsson 社との提携によるモバイル網への進出について DDoS 等による攻撃トラフィックに対処するためのコンサルティングと、それらの不正トラフィックによって発生したトラフィックに対して課金を行わない保険サービスの紹介 Leighton博士へのインタビュー さらに翌18日、Leighton博士への単独インタビューに伺いました。 主に前日の発表内容に関連した質問を行いましたが、それ以外にも幾つか興味があったことを聞いてみました。 以下、インタビューの内容です。 基本的にテープ起こしに近い状態ですが、Tom Leighton教授が英語
Geekなぺーじ : IPv4アドレス枯渇に関して色々
あと半年後ぐらいに予定されているIPv4アドレス枯渇に関して箇条書きにしてみました。 とりあえず、ざっと思いつくのはこんな感じです。 何か思い出したら、また箇条書きにしてみるかも知れません。 IPv4とIPv6には互換性がないので、結果として二つインターネットが出来る形になる IPv4アドレスが枯渇してもIPv4は使われ続ける IPv6への移行が進むとしても、ペースは遅いと予想されている IPv4が全く利用されなくなるほどIPv6への移行が進むかどうかを疑う人は日本では特に多い 全体としてIPv6へと移行する方向であるが、それがどれぐらいの速さかまだ誰にもわからない 2010年現在、IPv6ネットワークは世界的に拡大し続けている 2010年時点で最も積極的にIPv6を推進しているのがフランス 2010年に入ってからアメリカでも積極的にIPv6が用意されている IPv4アドレス枯渇は、ただち
Geekなぺーじ : IPv4とIPv6の違い
ここでは、プロトコルに起因するIPv4とIPv6の違いを扱っています。 デュアルスタック環境に伴う問題点などは今回は範疇外です。 IPv4のアドレスは32ビット、IPv6のアドレスは128ビットである点が最も大きな違いです。 ただし、IPv6のアドレスのうち上位64ビットがネットワークアドレスとして利用されるため、実際には「128ビットという無限のアドレス」というのは運用上は事実ではなく、インターネットの43億倍の数倍(ネットワーク数なので正確には言いにくいため)ぐらいです。 IPv4では「198.51.100.254」のような表記ですが、IPv6では「2001:db8:aaaa:bbbb:cccc:dddd:eeee:1」のように「:」で区切る表記になります。 「::1」のように、ゼロを省略することも可能です。 IPv4では通信の種類は、ユニキャスト、ブロードキャスト、マルチキャストの3
[速報] YouTubeがIPv6に対応！:Geekなぺーじ
YouTubeが本日よりIPv6対応してます！ ただし、www.youtube.comがIPv6化したわけではなく、背後で映像転送をするためのビデオストリーム部分のIPv6化のようです。 YouTubeでのビデオストリームはwww.youtube.comではなく、「v12.lscache8.c.youtube.com」のような感じのサーバから配信されますが、その映像配信用サーバのAAAAレコードを見るとIPv6化されているのがわかります。 映像配信サーバのFQDNを知るには、www.youtube.comの各映像表示ページのソースに記述されているJavaScriptを見て下さい。 本日より、Google over IPv6環境ではYouTubeを見ながらtcpdumpしてみると、IPv6パケットが大量に見えるかも知れません。 > dig -t AAAA v12.lscache8.c.you
Geekなぺーじ : IPv4アドレス枯渇。その意味と恐らくこれから起きること
今のインターネットはIPバージョン4で動作していますが、そのIPv4で各機器を識別するためのIPv4アドレスが遂に事実上枯渇しました(参考)。 長年「枯渇する」と言われ続けていましたが、それが遂に現実の物となりました。 ここでは、IPv4アドレス枯渇とは何かと、それによって何が起きるのかを紹介します。 IPv4アドレス枯渇に関して、アナログ放送の停波と地デジへの移行や、原油枯渇と似たようなものであるような認識が多く見られますが、個人的にはIPv4アドレス枯渇後のIPv4アドレスのアナロジー(類比)としては相撲の親方株の方が近い気がしています。 まず、アナログ放送の停波と地デジへの移行ですが、アナログ放送は2011年7月に一斉に停止します。 しかし、IPv4アドレスの場合は、ある日突然IPv4が使えなくなるわけではなく、今まで使っているIPv4アドレスはそのまま使い続けられるという意味でアナ
Ustreamで世界に向けて剣道を中継:Geekなぺーじ
全日本剣道連盟は、4月18日に行われた剣道八段戦をUstream中継しました。 前日から私も手伝い役の一人として名古屋に行ってました。 今回、最終的なUstream視聴者は2962でした。 剣道の八段は合格率約1％の超難関であり、その八段の中から選ばれた32名が選手として登場する大会です。 公式情報によると八段戦(正式名称は「全日本選抜剣道八段優勝大会」)は以下のような大会です。 全日本選抜剣道八段優勝大会とは 全国５００余名の八段受有者の中から、受有後５年を経た６５才以下に該当する１００余名が抽出され、さらに選考委員会において厳選された心技ともに円熟した３２名によって行われるトーナメント方式の大会です。 こちらはUstreamではなく、YouTubeに掲載した動画ですが、今回の大会で撮影された動画で個人的にインパクトがあると思ったのは、準決勝での東選手の突きです。 試合は佐藤選手が勝利し
Geekなぺーじ : Google Public DNSについて調べてみた
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が多い所を優先的にキャッシュ更新しておくので、非常に効率が
Twitterで大学授業ノートプロジェクト sfcnote が斬新過ぎる:Geekなぺーじ
「twitterで意見を交わし合いながら授業を受けるとどうなるかという知の共有・創発実験」であるsfcnoteが面白過ぎます。 Twitterを使って授業の共有をするとどうなるのかに関する非常に面白い取り組みだと思いました。 http://sfcnote.com/ sfcnoteは、SFC(慶應義塾大学湘南藤沢キャンパス)の教室を舞台としつつ、Twitter上で議論を活発化させ、さらには授業ノートとしてまとめてしまおうという実験プロジェクトのようです。 大学の各教室名と同じハッシュタグがあらかじめ用意されています。 以下、Webサイトに書いてあるプロジェクトの目的や背景です。 http://sfcnote.com/より ■□■ プロジェクトの目的 ■□■ ・学生同士が、授業内容について意見をより活発に共有することで、創発的な授業、キャンパスを創りあげていく ・キャンパス内外のコラボレーショ
Geekなぺーじ : Googleのネットワーク構成を調べてみた
以下、図を作った方法、その他もうちょっと深い推測です。 なお、ここに書いている内容は、公開された情報から勝手に推測しているだけなので、正しくない可能性があります。 あらかじめご了承下さい。 AS番号を調べる まず、最初に「Google」という文字列が含まれるAS番号(ASN)を探しました。 Googleはアメリカの会社なので、まずは何も考えずにARINのwhoisで「google」と打ち込んで結果を見ます。 何か色々出てきます。 Google Inc. (AS15169) GOOGLE 15169 Google Inc. (AS36039) GOOGLE 36039 Google Inc. (AS36040) GOOGLE 36040 Google Inc. (AS15169) GOOGLE 15169 Google Inc. (AS36039) GOOGLE 36039 Google I
Geekなぺーじ : エリクサーのつかいどころ
世の中には2種類の人間がいます。 エリクサーを使える人と使えない人です。 エリクサーはヒットポイントだけではなく、マジックポイントも回復してくれます。 しかし、序盤ではあまり手に入らず貴重な資源であるように思えてしまいます。 そして、旅の途中でエリクサーを使わず、大事に暖めておいたら最後までほとんど使わなかったという事もあり得ます。 何のために持っていたアイテムなんでしょうか？ 全く使わないのとガンガン使う人の中間に位置するポジションとしては、ボス戦でしかエリクサーを使わないというというのもありそうです。 小学生の時にもらったお年玉は、高校生になったときには大した金額ではない事があります。 また、高校生の時に貯めた貯金は、社会人になるとスズメの涙程度にしか感じないかも知れません。 一方で、お金を手に入れると同時に使ってしまって、残りは何とか細く長く生き抜くという方法もありますが、それには賛
Geekなぺーじ : キルスイッチを探せ
「IEEE Spectrum : The Hunt for the Kill Switch」という記事がありました。 軍事的な利用目的で、チップメーカーがICにトラップドアを仕掛けているのではないかという話です。 ハードウェアに細工がしてないかペンタゴンが調べ始めているそうです。 こういった分野のセキュリティ話もあるんですね。。。 以下、要約です。 かなり削っています。 完全に専門外の内容なので、適切ではない表現や誤訳などが含まれる可能性が高いので、詳細は原文をご覧下さい。 間違いなど、ご指摘頂ければ幸いです。 昨年9月、イスラエルがシリアの核施設と思われる施設を爆撃した。 シリアのレーダーが機能していなかった。 多くの軍事ブロガーやテクノロジブロガーはレーダーが機能しなかったのは偶然ではなかったと結論付けていた。 多くのブログ記事が民生品のマイクロプロセッサの「バックドア」によってシリア
Geekなぺーじ : 人生の全てはTCP/IPに学んだ
1. ゆずり合うこと TCPはネットワーク帯域を他のTCPセッションと譲り合います。 TCPには、ネットワークが混雑(輻輳:ふくそう)してくると、送信されるパケット量を減らす仕組みがあります。 この譲り合いがあるからこそ、現在のインターネットは多数の人間が同時に使えています。 同様に、現実世界においても無理な競い合いを行うよりも譲り合いを行った方がスケーラビリティが上昇します。 2. 信頼はきめ細やかな確認応答で実現されること TCPでは、信頼性を確保するためにAck(Acknowledgement、確認応答)を送信してデータの到着を伝えます。 TCPのセッションが確立している間は、Ackが細かく送受信され続けます。 このきめ細かな確認応答が信頼の根幹であると言っても過言ではありません。 現実世界においても、きめ細かく応答を行う事が重要です。 メールなどを受け取っても、全く返事をしない相手
Geekなぺーじ : オーム社開発部での開発体制
オーム社開発部さんでの本の作り方を取材させて頂きました。 社内で自作ツールをバリバリ作って、出版作業の効率化を行っているのが凄いと思いました。 ただし、今回取材をした内容が行われているのは、オーム社開発部のうちの1グループ(グループは約3名)です。 全体的にこの体制で行われているわけではないそうなので、ご注意下さい。 取材実現の経緯は「オーム社開発部の方とのやり取り」をご覧下さい。 Subversionでバージョン管理 著書の原稿は、XML管理されており、そのXMLはSubversionで全ての著者(監訳者)と共有されているそうです。 Subversionのサーバはインターネット上にあり、各自がリモートで作業を行える環境が整い始めているため、最近では著者と一度も会わずに本が完成するという案件もあるそうです。 フォントなどの問題から、本番環境でのPDF作成はオーム社開発部で毎日行っており、毎
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
