タグ

networkと*あとで読むに関するsionsouのブックマーク (5)

  • Route 53のPrivate DNS対応を試してみた | DevelopersIO

    ウィスキー、シガー、パイプをこよなく愛する大栗です。 DNSサービスであるRoute 53がVPC内のPrivate DNSをサポートしたので試してみました。 Route 53の設定 Route 53でHosted Zoneを作成します。今まで見慣れないTypeとVPC Idが出てきます。TypeでPublic DNSかPrivate DNSを選択します。 ドメイン名を"maroon1st.local"としてドメインを作成して、Typeを"Private Hosted Zone for Amazon VPC"に設定して、対象のVPCを関連付けます。 作成したHosted Zoneでレコードを作成します。ここではRDSのエンドポイントにCNAMEを設定しました。 この後、既存のDNSキャッシュが消えるまで待ちます。(DNSは「浸透」しませんよ) digコマンドで確認すると、以下の様に表示され

    Route 53のPrivate DNS対応を試してみた | DevelopersIO
  • 強烈なDNSキャッシュポイズニング手法が公開される:Geekなぺーじ

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

  • HTTPリクエストを減らすために【序章】HTTPリクエストは甘え - MOL

    このシリーズはHTTPリクエストの理解を通じてWebパフォーマンスの重要性について考える5章構成になっている。 【序章】HTTPリクエストは甘え 【CSS Sprite編】スプライト地獄からの解放 【WebFont編】ドラッグ&ドロップしてコマンド叩いてウェーイ 【DataURI編】遅延ロードでレンダリングブロックを回避 【終章】我々には1000msの猶予しか残されていない 1日目は、HTTPリクエストの概要について説明する。 例えに、私のポートフォリオページ(t32k.me)が表示されるまでの流れを見ていく。まず、検索からでも方法はなんでもよいが、ブラウザのURLバーにt32k.meと打ち込んでアクセスする。そのページを見にいくということは、つまりt32k.meに対してHTTPスキームでリクエストするということを意味している。 クライアントであるブラウザは入力されたURLを判断して、リソ

  • 僕が考えた最強のサーバ設定 - とあるプログラマの日記 @s025236

    いつの間にかさくらのVPSの標準OSがCentOS6になってたので設定を見直してみました。 月額980円/月から利用でき、2週間のお試し期間もあるのでこれを機会にサーバ設定に足を踏み入れてみてはどうでしょう? 慣れると10分くらいでウェブサーバが立ち上げれるようになります。 すみません。こんなに多くの人が見てると思わなかったんです。 お一人様サーバ向けのつもりで書いてます。 タイトルもタグもネタだったのにツッコまれまくりで恥ずかしい… 公開鍵登録しよう どうせ自分しか触らないなしrootで作業しちゃってもいいんじゃない? リブート(またはsshのrestart)以降秘密鍵がないとsshでログイン出来なくなるので気をつけてください。 mkdir ~/.ssh/ touch ~/.ssh/authorized_keys chmod 700 ~/.ssh/ chmod 600 ~/.ssh/au

  • ついにRFCに登場!Webサーバとの双方向通信を実現する「WebSocket」 - builder

    次世代のWebアプリケーションの中核を担う技術として「HTML5」に注目が集まっているが、それと並んで期待されている技術に「WebSocket」がある。 IETFとW3Cによって仕様の策定が進められており、最初の提案以来幾度もの改訂を経て、2011年12月11日にそのプロトコル仕様がRFCのProposed Standard(RFC 6455)となった。 AjaxからComet、そしてWebSocketへ WebSocketはウェブサーバとブラウザが直接コネクションを張って双方向通信するための技術規格である。HTTPとは異なる独自の軽量プロトコルによって通信を行うため、オーバーヘッドが小さく、長時間に渡って通信する場合でもHTTPコネクションを占有する必要がないというメリットがある。 WebSocketが生まれた背景には、サーバとブラウザがもっとリアルタイムに通信して情報の配信や更新を行え

    ついにRFCに登場!Webサーバとの双方向通信を実現する「WebSocket」 - builder
  • 1