ネームサーバーは、何らかの戦略に基づいてIPアドレスを動的に解決できますか?


11

複数のデータセンターに展開されているWebサイトのDNS解決のために、いくつかのネームサーバーを登録しました。

DNS解決の現在の戦略は、異なるクライアントIPアドレスに基づいて、ネームサーバーが同じドメインに対して異なるIPアドレスを返すことです。たとえば、クライアントのIPアドレスが北米のものである場合、ネームサーバーは、北米のデータセンターのIPアドレスであるIPアドレスを返します。

ただし、クライアントのIPアドレスは、ユーザーの実際のIPアドレスではない場合があります。ISPまたはプロキシサーバーに属するDNSのIPアドレスである場合があります。一方、データセンターの1つがダウンした場合、クラッシュしたデータセンターに属するIPアドレスをネームサーバーから除外する必要があります。したがって、DNS解決のためのより動的な戦略が得られることを願っています。その解決策はありますか?


これは、エニーキャストの場合のように聞こえます。
ロンMaupinの

1
@RonMaupinエニーキャストを行うには、プロバイダーに依存しないアドレスブロックの割り当てが必要であり、さらに重要なことに、各データセンターからプレフィックスをアドバタイズするためにBGP実行する必要があることに注意してください。これはまったく新しいレベルの運用であり、多くの「コンテンツ指向」企業が経験するものではありません。DNSベースのソリューションははるかに簡単に見えます。
IPX

@IPX、私は疑問に思われるように、世界中にデータセンターを持つ企業がプロバイダーに依存しないアドレッシングと独自のAS番号を持つと想像します。それにより、エニーキャストは無料で簡単です。
ロンMaupinの

1
@RonMaupinは、OPの会社が実際に世界中で複数のデータセンターを運営している場合はそうですが、おそらくここでは比較的単純な質問をすることはないでしょう。私は彼らが単にいくつかの商業データセンターに自分のHWを配置するか、HWを雇っただけで、高度なネットワーク運用を本当に気にしていないと思います。これは、多くの中規模企業が冗長化のために行っていることです。その場合は、DNSはルーティングではなく答えです。
IPX

@IPX、私が質問から収集したのは、会社が世界中にデータセンターを持っているということです。あるデータセンターがクラッシュした場合、転送されるトラフィックは別のデータセンターに送られるべきです。 。「)。サードパーティのホスティングについて推測しようとするのではなく、質問に答えただけで、私たちもそのいくつかを行いますが、ISPとのピアリングに使用されるプロバイダーに依存しない独自のアドレス指定とAS番号がまだあります。これにより、ネットワークの再アドレス指定を中断することなく、契約の交渉とISPの変更が可能になります。
ロンMaupinの

回答:


16

エニーキャストが欲しいようですね。これは、Googleのようなサイトが使用するタイプのことです。すべてのWebサイトに単一のアドレス(DNSによって解決される)があり、インターネットルーティングプロトコル(BGP)がユーザーを(ルーティングプロトコルによって)最も近いサイトに誘導できるようにします。サイトがダウンすると、次に近いサイトがBGPによってインターネットルーティングテーブルに自動的に配置されます。

8.8.8.8DNS の典型的な例です。世界中のさまざまな場所に解決され、1つの場所がダウンすると、次に近い場所に移動します。

答えはDNSではなく、ルーティングです。


2
エニーキャストは通常​​、TCPベースのプロトコルには役立ちません。同じ接続に属するパケットは異なるサーバーに送られる可能性があるためです。
パウロEbermann

2
@PaŭloEbermannは、BGPルーティングを使用する場合には問題になりません。ルートは通常、アナウンスされたときに変更されないため(マイナーな変更のみ)
Ferrybig

2
@PaŭloEbermannすべてのロードバランサーがバックエンドの選択方法に同意する限り、DSRベースのロードバランサー間でエニーキャストを実行できます。
カスペルド

3
@PaŭloEbermann、それは誤解です。1つのホストからのすべてのトラフィックは1つのサーバーに送られ、そのサーバーがダウンしない限り、トラフィックは別のサーバーに向けられます。はい、それはTCP接続を切断しますが、接続しているサーバーがダウンするたびにそうなります。エニーキャストはラウンドロビン型のものではありません。ルーティングは確定的であるため、エニーキャストは確定的です。
ロンMaupinの

2
@RonMaupinエニーキャストルーティングは、あなたが暗示しているほど安定していません。そして、Googleはあなたが言っているようにエニーキャストを使用しません。Googleが実際にこれをどのように行っているかを知りたい場合は、Googleが発行したサイト信頼性ワークブックの227ページをご覧ください。要するに、エニーキャストルーティングの背後にあるロードバランシングレイヤーは、TCP接続を切断することになるルーティングの避けられない変更を補います。
カスペルド

9

何が必要である正確にアマゾンRoute53 DNSサービスの提供:

Route53を使用できるようにするためにAWSでウェブサイトホストする必要はありません。プライベートデータセンターに展開されたサービスとうまく機能します。

FacebookまたはGoogleの場合を除き、リクエスト100万件あたり$ 0.40から始まる価格設定も問題になりません(価格設定の詳細を参照)。

それが役立つことを願っています:)


これにAmazon以外の製品を使用したことがありますか?

@chicks nopeしていない。私は常に仕事に最適なツールを使用する傾向があり、ほとんどの場合、Route53はその法案に適合します。ただし、「geo dns service」のようなものをグーグル検索すると、いくつかのオプションが表示されます。私はすぐにいくつかを見ましたが、それらは非常に高価に見えます(月50ドル前後-AWS Route53で多分使うよりもはるかに多いです)。
MLu

2
ほとんどの場合に最適なツールを見つけた最初のツールを呼び出す前に、もう少し視野を広げたいと思います。Route53は誰にとっても最高の可能性がありますが、他に何も試したことがない場合はどうすればわかりますか?

-1

私はこの考えを持っていて、それをコーディングし始めましたが、最初に必要性が蒸発したために終わりませんでした。

DNSサーバーには、LAN上のすべてのマシンのホスト名とMACアドレス、およびそれらにアクセスする方法があります。認識しているマシンへの要求を受信すると、指定されたMACアドレスのIPアドレスに対してリバースARPを送信し、応答を使用してDNS回答を作成します。

これは、あなたがやろうとしていることとは何の関係もありませんが、ポイントを示しています。理論的には、DNSサーバーをコーディングして、名前をIPアドレスに解決する新しいスキームを実行できます。

実際の質問は、顧客のIPアドレスを取得して送信先を決定する方法です。これはわずかなXY問題です。本当に必要なのは、顧客のISPがジオロケーションを行うことです。8.8.4.4または他のDNSリダイレクトサービスではない場合、要求を行うIPアドレスから直接それを行うことで取得できます。私の考えでは、DNSリダイレクタの最善の解決策は、問題を無視し、自己相対ジオロケーション(つまり、DNSサーバーからの呼び出しIPアドレスの検索を試みる)を行い、適切にリダイレクトすることです。ジオロケーションの方法については、こちらをご覧くださいhttps : //stackoverflow.com/questions/2574542/location-detecting-techniques-for-ip-addresses

あなたは本当にここでエニーキャストを望んでいませんが、もっと正気なものを望んでいます。エニーキャストには迷惑な性質があり、TCPストリームの途中でパケットを再ルーティングして大量の混乱を引き起こす可能性があります。

Ron Maupinは、エニーキャストはTCPのルート信頼性があると主張しています。そうでない場合のtracerouteは次のとおりです。

 3  cr1-rhe-a-be153.bb.as11404.net (174.127.183.14)  20.657 ms  20.763 ms  19.660 ms
 4  cr1-che-b-be-2.as11404.net (192.175.29.161)  22.550 ms  23.562 ms  23.538 ms
 5  * cr1-9greatoaks-hu-0-6-0-20-0.bb.as11404.net (192.175.28.108)  24.409 ms  38.083 ms
 6  72.14.222.146 (72.14.222.146)  40.038 ms  39.106 ms  39.125 ms
 7  108.170.242.225 (108.170.242.225)  37.930 ms 108.170.243.1 (108.170.243.1)  35.434 ms 108.170.242.225 (108.170.242.225)  33.694 ms
 8  209.85.240.249 (209.85.240.249)  33.476 ms 108.170.232.65 (108.170.232.65)  31.683 ms 108.170.234.155 (108.170.234.155)  30.754 ms
 9  google-public-dns-b.google.com (8.8.4.4)  30.491 ms  28.644 ms  25.718 ms

アップストリームIPアドレスの位置を明らかにしようとすると、両方ともウィチタにあります。これは物理学の簡単なデモンストレーションで十分であるので正しくありません。

8.8.4.4までの範囲は30ミリ秒で測定され、最初の18ミリ秒がローカルペナルティです(ホップ3はISPのローカルルーターです)。ウィチタまでの距離は1297マイルです。したがって、最小往復時間は(1297 * 2マイル/秒あたり225,000キロメートル(ガラスの光の速度))18.55msです。したがって、28ミリ秒よりも早く応答が返されないはずですが、25ミリ秒で応答が返ってきました。

パケットは2つの異なるBGPルートによってGoogleに到着しています。BGPは最も近いものを選択しませんでした。



コメントは詳細なディスカッション用ではありません。この会話はチャットに移動さました
区-モニカの復職

すべてのコメントをチャットに移動しましたが、非常に多くのコメントが自動的に移動されたため、後のチャットにすべてのコメントが含まれているかどうかはわかりません。いずれにせよ、この回答の有効性やルーターの動作などに関するさらなる議論はコメントにすべきではなく、チャットルームの1つに保管してください。ここにあるコメントは削除されます。
区-モニカの復職

-2

必要なものは、DNSエニーキャストとRFC-7871の何らかの組み合わせで実現できます。


1
詳細が答えを改善します
Dave M
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.