前書き
サーバーの構成とインフラストラクチャを管理する重要な部分には、適切なドメインネームシステム（DNS）を設定することにより、ネットワークインターフェイスとIPアドレスを名前で簡単に検索する方法を維持することが含まれます。 IPアドレスの代わりに完全修飾ドメイン名（FQDN）を使用してネットワークアドレスを指定すると、サービスとアプリケーションの構成が容易になり、構成ファイルの保守性が向上します。 プライベートネットワーク用に独自のDNSを設定することは、サーバーの管理を改善する優れた方法です。
このチュートリアルでは、CentOS 7でBINDネームサーバーソフトウェア（BIND9）を使用して、プライベートホスト名とプライベートIPを解決するために仮想プライベートサーバー（VPS）で使用できる内部DNSサーバーのセットアップ方法について説明します。アドレス。 これは、内部ホスト名とプライベートIPアドレスを管理するための中心的な方法を提供します。これは、環境が数個以上のホストに拡大する場合に不可欠です。
このチュートリアルのUbuntuバージョンはhereにあります。
前提条件
このチュートリアルを完了するには、次のものが必要です。
-
同じデータセンターで実行されており、private networking enabledを持つ一部のサーバー
-
プライマリDNSサーバーとして機能する新しいVPS、ns1
-
オプション：セカンダリDNSサーバーとして機能する新しいVPS、ns2
-
上記のすべてへのルートアクセス（steps 1-4 here）
DNSの概念に慣れていない場合は、少なくともIntroduction to Managing 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」になります。 関連する詳細については、次の表を参照してください。
| Host | Role | プライベートFQDN | プライベートIPアドレス |
|---|---|---|---|
host1 |
ジェネリックホスト1 |
host1.nyc3.example.com |
10.128.100.101 |
host2 |
ジェネリックホスト2 |
host2.nyc3.example.com |
10.128.200.102 |
Note:既存の設定は異なりますが、名前とIPアドレスの例を使用して、機能する内部DNSを提供するようにDNSサーバーを構成する方法を示します。 ホスト名とプライベートIPアドレスを独自のものに置き換えることにより、このセットアップを独自の環境に簡単に適合させることができるはずです。 命名スキームでデータセンターの地域名を使用する必要はありませんが、ここでは、これらのホストが特定のデータセンターのプライベートネットワークに属していることを示すために使用します。 複数のデータセンターを利用する場合、それぞれのデータセンター内に内部DNSをセットアップできます。
私たちの目標
このチュートリアルの終わりまでに、プライマリDNSサーバーns1と、オプションでバックアップとして機能するセカンダリDNSサーバーns2ができあがります。
以下に、名前とIPアドレスの例を示した表を示します。
| Host | Role | プライベート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をインストールする
Note:redで強調表示されているテキストは重要です！ 多くの場合、独自の設定に置き換える必要があるもの、または構成ファイルに変更または追加する必要があるものを示すために使用されます。 たとえば、host1.nyc3.example.comのようなものが表示された場合は、それを独自のサーバーのFQDNに置き換えます。 同様に、host1_private_IPが表示された場合は、それを自分のサーバーのプライベートIPアドレスに置き換えます。
ns1とns2の両方のDNSサーバーで、yumを使用してBINDをインストールします。
sudo yum install bind bind-utilsyを入力して、プロンプトを確認します。
BINDがインストールされたので、プライマリDNSサーバーを設定しましょう。
プライマリDNSサーバーを構成する
BINDの構成は、メイン構成ファイルnamed.confから含まれる複数のファイルで構成されます。 これらのファイル名は「named」で始まります。これは、BINDが実行するプロセスの名前だからです。 オプションファイルの構成から始めます。
バインドを構成する
BINDのプロセスはnamedとして知られています。 そのため、多くのファイルは「BIND」ではなく「named」を参照しています。
ns1で、編集のためにnamed.confファイルを開きます。
sudo vi /etc/named.conf既存のoptionsブロックの上に、「trusted」と呼ばれる新しいACLブロックを作成します。 ここで、再帰DNSクエリを許可するクライアントのリストを定義します（つまり、 ns1と同じデータセンターにあるサーバー。 プライベートIPアドレスの例を使用して、ns1、ns2、host1、およびhost2を信頼できるクライアントのリストに追加します。
/etc/named.conf — 1 of 4
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ブロックを編集します。 ns1のプライベートIPアドレスをlisten-on port 53ディレクティブに追加し、listen-on-v6行をコメントアウトします。
/etc/named.conf — 2 of 4
options {
listen-on port 53 { 127.0.0.1; 10.128.10.11; };
# listen-on-v6 port 53 { ::1; };
...これらのエントリの下で、allow-transferディレクティブを「none」からns2のプライベートIPアドレスに変更します。 また、allow-queryディレクティブを「localhost」から「trusted」に変更します。
/etc/named.conf — 3 of 4
...
options {
...
allow-transfer { 10.128.20.12; }; # disable zone transfers by default
...
allow-query { trusted; }; # allows queries from "trusted" clients
...ファイルの最後に、次の行を追加します。
/etc/named.conf — 4 of 4
include "/etc/named/named.conf.local";ここで、named.confを保存して終了します。 上記の構成では、自分のサーバー（「信頼できる」サーバー）のみがDNSサーバーにクエリを実行できるように指定されています。
次に、ローカルファイルを構成して、DNSゾーンを指定します。
ローカルファイルを構成する
ns1で、編集のためにnamed.conf.localファイルを開きます。
sudo vi /etc/named/named.conf.localファイルは空でなければなりません。 ここでは、順ゾーンと逆ゾーンを指定します。
次の行で順ゾーンを追加します（ゾーン名を独自のものに置き換えます）。
/etc/named/named.conf.local — 1 of 2
zone "nyc3.example.com" {
type master;
file "/etc/named/zones/db.nyc3.example.com"; # zone file path
};プライベートサブネットが10.128.0.0/16であると仮定して、次の行で逆引きゾーンを追加します（逆引きゾーン名は、「10.128」のオクテット反転である「128.10」で始まることに注意してください）。
/etc/named/named.conf.local — 2 of 2
zone "128.10.in-addr.arpa" {
type master;
file "/etc/named/zones/db.10.128"; # 10.128.0.0/16 subnet
};サーバーが複数のプライベートサブネットにまたがっているが同じデータセンターにある場合は、個別のサブネットごとに追加のゾーンとゾーンファイルを必ず指定してください。 必要なゾーンをすべて追加し終えたら、named.conf.localファイルを保存して終了します。
ゾーンがBINDで指定されたので、対応する順ゾーンファイルと逆ゾーンファイルを作成する必要があります。
順ゾーンファイルを作成する
フォワードゾーンファイルは、フォワードDNSルックアップ用のDNSレコードを定義する場所です。 つまり、DNSが名前クエリ（たとえば「host1.nyc3.example.com」）を受信すると、フォワードゾーンファイルを調べて、host1の対応するプライベートIPアドレスを解決します。
ゾーンファイルが格納されるディレクトリを作成しましょう。 named.conf.localの構成によると、その場所は/etc/named/zonesである必要があります。
sudo chmod 755 /etc/named
sudo mkdir /etc/named/zones次に、順ゾーンファイルを編集しましょう。
sudo vi /etc/named/zones/db.nyc3.example.com最初に、SOAレコードを追加します。 強調表示されたns1 FQDNを独自のFQDNに置き換え、2番目の「nyc3.example.com」を独自のドメインに置き換えます。 ゾーンファイルを編集するたびに、namedプロセスを再開する前に、serial値をインクリメントする必要があります。値は「3」にインクリメントされます。 これは次のようになります。
/etc/named/zones/db.nyc3.example.com — 1 of 3
@ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTLその後、次の行を使用してネームサーバーレコードを追加します（名前を独自のものに置き換えます）。 2番目の列は、これらが「NS」レコードであることを示していることに注意してください。
/etc/named/zones/db.nyc3.example.com — 2 of 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/named/zones/db.nyc3.example.com — 3 of 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.102db.nyc3.example.comファイルを保存して終了します。
最終的なフォワードゾーンファイルの例は次のようになります。
/etc/named/zones/db.nyc3.example.com — complete
$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ルックアップ用のDNS PTRレコードを定義する場所です。 つまり、DNSがIPアドレス（たとえば「10.128.100.101」）でクエリを受信すると、逆ゾーンファイルを検索して、対応するFQDN（この場合は「host1.nyc3.example.com」）を解決します。 。
ns1で、named.conf.localファイルで指定された各逆引きゾーンに対して、逆引きゾーンファイルを作成します。
named.conf.localで定義された逆引きゾーンに対応する逆引きゾーンファイルを編集します。
sudo vi /etc/named/zones/db.10.128フォワードゾーンファイルと同じ方法で、強調表示されたns1 FQDNを独自のFQDNに置き換えてから、2番目の「nyc3.example.com」を独自のドメインに置き換えます。 ゾーンファイルを編集するたびに、namedプロセスを再開する前に、serial値をインクリメントする必要があります。値は「3」にインクリメントされます。 これは次のようになります。
/etc/named/zones/db.10.128 — 1 of 3
@ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTLその後、次の行を使用してネームサーバーレコードを追加します（名前を独自のものに置き換えます）。 2番目の列は、これらが「NS」レコードであることを示していることに注意してください。
/etc/named/zones/db.10.128 — 2 of 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/named/zones/db.10.128 — 3 of 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/named/zones/db.10.128 — complete
$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.102BIND構成構文を確認してください
次のコマンドを実行して、named.conf*ファイルの構文を確認します。
sudo named-checkconf名前付き構成ファイルに構文エラーがない場合、シェルプロンプトに戻り、エラーメッセージは表示されません。 構成ファイルに問題がある場合は、エラーメッセージとConfigure Primary DNS Serverセクションを確認してから、named-checkconfを再試行してください。
named-checkzoneコマンドを使用して、ゾーンファイルの正確性を確認できます。 最初の引数はゾーン名を指定し、2番目の引数は対応するゾーンファイルを指定します。これらは両方ともnamed.conf.localで定義されています。
たとえば、「nyc3.example.com」フォワードゾーン構成を確認するには、次のコマンドを実行します（フォワードゾーンとファイルに一致するように名前を変更します）。
sudo named-checkzone nyc3.example.com /etc/named/zones/db.nyc3.example.comまた、「128.10.in-addr.arpa」逆引きゾーン構成を確認するには、次のコマンドを実行します（逆引きゾーンとファイルに一致するように番号を変更します）。
sudo named-checkzone 128.10.in-addr.arpa /etc/named/zones/db.10.128すべての構成ファイルとゾーンファイルにエラーがない場合、BINDサービスを再起動する準備ができているはずです。
BINDを開始
BINDを開始します。
sudo systemctl start named今、あなたはそれを有効にしたいので、起動時に起動します：
sudo systemctl enable namedこれで、プライマリDNSサーバーがセットアップされ、DNSクエリに応答する準備が整いました。 セカンダリDNSサーバーの作成に進みましょう。
セカンダリDNSサーバーを構成する
ほとんどの環境では、プライマリが使用できなくなった場合にリクエストに応答するセカンダリDNSサーバーをセットアップすることをお勧めします。 幸いなことに、セカンダリDNSサーバーの構成ははるかに簡単です。
ns2で、named.confファイルを編集します。
sudo vi /etc/named.conf[.note]＃Note:これらの手順をスキップしたい場合は、ns1のnamed.confファイルをコピーして、ns2のプライベートIPアドレスをリッスンするように変更して許可しないでください。転送。
＃
既存のoptionsブロックの上に、「trusted」と呼ばれる新しいACLブロックを作成します。 ここで、再帰DNSクエリを許可するクライアントのリストを定義します（つまり、 ns1と同じデータセンターにあるサーバー。 プライベートIPアドレスの例を使用して、ns1、ns2、host1、およびhost2を信頼できるクライアントのリストに追加します。
/etc/named.conf — 1 of 4
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ブロックを編集します。 ns1のプライベートIPアドレスをlisten-on port 53ディレクティブに追加し、listen-on-v6行をコメントアウトします。
/etc/named.conf — 2 of 4
options {
listen-on port 53 { 127.0.0.1; 10.128.20.12; };
# listen-on-v6 port 53 { ::1; };
...allow-queryディレクティブを「localhost」から「trusted」に変更します。
/etc/named.conf — 3 of 4
...
options {
...
allow-query { trusted; }; # allows queries from "trusted" clients
...ファイルの最後に、次の行を追加します。
/etc/named.conf — 4 of 4
include "/etc/named/named.conf.local";ここで、named.confを保存して終了します。 上記の構成では、自分のサーバー（「信頼できる」サーバー）のみがDNSサーバーにクエリを実行できるように指定されています。
次に、ローカルファイルを構成して、DNSゾーンを指定します。
named.confを保存して終了します。
次に、named.conf.localファイルを編集します。
sudo chmod 755 /etc/named
sudo vi /etc/named/named.conf.localプライマリDNSサーバーのマスターゾーンに対応するスレーブゾーンを定義します。 タイプは「スレーブ」であり、ファイルにはパスが含まれておらず、プライマリDNSサーバーのプライベートIPに設定する必要があるmastersディレクティブがあることに注意してください。 プライマリDNSサーバーで複数の逆ゾーンを定義した場合は、それらをすべてここに追加してください。
/etc/named/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チェックアウトしたら、BINDを開始します。
sudo systemctl start named起動時にBINDを有効にする：
sudo systemctl enable namedこれで、プライベートネットワーク名とIPアドレスを解決するためのプライマリおよびセカンダリDNSサーバーができました。 次に、プライベートDNSサーバーを使用するようにサーバーを構成する必要があります。
DNSクライアントを構成する
「信頼できる」ACL内のすべてのサーバーがDNSサーバーにクエリを実行する前に、ns1とns2をネームサーバーとして使用するように各サーバーを構成する必要があります。 このプロセスはOSによって異なりますが、ほとんどのLinuxディストリビューションでは、/etc/resolv.confファイルにネームサーバーを追加する必要があります。
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サーバーを使用するように構成されました。
Ubuntuクライアント
UbuntuおよびDebianLinux VPSでは、起動時に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サーバーを使用するように構成されました。
テストクライアント
「bind-utils」パッケージに含まれているnslookupを使用して、クライアントがネームサーバーにクエリを実行できるかどうかをテストします。 これは、設定済みで「信頼できる」ACLにあるすべてのクライアントで実行できるはずです。
前方参照
たとえば、次のコマンドを実行して、前方参照を実行してhost1.nyc3.example.comのIPアドレスを取得できます。
nslookup host1searchオプションがプライベートサブドメインに設定されているため、「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」レコードを追加し、「シリアル」の値を増やします
-
リバースゾーンファイル：新しいホストの「PTR」レコードを追加し、「シリアル」の値を増やします
-
新しいホストのプライベートIPアドレスを「信頼できる」ACLに追加します（
named.conf.options）
次に、BINDをリロードします。
sudo systemctl reload namedセカンダリネームサーバー
-
新しいホストのプライベートIPアドレスを「信頼できる」ACLに追加します（
named.conf.options）
次に、BINDをリロードします。
sudo systemctl reload namedDNSを使用するように新しいホストを構成する
-
DNSサーバーを使用するようにresolv.confを構成します
-
nslookupを使用してテストする
DNSからホストを削除する
環境からホストを削除する場合、またはDNSからホストを削除する場合は、サーバーをDNSに追加したときに追加されたすべてのものを削除します（つまり、 上記の手順の逆）。
結論
サーバーのプライベートネットワークインターフェイスを、IPアドレスではなく名前で参照できるようになりました。 これにより、プライベートIPアドレスを覚えておく必要がなくなり、ファイルの読み取りと理解が容易になるため、サービスとアプリケーションの構成が簡単になります。 また、さまざまな分散構成ファイルを編集する必要がなく、単一の場所にあるプライマリサーバーである新しいサーバーを指すように構成を変更できるようになり、メンテナンスが容易になりました。
内部DNSを設定し、構成ファイルがプライベートFQDNを使用してネットワーク接続を指定すると、DNSサーバーが適切に維持されるのはcriticalです。 両方が使用できなくなった場合、それらに依存するサービスとアプリケーションは適切に機能しなくなります。 これが、少なくとも1つのセカンダリサーバーでDNSをセットアップし、それらすべての作業バックアップを維持することが推奨される理由です。