web-dev-qa-db-ja.com

DNSを使用して訪問者を最も近いサーバーに送信するにはどうすればよいですか?

DNSエントリをローカライズする方法はありますか?つまり、アジアのユーザーは、mydomain.comを米国またはヨーロッパのユーザーとは別のIPに解決します。これは、ユーザーに近くのサーバーを提供するのに役立ちます。 DNSはこれまで使用された唯一の手法です。つまり、DNSを置き換えるソフトウェアルーティングまたは中央システムを配置してこれを解決することはできません。

22
kcode

はい、現在、この問題に対する2つの一般的な解決策があります。

1つはAnycastと呼ばれ、同じIPブロックが文字通り世界中の複数の場所で使用されています。つまり、ドメインのネームサーバーは常に同じIPアドレスを返しますが、そのIPアドレスは実際には複数の物理サーバーのセットに割り当てられています。

詳細はこちら http://en.wikipedia.org/wiki/Anycast

2番目の手法にもAnyCastが関係しますが、今回は、エニーキャストされるIPアドレス範囲はネームサーバー自体を参照します。ネームサーバーはclosestであるクライアントからのリクエストのみを行うため(BGPの魔法によって決定される)、それらは論理的にIPアドレスを返すことができます。クライアントに対してローカル。

これの例はグーグルのl.google.comドメインです

オーストラリアのホストから

crimson:~ dave$ Host www.google.com
www.google.com is an alias for www.l.google.com.
www.l.google.com is an alias for www-notmumbai.l.google.com.
www-notmumbai.l.google.com has address 66.249.89.99
www-notmumbai.l.google.com has address 66.249.89.147
www-notmumbai.l.google.com has address 66.249.89.103
www-notmumbai.l.google.com has address 66.249.89.104

米国のホストから

[dave@odessa ~]$ Host www.google.com
www.google.com is an alias for www.l.google.com.
www.l.google.com has address 74.125.95.99
www.l.google.com has address 74.125.95.147
www.l.google.com has address 74.125.95.104
www.l.google.com has address 74.125.95.106
www.l.google.com has address 74.125.95.105
www.l.google.com has address 74.125.95.103

したがって、www.google.comのCNAMEはwww.l.google.comに解決されますが、解決すると、場所に応じて、クライアントは異なるIPアドレスのセットを受け取ります。これは、www.l.google.comのリクエストを受け取ったネームサーバーが、クライアントに対してlocalネームサーバーであったためです。

21
Dave Cheney

同じ問題がありました。私たちの会社はロシアと中国に顧客を抱えており、彼らはすべて私たちのサービスへの非常に高速な接続を必要としています。 Amazon Route 53 Geo dnsを使用して2つのレコードを作成しました。1つは中国から東京リージョンのクラスターに顧客を、もう1つはロシアからロンドンに顧客をルーティングします。

2
amanbolat

アジア、北米、ヨーロッパのサーバーのみをローカライズする場合は、WebアプリケーションとDNSの両方を自分で実行することを決定できます。

DNSでは、Split-Horizo​​n DNSのようなアプローチを使用できます。これは、DNSサーバーの統合機能(またはGeoDNS)、またはfirewallを介して、異なるIPアドレス範囲を異なる実行中のインスタンスにリダイレクトする可能性があります。 DNSサーバー(ローカルマシン上でサーバーの複数の異なるコピーを実行でき、異なるローカルIPアドレスでリッスンします)。

[〜#〜] ripe [〜#〜]およびAfriNIC IPアドレスからのDNSリクエストに返信することで、ケースの≈90%でおそらく期待される結果を得ることができます。ヨーロッパのホストのAレコード、[〜#〜] apnic [〜#〜]からのリクエスト、および/のIPアドレスからのリクエスト/ 8[〜#〜] arin [〜#〜]によって管理されるブロック、LACNICおよびその他の北米のサーバーのAレコードを含む/ 8アドレス空間。これは特定の状況ではいくつかの誤った結果になります(一部の/ 8ブロックがヨーロッパと北米で共有され、一部のアドレススペースはエニーキャストなど)。ただし、発生する最悪の事態は影響を受けるパーティーにとって余分なレイテンシなので、それはすべきではありません。大したことはありません。

(そして、はい、これらをより簡単にする方法があるはずですが、今のところ、何もないようです。)

2
cnst