CentOS7でBINDをプライベートネットワークDNSサーバーとして構成する方法
序章
サーバー構成とインフラストラクチャの管理の重要な部分には、適切なドメインネームシステム(DNS)を設定することにより、ネットワークインターフェイスとIPアドレスを名前で簡単に検索する方法を維持することが含まれます。 IPアドレスの代わりに完全修飾ドメイン名(FQDN)を使用してネットワークアドレスを指定すると、サービスとアプリケーションの構成が容易になり、構成ファイルの保守性が向上します。 プライベートネットワーク用に独自のDNSを設定することは、サーバーの管理を改善するための優れた方法です。
このチュートリアルでは、仮想プライベートサーバー(VPS)がプライベートホスト名とプライベートIPを解決するために使用できるCentOS 7のBINDネームサーバーソフトウェア(BIND9)を使用して、内部DNSサーバーをセットアップする方法について説明します。アドレス。 これは、内部ホスト名とプライベートIPアドレスを管理するための中心的な方法を提供します。これは、環境が少数のホストを超える場合に不可欠です。
このチュートリアルのUbuntuバージョンはここにあります。
前提条件
このチュートリアルを完了するには、次のものが必要です。
- 同じデータセンターで実行されており、プライベートネットワークが有効になっている一部のサーバー
- プライマリ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サーバーで、yumを使用してBINDをインストールします。
- sudo yum install bind bind-utils
次のように入力してプロンプトを確認します y
.
BINDがインストールされたので、プライマリDNSサーバーを構成しましょう。
プライマリDNSサーバーを構成する
BINDの構成は、メイン構成ファイルから含まれている複数のファイルで構成されています。 named.conf
. これらのファイル名は「named」で始まります。これは、BINDが実行するプロセスの名前であるためです。 オプションファイルの設定から始めます。
バインドを構成する
BINDのプロセスは、名前付きとして知られています。 そのため、ファイルの多くは「BIND」ではなく「named」を参照しています。
ns1 で、 named.conf
編集用ファイル:
- sudo vi /etc/named.conf
既存の上 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
};
信頼できるDNSクライアントのリストができたので、 options
ブロック。 ns1のプライベートIPアドレスをに追加します listen-on port 53
ディレクティブ、およびコメントアウト listen-on-v6
ライン:
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」へのディレクティブ:
...
options {
...
allow-transfer { 10.128.20.12; }; # disable zone transfers by default
...
allow-query { trusted; }; # allows queries from "trusted" clients
...
ファイルの最後に、次の行を追加します。
include "/etc/named/named.conf.local";
保存して終了します named.conf
. 上記の構成では、独自のサーバー(「信頼できる」サーバー)のみがDNSサーバーにクエリを実行できるように指定されています。
次に、DNSゾーンを指定するために、ローカルファイルを構成します。
ローカルファイルを構成する
ns1 で、 named.conf.local
編集用ファイル:
- sudo vi /etc/named/named.conf.local
ファイルは空である必要があります。 ここでは、順方向ゾーンと逆方向ゾーンを指定します。
次の行でフォワードゾーンを追加します(ゾーン名を独自のものに置き換えます)。
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」で始まることに注意してください)。
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レコードを追加する必要があります。 強調表示されたns1FQDNを独自のFQDNに置き換えてから、2番目の「nyc3.example.com」を独自のドメインに置き換えます。 ゾーンファイルを編集するたびに、serialの値をインクリメントしてから再起動する必要があります。 named
プロセス–「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」レコードであることを指定していることに注意してください。
; 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
ファイル、リバースゾーンファイルを作成します。
で定義された逆引きゾーンに対応する逆引きゾーンファイルを編集します named.conf.local
:
- sudo vi /etc/named/zones/db.10.128
転送ゾーンファイルと同じ方法で、強調表示されたns1 FQDNを独自のFQDNに置き換えてから、2番目の「nyc3.example.com」を独自のドメインに置き換えます。 ゾーンファイルを編集するたびに、serialの値をインクリメントしてから再起動する必要があります。 named
プロセス–「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」レコードであることを指定していることに注意してください。
; name servers - NS records
IN NS ns1.nyc3.example.com.
IN NS ns2.nyc3.example.com.
それから加えて PTR
編集中のゾーンファイルのサブネット上にIPアドレスがあるすべてのサーバーのレコード。 この例では、すべてのホストが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
また。
The 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
注:これらの手順をスキップしたい場合は、ns1をコピーできます。 named.conf
ファイルを作成し、 ns2 のプライベートIPアドレスをリッスンし、転送を許可しないように変更します。
既存の上 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
};
信頼できるDNSクライアントのリストができたので、 options
ブロック。 ns1のプライベートIPアドレスをに追加します listen-on port 53
ディレクティブ、およびコメントアウト listen-on-v6
ライン:
options {
listen-on port 53 { 127.0.0.1; 10.128.20.12; };
# listen-on-v6 port 53 { ::1; };
...
変化する allow-query
「localhost」から「trusted」へのディレクティブ:
...
options {
...
allow-query { trusted; }; # allows queries from "trusted" clients
...
ファイルの最後に、次の行を追加します。
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サーバーのマスターゾーンに対応するスレーブゾーンを定義します。 タイプは「スレーブ」であり、ファイルにはパスが含まれておらず、 masters
プライマリDNSサーバーのプライベートIPに設定する必要があるディレクティブ。 プライマリ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 start named
BINDを有効にして起動時に開始します。
sudo systemctl enable named
これで、プライベートネットワーク名とIPアドレスを解決するためのプライマリDNSサーバーとセカンダリ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アドレスに置き換えます)。
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およびDebianLinuxVPSでは、 head
に追加されるファイル resolv.conf
起動時:
- sudo vi /etc/resolvconf/resolv.conf.d/head
次の行をファイルに追加します(プライベートドメイン、ns1およびns2プライベートIPアドレスに置き換えます)。
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サーバーを使用するように構成されました。
クライアントをテストする
使用する nslookup
—「bind-utils」パッケージに含まれています—クライアントがネームサーバーにクエリを実行できるかどうかをテストします。 これは、構成済みで「信頼できる」ACLにあるすべてのクライアントで実行できるはずです。
フォワードルックアップ
たとえば、次のコマンドを実行することにより、前方参照を実行してhost1.nyc3.example.comのIPアドレスを取得できます。
- nslookup host1
「host1」をクエリすると、「host1.nyc3.example.com」に展開されます。 search
オプションがプライベートサブドメインに設定されている場合、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 systemctl reload named
セカンダリネームサーバー
- 新しいホストのプライベートIPアドレスを「信頼できる」ACLに追加します(
named.conf.options
)
次に、BINDをリロードします。
- sudo systemctl reload named
DNSを使用するように新しいホストを構成する
- DNSサーバーを使用するようにresolv.confを構成します
- を使用してテスト
nslookup
DNSからのホストの削除
環境からホストを削除する場合、またはDNSからホストを削除する場合は、サーバーをDNSに追加したときに追加されたものをすべて削除します(つまり、 上記の手順の逆)。
結論
これで、サーバーのプライベートネットワークインターフェイスをIPアドレスではなく名前で参照できるようになりました。 これにより、プライベートIPアドレスを覚えておく必要がなくなり、ファイルの読み取りと理解が容易になるため、サービスとアプリケーションの構成が容易になります。 また、さまざまな分散構成ファイルを編集する代わりに、構成を変更して、プライマリDNSサーバーである単一の場所にある新しいサーバーを指すようにすることができるため、保守が容易になります。
内部DNSを設定し、構成ファイルでプライベートFQDNを使用してネットワーク接続を指定したら、DNSサーバーを適切に維持することが重要です。 両方が利用できなくなると、それらに依存するサービスとアプリケーションは適切に機能しなくなります。 これが、少なくとも1つのセカンダリサーバーを使用してDNSを設定し、それらすべてのバックアップを維持することをお勧めする理由です。