前書き
サーバーの構成とインフラストラクチャを管理する重要な部分には、適切なドメインネームシステム（DNS）を設定することにより、ネットワークインターフェイスとIPアドレスを名前で簡単に検索する方法を維持することが含まれます。 IPアドレスの代わりに完全修飾ドメイン名（FQDN）を使用してネットワークアドレスを指定すると、サービスとアプリケーションの構成が容易になり、構成ファイルの保守性が向上します。 プライベートネットワーク用に独自のDNSを設定することは、サーバーの管理を改善する優れた方法です。
このチュートリアルでは、Ubuntu 14.04のBINDネームサーバーソフトウェア（BIND9）を使用して、プライベートホスト名とプライベートIPを解決するために仮想プライベートサーバー（VPS）で使用できる内部DNSサーバーのセットアップ方法について説明しますアドレス。 これは、内部ホスト名とプライベートIPアドレスを管理するための中心的な方法を提供します。これは、環境が数個以上のホストに拡大する場合に不可欠です。
このチュートリアルのCentOSバージョンは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サーバーで、aptを更新します。
sudo apt-get updateBINDをインストールします。
sudo apt-get install bind9 bind9utils bind9-docIPv4モード
続行する前に、BINDをIPv4モードに設定しましょう。 両方のサーバーで、bind9サービスパラメータファイルを編集します。
sudo vi /etc/default/bind9OPTIONS変数に「-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 of 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 of 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 of 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 — original
$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 — updated 1 of 3
@ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. (
3 ; Serialファイルの最後（SOAレコードの後）にある3つのレコードを削除します。 削除する行が不明な場合は、上記の「この行を削除」コメントでマークされます。
ファイルの最後に、次の行を使用してネームサーバーレコードを追加します（名前を独自のものに置き換えます）。 2番目の列は、これらが「NS」レコードであることを示していることに注意してください。
/etc/bind/zones/db.nyc3.example.com — updated 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/bind/zones/db.nyc3.example.com — updated 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/bind/zones/db.nyc3.example.com — updated
$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ファイルで指定された各逆引きゾーンに対して、逆引きゾーンファイルを作成します。 サンプルのdb.127ゾーンファイルに基づいてリバースゾーンファイルを作成します。 次のコマンドを使用して適切な場所にコピーします（逆ゾーン定義に一致するように宛先ファイル名を置き換えます）。
cd /etc/bind/zones
sudo cp ../db.127 ./db.10.128named.conf.localで定義された逆引きゾーンに対応する逆引きゾーンファイルを編集します。
sudo vi /etc/bind/zones/db.10.128最初は、次のようになります。
/etc/bind/zones/db.10.128 — original
$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 — updated 1 of 3
@ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. (
3 ; Serialファイルの最後（SOAレコードの後）にある2つのレコードを削除します。 削除する行が不明な場合は、上記の「この行を削除」コメントでマークされます。
ファイルの最後に、次の行を使用してネームサーバーレコードを追加します（名前を独自のものに置き換えます）。 2番目の列は、これらが「NS」レコードであることを示していることに注意してください。
/etc/bind/zones/db.10.128 — updated 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/bind/zones/db.10.128 — updated 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/bind/zones/db.10.128 — updated
$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 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 — updated 1 of 2 (secondary)
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 — updated 2 of 2 (secondary)
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 — updated (secondary)
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クライアントを構成する
「信頼できる」ACL内のすべてのサーバーがDNSサーバーにクエリを実行する前に、ns1とns2をネームサーバーとして使用するように各サーバーを構成する必要があります。 このプロセスはOSによって異なりますが、ほとんどのLinuxディストリビューションでは、/etc/resolv.confファイルにネームサーバーを追加する必要があります。
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サーバーを使用するように構成されました。
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 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 service bind9 reloadセカンダリネームサーバー
-
新しいホストのプライベートIPアドレスを「信頼できる」ACLに追加します（
named.conf.options）
次に、BINDをリロードします。
sudo service bind9 reloadDNSを使用するように新しいホストを構成する
-
DNSサーバーを使用するようにresolv.confを構成します
-
nslookupを使用してテストする
DNSからホストを削除する
環境からホストを削除する場合、またはDNSからホストを削除する場合は、サーバーをDNSに追加したときに追加されたすべてのものを削除します（つまり、 上記の手順の逆）。
結論
サーバーのプライベートネットワークインターフェイスを、IPアドレスではなく名前で参照できるようになりました。 これにより、プライベートIPアドレスを覚えておく必要がなくなり、ファイルの読み取りと理解が容易になるため、サービスとアプリケーションの構成が簡単になります。 また、さまざまな分散構成ファイルを編集する必要がなく、単一の場所にあるプライマリサーバーである新しいサーバーを指すように構成を変更できるようになり、メンテナンスが容易になりました。
内部DNSを設定し、構成ファイルがプライベートFQDNを使用してネットワーク接続を指定すると、DNSサーバーが適切に維持されるのはcriticalです。 両方が使用できなくなった場合、それらに依存するサービスとアプリケーションは適切に機能しなくなります。 これが、少なくとも1つのセカンダリサーバーでDNSをセットアップし、それらすべての作業バックアップを維持することが推奨される理由です。