Ubuntu16.04でBINDをプライベートネットワークDNSサーバーとして構成する方法
序章
サーバー構成とインフラストラクチャの管理の重要な部分には、適切なドメインネームシステム(DNS)を設定することにより、ネットワークインターフェイスとIPアドレスを名前で簡単に検索する方法を維持することが含まれます。 IPアドレスの代わりに完全修飾ドメイン名(FQDN)を使用してネットワークアドレスを指定すると、サービスとアプリケーションの構成が容易になり、構成ファイルの保守性が向上します。 プライベートネットワーク用に独自のDNSを設定することは、サーバーの管理を改善するための優れた方法です。
このチュートリアルでは、Ubuntu 16.04でBINDネームサーバーソフトウェア(BIND9)を使用して、サーバーがプライベートホスト名とプライベートIPアドレスを解決するために使用できる内部DNSサーバーをセットアップする方法について説明します。 これは、内部ホスト名とプライベートIPアドレスを管理するための中心的な方法を提供します。これは、環境が少数のホストを超える場合に不可欠です。
このチュートリアルのCentOSバージョンはここにあります。
前提条件
このチュートリアルを完了するには、次のものが必要です。
- プライベートネットワークが有効になっていると同じデータセンターで実行されている一部のサーバー。 これらはDNSクライアントになります。
- プライマリDNSサーバーとして機能する新しいサーバーns1
- (推奨)セカンダリDNSサーバーとして機能する新しいサーバー ns2
- 上記のサーバーへの
sudo
ユーザーによる管理アクセス。 Ubuntu16.04初期サーバーセットアップガイドに従ってこれをセットアップできます。
DNSの概念に慣れていない場合は、DNS管理の概要の最初の3つの部分を読むことをお勧めします。
インフラストラクチャと目標の例
この記事では、次のことを前提としています。
- 作成したDNSインフラストラクチャを利用する既存のクライアントサーバーが2つあります。 このガイドでは、これらをhost1およびhost2と呼びます。 インフラストラクチャに必要な数だけ追加できます。
- DNSネームサーバーとして指定される追加の2つのサーバーがあります。 このガイドでは、これらをns1およびns2と呼びます。
- これらのサーバーはすべて同じデータセンターに存在します。 これがnyc3データセンターであると想定します。
- これらのサーバーはすべてプライベートネットワークが有効になっています(
10.128.0.0/16
サブネット上にあります。 サーバーに合わせてこれを調整する必要があります)。 - すべてのサーバーは、「example.com」で実行されるWebアプリケーションに何らかの形で関連しています。
これらの仮定に基づいて、「nyc3.example.com」を使用してプライベートサブネットまたはゾーンを参照する命名スキームを使用することが理にかなっていると判断しました。 したがって、 host1 のプライベート完全修飾ドメイン名(FQDN)はhost1.nyc3.example.comになります。 次の表に関連する詳細を参照してください。
亭主 | 役割 | プライベートFQDN | プライベートIPアドレス |
---|---|---|---|
ns1 | プライマリDNSサーバー | ns1.nyc3.example.com | 10.128.10.11 |
ns2 | セカンダリDNSサーバー | ns2.nyc3.example.com | 10.128.20.12 |
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ができます。
プライマリ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
systemdユニットファイルを編集します。
- sudo systemctl edit --full bind9
ExecStart
ディレクティブの最後に「-4」を追加します。 次のようになります。
. . .
[Service]
ExecStart=/usr/sbin/named -f -u bind -4
終了したら、エディタを保存して閉じます。
systemdデーモンをリロードして、実行中のシステムに新しい構成を読み込みます。
- sudo systemctl daemon-reload
BINDを再起動して、変更を実装します。
- sudo systemctl restart bind9
BINDがインストールされたので、プライマリDNSサーバーを構成しましょう。
プライマリDNSサーバーを構成する
BINDの構成は、メイン構成ファイルnamed.conf
から含まれている複数のファイルで構成されています。 これらのファイル名はnamed
で始まります。これは、BINDが実行するプロセスの名前であるためです。 オプションファイルの設定から始めます。
オプションファイルの構成
ns1 で、named.conf.options
ファイルを開いて編集します。
- sudo nano /etc/bind/named.conf.options
既存のoptions
ブロックの上に、「trusted」と呼ばれる新しいACLブロックを作成します。 ここで、再帰DNSクエリを許可するクライアントのリストを定義します(つまり、 ns1 と同じデータセンターにあるサーバー)。 プライベートIPアドレスの例を使用して、 ns1 、 ns2 、 host1 、およびhost2を信頼できるクライアントのリストに追加します。
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
};
options {
. . .
信頼できるDNSクライアントのリストができたので、options
ブロックを編集します。 現在、ブロックの開始は次のようになります。
. . .
};
options {
directory "/var/cache/bind";
. . .
}
directory
ディレクティブの下に、強調表示された構成行を追加します(そして、適切な ns1 IPアドレスに置き換えます)。次のようになります。
. . .
};
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 nano /etc/bind/named.conf.local
いくつかのコメントを除いて、ファイルは空である必要があります。 ここでは、順方向ゾーンと逆方向ゾーンを指定します。
次の行でフォワードゾーンを追加します(ゾーン名を独自のものに置き換えます)。
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」で始まることに注意してください)。 :
. . .
};
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 nano /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」にインクリメントします。 次のようになります。
@ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. (
3 ; Serial
. . .
次に、ファイルの最後(SOAレコードの後)にある3つのレコードを削除します。 削除する行がわからない場合は、上の「この行を削除」コメントでマークされています。
ファイルの最後に、ネームサーバーレコードを次の行で追加します(名前を独自のレコードに置き換えます)。 2番目の列は、これらが「NS」レコードであることを指定していることに注意してください。
. . .
; 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レコードを次のように追加します。
. . .
; 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
ファイルを保存して閉じます。
最後のフォワードゾーンファイルの例は次のようになります。
$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「
ns1 で、named.conf.local
ファイルで指定された逆引きゾーンごとに、逆引きゾーンファイルを作成します。 サンプルのdb.127
ゾーンファイルに基づいてリバースゾーンファイルを作成します。 次のコマンドを使用して、適切な場所にコピーします(逆引きゾーンの定義と一致するように宛先ファイル名を置き換えます)。
- cd /etc/bind/zones
- sudo cp ../db.127 ./db.10.128
named.conf.local
で定義された逆引きゾーンに対応する逆引きゾーンファイルを編集します。
- sudo nano /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値をインクリメントします。 次のようになります。
@ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. (
3 ; Serial
. . .
次に、ファイルの最後(SOAレコードの後)にある2つのレコードを削除します。 削除する行がわからない場合は、上の「この行を削除」コメントでマークされています。
ファイルの最後に、ネームサーバーレコードを次の行で追加します(名前を独自のレコードに置き換えます)。 2番目の列は、これらが「NS」レコードであることを指定していることに注意してください。
. . .
; 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アドレスを必ず置き換えてください。
. . .
; 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
リバースゾーンファイルを保存して閉じます(リバースゾーンファイルをさらに追加する必要がある場合は、このセクションを繰り返します)。
最後の例のリバースゾーンファイルは次のようになります。
$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 systemctl restart bind9
UFWファイアウォールを構成している場合は、次のように入力してBINDへのアクセスを開きます。
- sudo ufw allow Bind9
これで、プライマリDNSサーバーがセットアップされ、DNSクエリに応答する準備が整いました。 セカンダリDNSサーバーの作成に移りましょう。
セカンダリDNSサーバーを構成する
ほとんどの環境では、プライマリが使用できなくなった場合に要求に応答するセカンダリDNSサーバーを設定することをお勧めします。 幸い、セカンダリDNSサーバーの構成ははるかに簡単です。
ns2 で、named.conf.options
ファイルを編集します。
- sudo nano /etc/bind/named.conf.options
ファイルの先頭に、すべての信頼できるサーバーのプライベートIPアドレスを含むACLを追加します。
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
};
options {
. . .
directory
ディレクティブの下に、次の行を追加します。
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 nano /etc/bind/named.conf.local
プライマリDNSサーバーのマスターゾーンに対応するスレーブゾーンを定義します。 タイプは「スレーブ」であり、ファイルにはパスが含まれておらず、プライマリDNSサーバーのプライベートIPに設定する必要があるmasters
ディレクティブがあることに注意してください。 プライマリDNSサーバーで複数のリバースゾーンを定義した場合は、必ずここにすべて追加してください。
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
チェックアウトしたら、BINDを再起動します。
- sudo systemctl restart bind9
UFWファイアウォールルールを変更して、サーバーへのDNS接続を許可します。
- sudo ufw allow Bind9
これで、プライベートネットワーク名とIPアドレスを解決するためのプライマリDNSサーバーとセカンダリDNSサーバーができました。 次に、プライベートDNSサーバーを使用するようにクライアントサーバーを構成する必要があります。
DNSクライアントを構成する
「信頼できる」ACL内のすべてのサーバーがDNSサーバーにクエリを実行する前に、ns1およびns2をネームサーバーとして使用するように各サーバーを構成する必要があります。 このプロセスはOSによって異なりますが、ほとんどのLinuxディストリビューションでは、ネームサーバーを/etc/resolv.conf
ファイルに追加する必要があります。
Ubuntuクライアント
UbuntuおよびDebianLinuxサーバーでは、/etc/network/interfaces
ファイルを編集できます。
- sudo nano /etc/network/interfaces
内部で、dns-nameservers
行を見つけ、現在そこにあるリストの前に独自のネームサーバーを追加します。 その線の下に、インフラストラクチャのベースドメインを指すdns-search
オプションを追加します。 この場合、これは「nyc3.example.com」になります。
. . .
dns-nameservers 10.128.10.11 10.128.20.12 8.8.8.8
dns-search nyc3.example.com
. . .
終了したら、ファイルを保存して閉じます。
次に、ネットワークサービスを再起動し、次のコマンドを使用して新しい変更を適用します。 eth0
をネットワークインターフェイスの名前に置き換えてください。
- sudo ifdown --force eth0 && sudo ip addr flush dev eth0 && sudo ifup --force eth0
これにより、現在の接続を切断せずにネットワークを再起動する必要があります。 正しく機能した場合は、次のように表示されます。
OutputRTNETLINK answers: No such process
Waiting for DAD... Done
次のように入力して、設定が適用されたことを再確認します。
- cat /etc/resolv.conf
/etc/resolv.conf
ファイルと検索ドメインにネームサーバーが表示されます。
Output# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 10.128.10.11
nameserver 10.128.20.12
nameserver 8.8.8.8
search nyc3.example.com
これで、クライアントはDNSサーバーを使用するように構成されました。
CentOSクライアント
CentOS、RedHat、およびFedora Linux VPSで、/etc/sysconfig/network-scripts/ifcfg-eth0
ファイルを編集します。 eth0
をプライマリネットワークインターフェイスの名前に置き換える必要がある場合があります。
- sudo nano /etc/sysconfig/network-scripts/ifcfg-eth0
DNS1
およびDNS2
オプションを検索し、プライマリおよびセカンダリネームサーバーのプライベートIPアドレスに設定します。 インフラストラクチャのベースドメインにDOMAIN
パラメータを追加します。 このガイドでは、これは「nyc3.example.com」になります。
. . .
DNS1=10.128.10.11
DNS2=10.128.20.12
DOMAIN='nyc3.example.com'
. . .
終了したら、ファイルを保存して閉じます。
次に、次のように入力してネットワークサービスを再起動します。
- sudo systemctl restart network
コマンドは数秒間ハングする場合がありますが、すぐにプロンプトに戻るはずです。
次のように入力して、変更が適用されたことを確認します。
- cat /etc/resolv.conf
リストにネームサーバーと検索ドメインが表示されます。
nameserver 10.128.10.11
nameserver 10.128.20.12
search nyc3.example.com
クライアントをテストする
nslookup
を使用して、クライアントがネームサーバーにクエリを実行できるかどうかをテストします。 これは、構成済みで「信頼できる」ACLにあるすべてのクライアントで実行できるはずです。
CentOSクライアントの場合、次の機能を使用してユーティリティをインストールする必要があります。
- sudo yum install bind-utils
フォワードルックアップ
たとえば、次のコマンドを実行することにより、前方参照を実行して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
次のような出力が表示されます。
OutputServer: 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 systemctl reload bind9
セカンダリネームサーバー
- 新しいホストのプライベートIPアドレスを「信頼できる」ACLに追加します(
named.conf.options
)
次に、BINDをリロードします。
- sudo systemctl reload bind9
DNSを使用するように新しいホストを構成する
- DNSサーバーを使用するように
/etc/resolv.conf
を構成します nslookup
を使用してテストします
DNSからのホストの削除
環境からホストを削除する場合、またはDNSからホストを削除する場合は、サーバーをDNSに追加したときに追加されたものをすべて削除します(つまり、 上記の手順の逆)。
結論
これで、サーバーのプライベートネットワークインターフェイスをIPアドレスではなく名前で参照できるようになりました。 これにより、プライベートIPアドレスを覚えておく必要がなくなり、ファイルの読み取りと理解が容易になるため、サービスとアプリケーションの構成が容易になります。 また、さまざまな分散構成ファイルを編集する代わりに、構成を変更して、プライマリDNSサーバーである単一の場所にある新しいサーバーを指すようにすることができるため、保守が容易になります。
内部DNSを設定し、構成ファイルでプライベートFQDNを使用してネットワーク接続を指定したら、DNSサーバーを適切に維持することが重要です。 両方が利用できなくなると、それらに依存するサービスとアプリケーションは適切に機能しなくなります。 これが、少なくとも1つのセカンダリサーバーを使用してDNSを設定し、それらすべてのバックアップを維持することをお勧めする理由です。