DNSでサーバーのバックアップIPを設定できますか?


10

DNSプロトコルがバックアップネームサーバーやメールサーバーのレコードのようなバックアップAレコードサーバーアドレスを自然に保持できる方法はありますか?これを検索したところ、バックアップネームサーバー(NSレコード)の結果のみが表示されました。

DNSがバックアップAレコードをサポートする方法がない場合、プライマリサーバーが応答しない場合に、ユーザーが稼働中のサーバーに転送されるように結果をシミュレートする最良の方法は何ですか?

回答:


12

はい...ちょっと。

ここでできることは2つあります。ある名前のDNSサーバーに複数のAレコードを置くと、それらはすべてクライアントに提供され、それらのクライアントはセットから1つを選択して接続します。つまり、トラフィックはすべてのサイトに同時に「公平に」均等に分配されます。これは実際にあなたが説明しているようではありませんが、それは一般的な状況です(さまざまな理由で、私はそれを信頼していません)。

もう1つのオプションは、DNSサーバーにAレコードを1つだけ配置し、DNSサーバー(または監視スクリプトなどのそれに付随するもの)がサイトのメインアドレスを監視し、失敗した場合はDNSサーバーのAレコードは他のサイトに変更されます。これは、一度に1つのサイトだけがトラフィックを受け取ることを意味します。

この2番目の戦略の欠点は、DNSキャッシングです。古いサイトアドレスを取得したユーザーは、古いアドレスを含むDNSキャッシュエントリが削除されるまでSOLになります。これは、TTLを低く保つ必要があることを意味します(DNSインフラストラクチャの負荷が増加しますが、実際には問題になることはめったにありません)が、TTLを尊重しない「悪意のある」DNSキャッシュの問題がまだあります。これらはにとって大きな痛みです DNSエントリを変更する必要がある人はいますが、DNSエントリを「頻繁に」変更する必要がある人にとっては、100万倍も悪いものです(おそらく、サイトが1日に数回ダウンしていないことを願っていますが、それでも...)基本的に、誰もがこれらの不正なDNSキャッシュの1つの背後にあると、サイトが極端に長い期間「ダウン」していると見なされ、DNSキャッシュに問題があることを説明してみます。

要するに、あなたが考えているリスクを軽減するより良い方法があるので、私はサイトに対してそれをしませんが、それを軽減する方法についての提案が必要な場合はそのリスクを説明する必要があります。


リスクは、メインサーバーがダウンした場合(なんらかの理由で)ユーザーをバックアップサーバーに転送することです。つまり、この1年で、サーバーが一度停止しました(致命的なレイド障害)。バックアップがあったのでデータは安全でしたが、ウェブサイトは12時間ダウンしていました。これは、「適切な」修正でよくある問題でした。私は会社がバックアップ計画を望んでいたと思います。
kjones1876

9
DNSフェイルオーバーは必要ありません。より信頼性の高いハードウェアと、場合によってはホットスタンバイサーバーが必要です。
ウォンブル

「不正なDNSキャッシュ」は、古い妻の話です。実際のDNSサーバーソフトウェアは、TTLを無視する動作を示しません。DNSデータは問題を引き起こすような方法でキャッシュされている場所があるアプリケーションなど、Netscape Navigatorの問題をキャッシュ悪名高い検索たとえば。
JdeBP '25 / 07/25

@JdeBP:Kevin Costnerの言葉で:「不正なDNSキャッシュは神話ではありません...私はそれらを見ました!」私は発掘を行い、非常識で心を曲げる結果を見ました。そのようなことが一般的だった時代に遡って、帯域幅に制約があり、遅延に影響されたサービスで最も人気があり(たとえば、アップストリームリンクがISDNであるダイヤルアップISP)、それらは現在、優れていることを聞いた人によって主に使用されていますずっと前に考えて、それ以来、彼らの考えを変えていません(当時、彼らは特に良い考えだったわけではありませんが…ええ)。
ウォンブル

6

あなたが明示的に書いたにもかかわらず、誰もがあなたがWWWサーバーについて話していると思っているようです

バックアップネームサーバーやメールサーバーのように

見過ごされがちな真実は、HTTPサービスは例外であり、これに関しては標準ではないということです。通常の場合には、はい、そこにあるように、彼ら適切に代替プライマリサーバからバックアップサーバへのDNS経由でクライアントに情報を公開するための仕組み。 そのメカニズムは、SRV他の多くのプロトコルに対してサービスクライアントによって使用されるように、リソースレコード以外からの HTTP。 RFC 2782を参照してください。

SRVリソースレコードは、クライアントが優先順位と重みで、サーバーのリストを言われると、優先順位の順序でサーバを試すために必要とされている、重量に応じて同じ優先順位を持つサーバー間で摘み、より頻繁に低い加重よりも、加重のサーバーを選択しますもの。したがってSRV、サーバー管理者はリソースレコードを使用して、フォールバックサーバーとは何か、および優先順位が等しい一連のサーバー間で負荷を分散する方法をクライアントに伝えることができます。

現在、コンテンツDNSサーバーは、独自のリソースレコードの特別なタイプのリソースレコードによって配置されています。リソースレコードには、NS優先度と重みの情報はありません。同様に、SMTPリレーサーバーは、独自の特別な種類のリソースレコードによって配置されますMX。これには、優先度情報はありますが、重み付け情報はありません。したがって、コンテンツDNSサーバーの場合、フォールバックおよび負荷分散情報を公開するためのプロビジョニングはありません。MXリソースレコードを使用している場合、SMTPリレーサーバーの場合、負荷分散情報を公開するための準備はありません。

ただし、にSRV対応したMTSは現在存在しています。(第一号だったeximとなっていた、SRV2005年以来-capable)とのためにの荷物と邪魔されないサービスプロトコル、MXおよびNSリソースレコード、SRV採用ははるかに徹底的かつ広範囲に及んでいます。たとえば、Microsoft Windowsドメインを使用している場合、一連のサービス全体SRVがDNSでのルックアップによって検索されます。この時点で、それは10年以上の間当てはまります。

問題は、誰もがHTTPを考えているということです。HTTPが断然、今日の2011年には例外であり、ここでのルールではありません。


srvレコードは、環境が制御されている場合の内部ネットワークでの使用には最適ですが、異種クライアントを備えた外部サーバーのような場合にはカットされません。クライアントがsrvレコードへのアクセスをサポートするかどうかわからないため、レコードがアクセスされることはわかりません。
マイケル・ローマン、2011

1
繰り返しますが、あなたはHTTPにあなたの考えを支配させています。上記のクライアントの多くにとって、SRVレコードはサービスを見つけるための定義された方法です。また、問題はメカニズムが存在するかどうか、およびそれが何であったかであることに注意してください。メカニズムが存在し、これがメカニズムです。それは10年間広く使用されています。
JdeBP 2011

確かに正しい、srvは確かに正しいメカニズムであり、実際にはDNSで実行できなかったものの、それができればと思っていた他のことも実行します。残念ながら、ブラウザはsrvをサポートしていません。また、質問はHTTP固有のものでした。なぜなら、「バックアップネームサーバーやメールサーバーのように」と言ったためです。つまり、バックアップソリューションがすでに存在しています。
kjones1876

1

動的コンテンツを提供していて、2つのサーバーが同時にコンテンツを提供するだけでは実用的でない場合は、とにかくDNSに複数のレコードを用意し、バックアップサーバーを設定して、接続しようとするクライアントに到達できないICMPポートをスローするようにします。 ; いずれかの時点でメインサーバーがダウンした場合は、バックアップのポート80ブロックを削除するだけで、トラフィックが入り始めます。

他にできる唯一の(予算)方法は、リクエストでNATを実行するために別のマシン(または2つ)をセットアップすることです。したがって、Webサーバーが停止した場合でも、NATルールを削除できます。


私は最初にあなたの最初のアイデアに疲れました。メインサーバーでapacheをオフにしましたが、ブラウザはとにかく接続を試み続けました。しかし、ApacheコースをICMPエラーに変えるのでしょうか?そうでない場合、ICMPエラーが発生してもサーバーを作成するにはどうすればよいですか?
kjones1876

いいえ、接続はただタイムアウトする、あなたはiptablesのは、そうのようなきちんとそれを拒否してもらう必要があります:
Olipro

iptables -I INPUT -p tcp --dport 80 -j REJECT --reject-with icmp-port-unreachable
Olipro

私はそれに疲れて、人々は単に接続できませんでした...私は私がテストしているサーバーを抜いてさえいた。
kjones1876 2011

質問者は、WWWサーバーのみについて具体的に話しているわけではありません。実際、xeはメールサーバーとネームサーバーを明示的に言及しました。
JdeBP 2011

0

バックアップAレコードはありませんが、ランダムな順序で与えられる複数のAレコードが存在する可能性があります。

ほとんどのブラウザは、1つのサーバーに障害が発生した場合に別のサーバーを試すことができます。(参照:ラウンドロビンDNSによるWebの回復力

VRRPまたはCARPを備えた複数のサーバーによってバックアップされた1つのクラスターIPアドレスを持つことができます。プライマリサーバーに障害が発生すると、バックアップサーバーがアドレスを引き継ぎます。


質問者は、WWWサーバーのみについて具体的に話しているわけではありません。実際、xeはメールサーバーとネームサーバーを明示的に言及しました。
JdeBP 2011

@JdeBP:ああ。私は盲目であるようです。申し訳ありません:P
jkj

0

はい、しかしあなたはそれを自分でしなければなりません;-)

なぜ「バックアップAレコード」が必要なのか、またどのようにしてどのような状況でバックアップに行きたいのかについて、詳しい情報を教えてください。

また、プライマリホストとバックアップホスト間のネットワークの観点から関係を理解し​​ておくと役立ちます。


0

これはかなり古い質問ですが、2つのかなり重要なテクノロジー、つまり動的DNSとCDNは回答に含まれていません。

動的DNSは、DNSレコードをほぼリアルタイムで変更できるように設定されているため、監視クライアントは、サービスの可用性に応じてパブリックDNS Aレコードへの変更をトリガーできます。(もちろん、DNSホスティングサービスは動的DNSをサポートしている必要があります。)

CDNはDNSを配信するためにも使用できます。たとえば、Cloudflareは(2010年にローンチしたと思います)のように。

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