Ubuntu14.04でBINDをプライベートネットワークDNSサーバーとして構成する方法
序章
サーバー構成とインフラストラクチャの管理の重要な部分には、適切なドメインネームシステム(DNS)を設定することにより、ネットワークインターフェイスとIPアドレスを名前で簡単に検索する方法を維持することが含まれます。 IPアドレスの代わりに完全修飾ドメイン名(FQDN)を使用してネットワークアドレスを指定すると、サービスとアプリケーションの構成が容易になり、構成ファイルの保守性が向上します。 プライベートネットワーク用に独自のDNSを設定することは、サーバーの管理を改善するための優れた方法です。
このチュートリアルでは、Ubuntu 14.04でBINDネームサーバーソフトウェア(BIND9)を使用して、内部DNSサーバーをセットアップする方法について説明します。これは、仮想プライベートサーバー(VPS)がプライベートホスト名とプライベートIPを解決するために使用できます。アドレス。 これは、内部ホスト名とプライベートIPアドレスを管理するための中心的な方法を提供します。これは、環境が少数のホストを超える場合に不可欠です。
このチュートリアルのCentOSバージョンはここにあります。
前提条件
このチュートリアルを完了するには、次のものが必要です。
- 同じデータセンターで実行されており、プライベートネットワークが有効になっている一部のサーバー
- プライマリDNSサーバーとして機能する新しいVPS、 ns1
- オプション:セカンダリDNSサーバーとして機能する新しいVPS、 ns2
- 上記のすべてへのルートアクセス(ここのステップ1〜4 )
DNSの概念に慣れていない場合は、DNS管理の概要の最初の3つの部分を読むことをお勧めします。
ホストの例
例として、次のことを想定します。
- 「host1」と「host2」という2つの既存のVPSがあります
- 両方のVPSがnyc3データセンターに存在します
- 両方のVPSでプライベートネットワークが有効になっています(10.128.0.0/16サブネット上にあります)
- どちらのVPSも、「example.com」で実行されるWebアプリケーションに何らかの形で関連しています。
これらの仮定に基づいて、「nyc3.example.com」を使用してプライベートサブネットまたはゾーンを参照する命名スキームを使用することが理にかなっていると判断しました。 したがって、 host1 のプライベート完全修飾ドメイン名(FQDN)は「host1.nyc3.example.com」になります。 次の表に関連する詳細を参照してください。
亭主 | 役割 | プライベートFQDN | プライベートIPアドレス |
---|---|---|---|
host1 | ジェネリックホスト1 | host1.nyc3.example.com | 10.128.100.101 |
host2 | ジェネリックホスト2 | host2.nyc3.example.com | 10.128.200.102 |
注:既存の設定は異なりますが、名前とIPアドレスの例を使用して、機能する内部DNSを提供するようにDNSサーバーを構成する方法を示します。 ホスト名とプライベートIPアドレスを独自の環境に置き換えることで、この設定を独自の環境に簡単に適合させることができるはずです。 命名スキームでデータセンターのリージョン名を使用する必要はありませんが、ここでは、これらのホストが特定のデータセンターのプライベートネットワークに属していることを示すために使用します。 複数のデータセンターを利用する場合は、それぞれのデータセンター内に内部DNSを設定できます。
私たちの目標
このチュートリアルの終わりまでに、プライマリDNSサーバー ns1 と、オプションでバックアップとして機能するセカンダリDNSサーバーns2ができます。
名前とIPアドレスの例を示す表を次に示します。
亭主 | 役割 | プライベートFQDN | プライベートIPアドレス |
---|---|---|---|
ns1 | プライマリDNSサーバー | ns1.nyc3.example.com | 10.128.10.11 |
ns2 | セカンダリDNSサーバー | ns2.nyc3.example.com | 10.128.20.12 |
プライマリDNSサーバーns1のインストールから始めましょう。
DNSサーバーにBINDをインストールする
注:赤で強調表示されているテキストは重要です。 多くの場合、独自の設定に置き換える必要があること、または構成ファイルに変更または追加する必要があることを示すために使用されます。 たとえば、 host1.nyc3.example.com のようなものが表示された場合は、それを自分のサーバーのFQDNに置き換えます。 同様に、 host1_private_IP が表示されている場合は、それを自分のサーバーのプライベートIPアドレスに置き換えます。
ns1とns2の両方のDNSサーバーで、aptを更新します。
sudo apt-get update
次に、BINDをインストールします。
sudo apt-get install bind9 bind9utils bind9-doc
IPv4モード
続行する前に、BINDをIPv4モードに設定しましょう。 両方のサーバーで、bind9
サービスパラメータファイルを編集します。
sudo vi /etc/default/bind9
OPTIONS
変数に「-4」を追加します。 次のようになります。
/ etc / default / bind9
OPTIONS="-4 -u bind"
保存して終了。
BINDがインストールされたので、プライマリDNSサーバーを構成しましょう。
プライマリDNSサーバーを構成する
BINDの構成は、メイン構成ファイルnamed.conf
から含まれている複数のファイルで構成されています。 これらのファイル名は「named」で始まります。これは、BINDが実行するプロセスの名前であるためです。 オプションファイルの設定から始めます。
オプションファイルの構成
ns1 で、named.conf.options
ファイルを開いて編集します。
sudo vi /etc/bind/named.conf.options
既存のoptions
ブロックの上に、「trusted」と呼ばれる新しいACLブロックを作成します。 ここで、再帰DNSクエリを許可するクライアントのリストを定義します(つまり、 ns1)と同じデータセンターにあるサーバー。 プライベートIPアドレスの例を使用して、 ns1 、 ns2 、 host1 、およびhost2を信頼できるクライアントのリストに追加します。
/etc/bind/named.conf.options —1/3
acl "trusted" { 10.128.10.11; # ns1 - can be set to localhost 10.128.20.12; # ns2 10.128.100.101; # host1 10.128.200.102; # host2 };
信頼できるDNSクライアントのリストができたので、options
ブロックを編集します。 現在、ブロックの開始は次のようになります。
/etc/bind/named.conf.options — 2 of 3
options { directory "/var/cache/bind"; ... }
directory
ディレクティブの下に、強調表示された構成行を追加します(そして、適切な ns1 IPアドレスに置き換えます)。次のようになります。
/etc/bind/named.conf.options — 3/3
options { directory "/var/cache/bind"; recursion yes; # enables resursive queries allow-recursion { trusted; }; # allows recursive queries from "trusted" clients listen-on { 10.128.10.11; }; # ns1 private IP address - listen on private network only allow-transfer { none; }; # disable zone transfers by default forwarders { 8.8.8.8; 8.8.4.4; }; ... };
ここで、named.conf.options
を保存して終了します。 上記の構成では、独自のサーバー(「信頼できる」サーバー)のみがDNSサーバーにクエリを実行できるように指定されています。
次に、DNSゾーンを指定するために、ローカルファイルを構成します。
ローカルファイルを構成する
ns1 で、named.conf.local
ファイルを開いて編集します。
sudo vi /etc/bind/named.conf.local
いくつかのコメントを除いて、ファイルは空である必要があります。 ここでは、順方向ゾーンと逆方向ゾーンを指定します。
次の行でフォワードゾーンを追加します(ゾーン名を独自のものに置き換えます)。
/etc/bind/named.conf.local —1/2
zone "nyc3.example.com" { type master; file "/etc/bind/zones/db.nyc3.example.com"; # zone file path allow-transfer { 10.128.20.12; }; # ns2 private IP address - secondary };
プライベートサブネットが10.128.0.0/16であると仮定して、次の行で逆引きゾーンを追加します(逆引きゾーン名は、「10.128」のオクテット反転である「128.10」で始まることに注意してください)。
/etc/bind/named.conf.local — 2 of 2
zone "128.10.in-addr.arpa" { type master; file "/etc/bind/zones/db.10.128"; # 10.128.0.0/16 subnet allow-transfer { 10.128.20.12; }; # ns2 private IP address - secondary };
サーバーが複数のプライベートサブネットにまたがっていても、同じデータセンターにある場合は、個別のサブネットごとに追加のゾーンとゾーンファイルを指定してください。 必要なゾーンをすべて追加し終えたら、named.conf.local
ファイルを保存して終了します。
ゾーンがBINDで指定されたので、対応する順方向および逆引きゾーンファイルを作成する必要があります。
フォワードゾーンファイルの作成
フォワードゾーンファイルは、フォワードDNSルックアップのDNSレコードを定義する場所です。 つまり、DNSが名前クエリ「 host1.nyc3.example.com 」を受信すると、フォワードゾーンファイルを調べて、host1の対応するプライベートを解決します。 IPアドレス。
ゾーンファイルが存在するディレクトリを作成しましょう。 named.conf.local 構成によると、その場所は/etc/bind/zones
である必要があります。
sudo mkdir /etc/bind/zones
サンプルのdb.local
ゾーンファイルに基づいてフォワードゾーンファイルを作成します。 次のコマンドを使用して、適切な場所にコピーします。
cd /etc/bind/zones sudo cp ../db.local ./db.nyc3.example.com
次に、フォワードゾーンファイルを編集しましょう。
sudo vi /etc/bind/zones/db.nyc3.example.com
最初は、次のようになります。
/etc/bind/zones/db.nyc3.example.com —オリジナル
$TTL 604800 @ IN SOA localhost. root.localhost. ( 2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS localhost. ; delete this line @ IN A 127.0.0.1 ; delete this line @ IN AAAA ::1 ; delete this line
まず、SOAレコードを編集する必要があります。 最初の「localhost」をns1のFQDNに置き換えてから、「root.localhost」を「admin.nyc3.example.com」に置き換えます。 また、ゾーンファイルを編集するたびに、named
プロセスを再開する前に、serialの値をインクリメントする必要があります。値は「3」にインクリメントされます。 次のようになります。
/etc/bind/zones/db.nyc3.example.com —更新された1/3
@ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. ( 3 ; Serial
次に、ファイルの最後(SOAレコードの後)にある3つのレコードを削除します。 削除する行がわからない場合は、上の「この行を削除」コメントでマークされています。
ファイルの最後に、ネームサーバーレコードを次の行で追加します(名前を独自のものに置き換えます)。 2番目の列は、これらが「NS」レコードであることを指定していることに注意してください。
/etc/bind/zones/db.nyc3.example.com —更新された2/3
; name servers - NS records IN NS ns1.nyc3.example.com. IN NS ns2.nyc3.example.com.
次に、このゾーンに属するホストのAレコードを追加します。 これには、名前の末尾を「.nyc3.example.com」にするサーバーが含まれます(名前とプライベートIPアドレスに置き換えてください)。 例の名前とプライベートIPアドレスを使用して、 ns1 、 ns2 、 host1 、およびhost2のAレコードを次のように追加します。
/etc/bind/zones/db.nyc3.example.com —3/3を更新
; name servers - A records ns1.nyc3.example.com. IN A 10.128.10.11 ns2.nyc3.example.com. IN A 10.128.20.12 ; 10.128.0.0/16 - A records host1.nyc3.example.com. IN A 10.128.100.101 host2.nyc3.example.com. IN A 10.128.200.102
db.nyc3.example.com
ファイルを保存して終了します。
最後のフォワードゾーンファイルの例は次のようになります。
/etc/bind/zones/db.nyc3.example.com —更新
$TTL 604800 @ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. ( 3 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; ; name servers - NS records IN NS ns1.nyc3.example.com. IN NS ns2.nyc3.example.com. ; name servers - A records ns1.nyc3.example.com. IN A 10.128.10.11 ns2.nyc3.example.com. IN A 10.128.20.12 ; 10.128.0.0/16 - A records host1.nyc3.example.com. IN A 10.128.100.101 host2.nyc3.example.com. IN A 10.128.200.102
次に、リバースゾーンファイルに移動しましょう。
リバースゾーンファイルを作成する
逆引きゾーンファイルは、逆引きDNSルックアップのDNSPTRレコードを定義する場所です。 つまり、DNSがIPアドレス(たとえば「10.128.100.101」)でクエリを受信すると、リバースゾーンファイルを調べて、対応するFQDN「 host1.nyc3.example.com[この場合、X187X]」。
ns1 で、named.conf.local
ファイルで指定された逆引きゾーンごとに、逆引きゾーンファイルを作成します。 サンプルのdb.127
ゾーンファイルに基づいてリバースゾーンファイルを作成します。 次のコマンドを使用して、適切な場所にコピーします(逆引きゾーンの定義と一致するように宛先ファイル名を置き換えます)。
cd /etc/bind/zones sudo cp ../db.127 ./db.10.128
named.conf.local
で定義された逆引きゾーンに対応する逆引きゾーンファイルを編集します。
sudo vi /etc/bind/zones/db.10.128
最初は、次のようになります。
/etc/bind/zones/db.10.128 —オリジナル
$TTL 604800 @ IN SOA localhost. root.localhost. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS localhost. ; delete this line 1.0.0 IN PTR localhost. ; delete this line
フォワードゾーンファイルと同じ方法で、SOAレコードを編集し、serial値をインクリメントします。 次のようになります。
/etc/bind/zones/db.10.128 —更新された1/3
@ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. ( 3 ; Serial
次に、ファイルの最後(SOAレコードの後)にある2つのレコードを削除します。 削除する行がわからない場合は、上の「この行を削除」コメントでマークされています。
ファイルの最後に、ネームサーバーレコードを次の行で追加します(名前を独自のものに置き換えます)。 2番目の列は、これらが「NS」レコードであることを指定していることに注意してください。
/etc/bind/zones/db.10.128 —更新された2/3
; name servers - NS records IN NS ns1.nyc3.example.com. IN NS ns2.nyc3.example.com.
次に、編集しているゾーンファイルのサブネット上にIPアドレスがあるすべてのサーバーのPTR
レコードを追加します。 この例では、すべてのホストが10.128.0.0/16サブネット上にあるため、これにはすべてのホストが含まれます。 最初の列は、サーバーのプライベートIPアドレスの最後の2つのオクテットで構成されていることに注意してください。 サーバーと一致するように、名前とプライベートIPアドレスを必ず置き換えてください。
/etc/bind/zones/db.10.128 —3/3を更新
; PTR Records 11.10 IN PTR ns1.nyc3.example.com. ; 10.128.10.11 12.20 IN PTR ns2.nyc3.example.com. ; 10.128.20.12 101.100 IN PTR host1.nyc3.example.com. ; 10.128.100.101 102.200 IN PTR host2.nyc3.example.com. ; 10.128.200.102
リバースゾーンファイルを保存して終了します(リバースゾーンファイルをさらに追加する必要がある場合は、このセクションを繰り返します)。
最後の例のリバースゾーンファイルは次のようになります。
/etc/bind/zones/db.10.128 —更新
$TTL 604800 @ IN SOA nyc3.example.com. admin.nyc3.example.com. ( 3 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; name servers IN NS ns1.nyc3.example.com. IN NS ns2.nyc3.example.com. ; PTR Records 11.10 IN PTR ns1.nyc3.example.com. ; 10.128.10.11 12.20 IN PTR ns2.nyc3.example.com. ; 10.128.20.12 101.100 IN PTR host1.nyc3.example.com. ; 10.128.100.101 102.200 IN PTR host2.nyc3.example.com. ; 10.128.200.102
BIND構成構文を確認してください
次のコマンドを実行して、named.conf*
ファイルの構文を確認します。
sudo named-checkconf
名前付き構成ファイルに構文エラーがない場合は、シェルプロンプトに戻り、エラーメッセージは表示されません。 構成ファイルに問題がある場合は、エラーメッセージとプライマリDNSサーバーの構成セクションを確認してから、named-checkconf
を再試行してください。
named-checkzone
コマンドを使用して、ゾーンファイルの正確性を確認できます。 最初の引数はゾーン名を指定し、2番目の引数は対応するゾーンファイルを指定します。これらは両方ともnamed.conf.local
で定義されています。
たとえば、「 nyc3.example.com 」転送ゾーンの構成を確認するには、次のコマンドを実行します(転送ゾーンとファイルに一致するように名前を変更します)。
sudo named-checkzone nyc3.example.com db.nyc3.example.com
また、「 128.10 .in-addr.arpa」逆引きゾーン構成を確認するには、次のコマンドを実行します(逆引きゾーンとファイルに一致するように番号を変更します)。
sudo named-checkzone 128.10.in-addr.arpa /etc/bind/zones/db.10.128
すべての構成ファイルとゾーンファイルにエラーがない場合は、BINDサービスを再起動する準備ができているはずです。
BINDを再起動します
BINDを再起動します。
sudo service bind9 restart
これで、プライマリDNSサーバーがセットアップされ、DNSクエリに応答する準備が整いました。 セカンダリDNSサーバーの作成に移りましょう。
セカンダリDNSサーバーを構成する
ほとんどの環境では、プライマリが使用できなくなった場合に要求に応答するセカンダリDNSサーバーを設定することをお勧めします。 幸い、セカンダリDNSサーバーの構成ははるかに簡単です。
ns2 で、named.conf.options
ファイルを編集します。
sudo vi /etc/bind/named.conf.options
ファイルの先頭に、すべての信頼できるサーバーのプライベートIPアドレスを含むACLを追加します。
/etc/bind/named.conf.options —更新された1/2(セカンダリ)
acl "trusted" { 10.128.10.11; # ns1 10.128.20.12; # ns2 - can be set to localhost 10.128.100.101; # host1 10.128.200.102; # host2 };
directory
ディレクティブの下に、次の行を追加します。
/etc/bind/named.conf.options — 2 of 2を更新(セカンダリ)
recursion yes; allow-recursion { trusted; }; listen-on { 10.128.20.12; }; # ns2 private IP address allow-transfer { none; }; # disable zone transfers by default forwarders { 8.8.8.8; 8.8.4.4; };
named.conf.options
を保存して終了します。 このファイルは、 ns2 のプライベートIPアドレスでリッスンするように構成する必要があることを除いて、ns1のnamed.conf.options
ファイルとまったく同じになります。
次に、named.conf.local
ファイルを編集します。
sudo vi /etc/bind/named.conf.local
プライマリDNSサーバーのマスターゾーンに対応するスレーブゾーンを定義します。 タイプは「スレーブ」であり、ファイルにはパスが含まれておらず、プライマリDNSサーバーのプライベートIPに設定する必要があるmasters
ディレクティブがあることに注意してください。 プライマリDNSサーバーで複数のリバースゾーンを定義した場合は、必ずここにすべて追加してください。
/etc/bind/named.conf.local —更新(セカンダリ)
zone "nyc3.example.com" { type slave; file "slaves/db.nyc3.example.com"; masters { 10.128.10.11; }; # ns1 private IP }; zone "128.10.in-addr.arpa" { type slave; file "slaves/db.10.128"; masters { 10.128.10.11; }; # ns1 private IP };
ここで、named.conf.local
を保存して終了します。
次のコマンドを実行して、構成ファイルの有効性を確認します。
sudo named-checkconf
チェックアウトしたら、バインドを再開します
sudo service bind9 restart
これで、プライベートネットワーク名とIPアドレスを解決するためのプライマリDNSサーバーとセカンダリDNSサーバーができました。 次に、プライベートDNSサーバーを使用するようにサーバーを構成する必要があります。
DNSクライアントを構成する
「信頼できる」ACL内のすべてのサーバーがDNSサーバーにクエリを実行する前に、ns1およびns2をネームサーバーとして使用するように各サーバーを構成する必要があります。 このプロセスはOSによって異なりますが、ほとんどのLinuxディストリビューションでは、ネームサーバーを/etc/resolv.conf
ファイルに追加する必要があります。
Ubuntuクライアント
UbuntuおよびDebianLinuxVPSでは、起動時にresolv.conf
の前に追加されるhead
ファイルを編集できます。
sudo vi /etc/resolvconf/resolv.conf.d/head
次の行をファイルに追加します(プライベートドメイン、ns1およびns2プライベートIPアドレスに置き換えます)。
/etc/resolvconf/resolv.conf.d/head
search nyc3.example.com # your private domain nameserver 10.128.10.11 # ns1 private IP address nameserver 10.128.20.12 # ns2 private IP address
次に、resolvconf
を実行して、新しいresolv.conf
ファイルを生成します。
sudo resolvconf -u
これで、クライアントはDNSサーバーを使用するように構成されました。
CentOSクライアント
CentOS、RedHat、およびFedora Linux VPSでは、resolv.conf
ファイルを編集するだけです。
sudo vi /etc/resolv.conf
次に、ファイルのTOPに次の行を追加します(プライベートドメイン、ns1およびns2プライベートIPアドレスに置き換えます)。
/etc/resolv.conf
search nyc3.example.com # your private domain nameserver 10.128.10.11 # ns1 private IP address nameserver 10.128.20.12 # ns2 private IP address
保存して終了します。 これで、クライアントはDNSサーバーを使用するように構成されました。
クライアントをテストする
nslookup
を使用して、クライアントがネームサーバーにクエリを実行できるかどうかをテストします。 これは、構成済みで「信頼できる」ACLにあるすべてのクライアントで実行できるはずです。
フォワードルックアップ
たとえば、次のコマンドを実行することにより、前方参照を実行してhost1.nyc3.example.comのIPアドレスを取得できます。
nslookup host1
search
オプションがプライベートサブドメインに設定されているため、「host1」のクエリは「 host1.nyc3.example.com 」に展開され、DNSクエリは検索する前にそのサブドメインを検索しようとします他の場所のホスト。 上記のコマンドの出力は次のようになります。
Output:Server: 10.128.10.11 Address: 10.128.10.11#53 Name: host1.nyc3.example.com Address: 10.128.100.101
リバースルックアップ
逆引き参照をテストするには、host1のプライベートIPアドレスを使用してDNSサーバーにクエリを実行します。
nslookup 10.128.100.101
次のような出力が表示されます。
Output:Server: 10.128.10.11 Address: 10.128.10.11#53 11.10.128.10.in-addr.arpa name = host1.nyc3.example.com.
すべての名前とIPアドレスが正しい値に解決された場合、それはゾーンファイルが正しく構成されていることを意味します。 予期しない値を受け取った場合は、必ずプライマリDNSサーバー上のゾーンファイルを確認してください(例: db.nyc3.example.com
およびdb.10.128
)。
おめでとう! これで、内部DNSサーバーが正しくセットアップされました。 次に、ゾーンレコードの維持について説明します。
DNSレコードの維持
内部DNSが機能するようになったので、サーバー環境を正確に反映するようにDNSレコードを維持する必要があります。
DNSへのホストの追加
(同じデータセンター内の)環境にホストを追加するときはいつでも、DNSにホストを追加する必要があります。 実行する必要のある手順のリストは次のとおりです。
プライマリネームサーバー
- 転送ゾーンファイル:新しいホストの「A」レコードを追加し、「Serial」の値をインクリメントします
- 逆引きゾーンファイル:新しいホストの「PTR」レコードを追加し、「Serial」の値をインクリメントします
- 新しいホストのプライベートIPアドレスを「信頼できる」ACLに追加します(
named.conf.options
)
次に、BINDをリロードします。
sudo service bind9 reload
セカンダリネームサーバー
- 新しいホストのプライベートIPアドレスを「信頼できる」ACLに追加します(
named.conf.options
)
次に、BINDをリロードします。
sudo service bind9 reload
DNSを使用するように新しいホストを構成する
- DNSサーバーを使用するようにresolv.confを構成します
nslookup
を使用してテストします
DNSからのホストの削除
環境からホストを削除する場合、またはDNSからホストを削除する場合は、サーバーをDNSに追加したときに追加されたものをすべて削除します(つまり、 上記の手順の逆)。
結論
これで、サーバーのプライベートネットワークインターフェイスをIPアドレスではなく名前で参照できるようになりました。 これにより、プライベートIPアドレスを覚えておく必要がなくなり、ファイルの読み取りと理解が容易になるため、サービスとアプリケーションの構成が容易になります。 また、さまざまな分散構成ファイルを編集する代わりに、構成を変更して、プライマリDNSサーバーである単一の場所にある新しいサーバーを指すようにすることができるため、保守が容易になります。
内部DNSを設定し、構成ファイルでプライベートFQDNを使用してネットワーク接続を指定したら、DNSサーバーを適切に維持することが重要です。 両方が利用できなくなると、それらに依存するサービスとアプリケーションは適切に機能しなくなります。 これが、少なくとも1つのセカンダリサーバーを使用してDNSを設定し、それらすべてのバックアップを維持することをお勧めする理由です。