序章

サーバー構成とインフラストラクチャの管理の重要な部分には、適切なドメインネームシステム（DNS）を設定することにより、ネットワークインターフェイスとIPアドレスを名前で簡単に検索する方法を維持することが含まれます。 IPアドレスの代わりに完全修飾ドメイン名（FQDN）を使用してネットワークアドレスを指定すると、サービスとアプリケーションの構成が容易になり、構成ファイルの保守性が向上します。 プライベートネットワーク用に独自のDNSを設定することは、サーバーの管理を改善するための優れた方法です。

このチュートリアルでは、仮想プライベートサーバー（VPS）がプライベートホスト名とプライベートIPを解決するために使用できるCentOS 7のBINDネームサーバーソフトウェア（BIND9）を使用して、内部DNSサーバーをセットアップする方法について説明します。アドレス。 これは、内部ホスト名とプライベートIPアドレスを管理するための中心的な方法を提供します。これは、環境が少数のホストを超える場合に不可欠です。

このチュートリアルのUbuntuバージョンはここにあります。

前提条件

このチュートリアルを完了するには、次のものが必要です。

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をインストールします。

  1. sudo yum install bind bind-utils

次のように入力してプロンプトを確認します y.

BINDがインストールされたので、プライマリDNSサーバーを構成しましょう。

プライマリDNSサーバーを構成する

BINDの構成は、メイン構成ファイルから含まれている複数のファイルで構成されています。 named.conf. これらのファイル名は「named」で始まります。これは、BINDが実行するプロセスの名前であるためです。 オプションファイルの設定から始めます。

バインドを構成する

BINDのプロセスは、名前付きとして知られています。 そのため、ファイルの多くは「BIND」ではなく「named」を参照しています。

ns1 で、 named.conf 編集用ファイル：

  1. sudo vi /etc/named.conf

既存の上 options ブロック、「trusted」と呼ばれる新しいACLブロックを作成します。 ここで、再帰DNSクエリを許可するクライアントのリストを定義します（つまり、 ns1）と同じデータセンターにあるサーバー。 プライベートIPアドレスの例を使用して、 ns1 、 ns2 、 host1 、およびhost2を信頼できるクライアントのリストに追加します。

/etc/named.conf —1/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/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/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/4
include "/etc/named/named.conf.local";

保存して終了します named.conf. 上記の構成では、独自のサーバー（「信頼できる」サーバー）のみがDNSサーバーにクエリを実行できるように指定されています。

次に、DNSゾーンを指定するために、ローカルファイルを構成します。

ローカルファイルを構成する

ns1 で、 named.conf.local 編集用ファイル：

  1. sudo vi /etc/named/named.conf.local

ファイルは空である必要があります。 ここでは、順方向ゾーンと逆方向ゾーンを指定します。

次の行でフォワードゾーンを追加します（ゾーン名を独自のものに置き換えます）。

/etc/named/named.conf.local —1/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:

  1. sudo chmod 755 /etc/named

  2. sudo mkdir /etc/named/zones

次に、フォワードゾーンファイルを編集しましょう。

  1. sudo vi /etc/named/zones/db.nyc3.example.com

まず、SOAレコードを追加する必要があります。 強調表示されたns1FQDNを独自のFQDNに置き換えてから、2番目の「nyc3.example.com」を独自のドメインに置き換えます。 ゾーンファイルを編集するたびに、serialの値をインクリメントしてから再起動する必要があります。 named プロセス–「3」にインクリメントします。 次のようになります。

/etc/named/zones/db.nyc3.example.com —1/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/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/named/zones/db.nyc3.example.com —完了
  1. $TTL    604800

  2. @       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (

  3. 			      3		; Serial

  4. 			 604800		; Refresh

  5. 			  86400		; Retry

  6. 			2419200		; Expire

  7. 			 604800 )	; Negative Cache TTL

  8. ;

  9. ; name servers - NS records

  10.      IN      NS      ns1.nyc3.example.com.

  11.      IN      NS      ns2.nyc3.example.com.

  12. 

  13. ; name servers - A records

  14. ns1.nyc3.example.com.          IN      A       10.128.10.11

  15. ns2.nyc3.example.com.          IN      A       10.128.20.12

  16. 

  17. ; 10.128.0.0/16 - A records

  18. host1.nyc3.example.com.        IN      A      10.128.100.101

  19. 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 ファイル、リバースゾーンファイルを作成します。

で定義された逆引きゾーンに対応する逆引きゾーンファイルを編集します named.conf.local:

  1. sudo vi /etc/named/zones/db.10.128

転送ゾーンファイルと同じ方法で、強調表示されたns1 FQDNを独自のFQDNに置き換えてから、2番目の「nyc3.example.com」を独自のドメインに置き換えます。 ゾーンファイルを編集するたびに、serialの値をインクリメントしてから再起動する必要があります。 named プロセス–「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.

それから加えて PTR 編集中のゾーンファイルのサブネット上にIPアドレスがあるすべてのサーバーのレコード。 この例では、すべてのホストが10.128.0.0/16サブネット上にあるため、これにはすべてのホストが含まれます。 最初の列は、サーバーのプライベートIPアドレスの最後の2つのオクテットで構成されていることに注意してください。 サーバーと一致するように、名前とプライベートIPアドレスを必ず置き換えてください。

/etc/named/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/named/zones/db.10.128 —完了
  1. $TTL    604800

  2. @       IN      SOA     nyc3.example.com. admin.nyc3.example.com. (

  3.                               3         ; Serial

  4.                          604800         ; Refresh

  5.                           86400         ; Retry

  6.                         2419200         ; Expire

  7.                          604800 )       ; Negative Cache TTL

  8. ; name servers

  9.       IN      NS      ns1.nyc3.example.com.

  10.       IN      NS      ns2.nyc3.example.com.

  11. 

  12. ; PTR Records

  13. 11.10   IN      PTR     ns1.nyc3.example.com.    ; 10.128.10.11

  14. 12.20   IN      PTR     ns2.nyc3.example.com.    ; 10.128.20.12

  15. 101.100 IN      PTR     host1.nyc3.example.com.  ; 10.128.100.101

  16. 102.200 IN      PTR     host2.nyc3.example.com.  ; 10.128.200.102

BIND構成構文を確認してください

次のコマンドを実行して、 named.conf* ファイル：

  1. sudo named-checkconf

名前付き構成ファイルに構文エラーがない場合は、シェルプロンプトに戻り、エラーメッセージは表示されません。 構成ファイルに問題がある場合は、エラーメッセージとプライマリDNSサーバーの構成セクションを確認してから、試してください。 named-checkconf また。

The named-checkzone コマンドを使用して、ゾーンファイルの正確さを確認できます。 その最初の引数はゾーン名を指定し、2番目の引数は対応するゾーンファイルを指定します。これらは両方ともで定義されています。 named.conf.local.

たとえば、「 nyc3.example.com 」転送ゾーンの構成を確認するには、次のコマンドを実行します（転送ゾーンとファイルに一致するように名前を変更します）。

  1. sudo named-checkzone nyc3.example.com /etc/named/zones/db.nyc3.example.com

また、「 128.10 .in-addr.arpa」逆引きゾーン構成を確認するには、次のコマンドを実行します（逆引きゾーンとファイルに一致するように番号を変更します）。

  1. sudo named-checkzone 128.10.in-addr.arpa /etc/named/zones/db.10.128

すべての構成ファイルとゾーンファイルにエラーがない場合は、BINDサービスを再起動する準備ができているはずです。

BINDを開始します

BINDを開始します。

  1. sudo systemctl start named

今、あなたはそれを有効にしたいでしょう、それでそれは起動時に始まります：

  1. sudo systemctl enable named

これで、プライマリDNSサーバーがセットアップされ、DNSクエリに応答する準備が整いました。 セカンダリDNSサーバーの作成に移りましょう。

セカンダリDNSサーバーを構成する

ほとんどの環境では、プライマリが使用できなくなった場合に要求に応答するセカンダリDNSサーバーを設定することをお勧めします。 幸い、セカンダリDNSサーバーの構成ははるかに簡単です。

ns2 で、 named.conf ファイル：

  1. sudo vi /etc/named.conf

注：これらの手順をスキップしたい場合は、ns1をコピーできます。 named.conf ファイルを作成し、 ns2 のプライベートIPアドレスをリッスンし、転送を許可しないように変更します。

既存の上 options ブロック、「trusted」と呼ばれる新しいACLブロックを作成します。 ここで、再帰DNSクエリを許可するクライアントのリストを定義します（つまり、 ns1）と同じデータセンターにあるサーバー。 プライベートIPアドレスの例を使用して、 ns1 、 ns2 、 host1 、およびhost2を信頼できるクライアントのリストに追加します。

/etc/named.conf —1/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/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/4
...
options {
...
        allow-query { trusted; }; # allows queries from "trusted" clients
...

ファイルの最後に、次の行を追加します。

/etc/named.conf —4/4
include "/etc/named/named.conf.local";

保存して終了します named.conf. 上記の構成では、独自のサーバー（「信頼できる」サーバー）のみがDNSサーバーにクエリを実行できるように指定されています。

次に、DNSゾーンを指定するために、ローカルファイルを構成します。

保存して終了 named.conf.

次に、 named.conf.local ファイル：

  1. sudo chmod 755 /etc/named

  2. sudo vi /etc/named/named.conf.local

プライマリDNSサーバーのマスターゾーンに対応するスレーブゾーンを定義します。 タイプは「スレーブ」であり、ファイルにはパスが含まれておらず、 masters プライマリDNSサーバーのプライベートIPに設定する必要があるディレクティブ。 プライマリDNSサーバーで複数のリバースゾーンを定義した場合は、必ずここにすべて追加してください。

/etc/named/named.conf.local
  1. zone "nyc3.example.com" {

  2.     type slave;

  3.     file "slaves/db.nyc3.example.com";

  4.     masters { 10.128.10.11; };  # ns1 private IP

  5. };

  6. 

  7. zone "128.10.in-addr.arpa" {

  8.     type slave;

  9.     file "slaves/db.10.128";

  10.     masters { 10.128.10.11; };  # ns1 private IP

  11. };

保存して終了します named.conf.local.

次のコマンドを実行して、構成ファイルの有効性を確認します。

  1. sudo named-checkconf

チェックアウトしたら、BINDを開始します。

  1. 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 ファイル：

  1. 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およびDebianLinuxVPSでは、 head に追加されるファイル resolv.conf 起動時：

  1. 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 ファイル：

  1. sudo resolvconf -u

これで、クライアントはDNSサーバーを使用するように構成されました。

クライアントをテストする

使用する nslookup—「bind-utils」パッケージに含まれています—クライアントがネームサーバーにクエリを実行できるかどうかをテストします。 これは、構成済みで「信頼できる」ACLにあるすべてのクライアントで実行できるはずです。

フォワードルックアップ

たとえば、次のコマンドを実行することにより、前方参照を実行してhost1.nyc3.example.comのIPアドレスを取得できます。

  1. 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サーバーにクエリを実行します。

  1. 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をリロードします。

  1. sudo systemctl reload named

セカンダリネームサーバー

  • 新しいホストのプライベートIPアドレスを「信頼できる」ACLに追加します（named.conf.options)

次に、BINDをリロードします。

  1. sudo systemctl reload named

DNSを使用するように新しいホストを構成する

  • DNSサーバーを使用するようにresolv.confを構成します
  • を使用してテスト nslookup

DNSからのホストの削除

環境からホストを削除する場合、またはDNSからホストを削除する場合は、サーバーをDNSに追加したときに追加されたものをすべて削除します（つまり、 上記の手順の逆）。

結論

これで、サーバーのプライベートネットワークインターフェイスをIPアドレスではなく名前で参照できるようになりました。 これにより、プライベートIPアドレスを覚えておく必要がなくなり、ファイルの読み取りと理解が容易になるため、サービスとアプリケーションの構成が容易になります。 また、さまざまな分散構成ファイルを編集する代わりに、構成を変更して、プライマリDNSサーバーである単一の場所にある新しいサーバーを指すようにすることができるため、保守が容易になります。

内部DNSを設定し、構成ファイルでプライベートFQDNを使用してネットワーク接続を指定したら、DNSサーバーを適切に維持することが重要です。 両方が利用できなくなると、それらに依存するサービスとアプリケーションは適切に機能しなくなります。 これが、少なくとも1つのセカンダリサーバーを使用してDNSを設定し、それらすべてのバックアップを維持することをお勧めする理由です。