タグ

DNSとNetworkに関するftnkのブックマーク (28)

  • Kazuho@Cybozu Labs: DNS ラウンドロビンと高可用性 (High Availability)

    « brainf*ck でマジメに素数探索 | メイン | Brainf*ck で動的リスト » 2006年06月29日 DNS ラウンドロビンと高可用性 (High Availability) ウノウラボ Unoh Labs - ベンチャー流サーバ構築のススメ(ネットワーク編) について。 おもしろく読ませていただきました。また、監視系を導入せずに自律的に動作させようという発想も大好きです。 でも、 DNSは各回線の内側に設置しておきます。例えば上図のような場合、回線A側のDNSは回線AのIPアドレスを返すようにして、回線B側のDNSは回線BのIPアドレスを返すようにします。こうするとどちらかの回線が切れたときは切れたほうの回線のDNSにアクセスできなくなるので、自動的に生きている方の回線に接続されるようになります。 (ウノウラボ Unoh Labs - ベンチャー流サーバ構築のススメ(

  • チープなDNSラウンドロビンは高価なロードバランサの座を奪い返せるか:Web屋のネタ帳 on CNET - CNET Japan

    チープなDNSラウンドロビンは高価なロードバランサの座を奪い返せるか 公開日時: 2006/08/10 20:23 著者: watanabe 結論。DNSラウンドロビンという古くからある技術を取り巻く状況の変化を見過ごしている結果、負荷分散と可用性確保のために高価なロードバランサー機器を導入しているWebサイトは、実は大幅に金を無駄にしているのかもしれない。 一部の人には「今頃気がついたか」と笑われる可能性が高い話だ。 筆者が気づいたきっかけはとあるブログに書かれたこんな一節である。 あまり知られていないことかもしれませんが、DNS があるホスト名に対して複数の IP アドレスを返した場合、多くのウェブブラウザは、その全てのアドレスに対して接続を試みます (接続に成功するまで)。 Kazuho@Cybozu Labs: DNS ラウンドロビンと高可用性 (High Avail

  • (ひ)メモ - そんなわきゃない>DNS RRはロードバランサの座を奪い返せるか

    チープなDNSラウンドロビンは高価なロードバランサの座を奪い返せるか つっこみどころが満載スギなのは脇においておいて、金をかけないなら、DNSラウンドロビンじゃなくて、せめて、件の記事でも紹介されている Apache 2.2のmod_proxy_balancer か、Apache 2.2じゃなくても使えるreverse proxy系の実装たち、 POUND mod_backhand Perlbal を使うべきでしょう。 んで、「L7ロードバランサ(要はreverse proxy)なんていらねっす。セッション? んなのmemcachedでシェアすりゃいいんじゃん。その方がスケールアウトしやすいしー」という向きには、LinuxでL4のロードバランサするのをオススメでします。まともなL4ロードバランサが手に入るのに、金銭的コストはゼロですってよ、オクサン! Linux Virtual Serve

    (ひ)メモ - そんなわきゃない>DNS RRはロードバランサの座を奪い返せるか
  • http://wiki.no32.tk/takano32/?ValueDomain

  • Ywcafe.net

    Ywcafe.net This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: Healthy Weight Loss Best Penny Stocks Cheap Air Tickets Credit Card Application Top Smart Phones Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy|Do Not Sell or Share My Personal Information

  • DNSサーバへの攻撃を退けるPHREL | OSDN Magazine

    現在、インターネット上で公開ネームサーバを稼働させるにはそれなりの対策が求められる。際限のない攻撃の波にさらされるからだ。顧客のために再帰的な問い合わせを行うISP(インターネットサービスプロバイダ)の場合、状況はさらに悪くなる。大量のトラフィックに対処する方法は数多く存在し、サーバの増設、不正なトラフィックの遮断に役立つ専用のハードウェアソリューションまたはファイアウォールの購入などがある。そしてもう1つ、Linuxシステム上でネームサーバを稼働させている場合には、ホストごとにレート制限を行うプログラム(Per Host RatE Limiter)、PHRELという解決策がある。 問題が起こるのは、顧客のホストが不正に侵入されてスパムの送信元として利用される場合だ。こうした場合、受信者側のメールサーバのアドレスを取得する際に1分間に何千というDNS要求がネームサーバに送信される。他の顧客

    DNSサーバへの攻撃を退けるPHREL | OSDN Magazine
  • Ywcafe.net

    Ywcafe.net This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: fashion trends Anti Wrinkle Creams Contact Lens Dental Plans music videos Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy

  • ウノウラボ Unoh Labs: サービスの開発と運営をする上での問題の切り分け(ドメイン・DNS編)

    普段バランスボールに座って仕事をしているのにWBSの撮影は普段ボールで仕事をしていない人が軒並みボールに座るので自分の分がなくなって撮影中のテンションが下がってしまったアンケートに英語キーボードの人+1できなかったjokagiです.上鍵のタイプの英語キーボードってかなり少なくて困ってます. そういえばなんとか正式採用になってプロフィールに掲載されました. あらためてよろしくお願いいたします. さて今回はウェブ開発というかインターネット向けサーバー&クライアントな開発をする上で「問題の切り分けちゃんとできるようになりましょう」という話です. 問題の切り分けちゃんとできてますか? あるサービス,わかりやすいのはウェブサービスを開発していると,普通さまざまな問題がでてきます. スクリプトなどロジックの問題の場合は解決できる人は多くいらっしゃるのですが, 「サーバーにつながらない」という現象に対し

    ftnk
    ftnk 2007/09/11
    dig trace host