前書き

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

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

このチュートリアルのCentOSバージョンは、https://www.digitalocean.com/community/tutorials/how-to-configure-bind-as-a-private-network-dns-server-on-centos-7 [ここにあります]。

前提条件

このチュートリアルを完了するには、次のインフラストラクチャが必要です。 * https://www.digitalocean.com/docs/networking/private-networking/quickstart/ [private networking enabled] *で*同じデータセンター*に各サーバーを作成します。

  • プライマリDNSサーバーとして機能する新しいUbuntu 18.04サーバー、* ns1 *

  • (推奨)セカンダリDNSサーバーとして機能する2番目のUbuntu 18.04サーバー、* ns2 *

  • DNSサーバーを使用する同じデータセンター内の追加サーバー

これらの各サーバーで、https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-18-04に従って、「+ sudo +」ユーザーとファイアウォールを介した管理アクセスを設定します[ Ubuntu 18.04サーバーの初期セットアップガイド]。

DNSの概念に精通していない場合は、https://www.digitalocean.com/community/tutorial_series/an-introduction-to-managing-dnsの最初の3つの部分を読むことをお勧めします[DNSの管理の概要]。

インフラストラクチャと目標の例

この記事では、次のことを想定しています。

  • DNSネームサーバーとして指定される2つのサーバーがあります。 このガイドでは、これらを* ns1 および ns2 *と呼びます。

  • 作成したDNSインフラストラクチャを使用する2つの追加のクライアントサーバーがあります。 このガイドでは、これらを* host1 および host2 *と呼びます。 インフラストラクチャにはいくつでも追加できます。

  • これらのサーバーはすべて同じデータセンターに存在します。 これが* nyc3 *データセンターであると想定します。

  • これらのサーバーはすべて、プライベートネットワーキングが有効になっています(「+ 10.128.0.0 / 16 +」サブネット上にあります)。 サーバーに合わせてこれを調整する必要があるでしょう。

  • すべてのサーバーは、「example.com」で実行されるプロジェクトに接続されています。 DNSシステムは完全に内部的でプライベートなものであるため、ドメイン名を購入する必要はありません。 ただし、所有するドメインを使用すると、パブリックにルーティング可能なドメインとの競合を回避できる場合があります。

これらの仮定により、プライベートサブネットまたはゾーンを参照するために「nyc3.example.com」を使用する命名スキームを使用することが理にかなっていると判断します。 したがって、* host1 のプライベート完全修飾ドメイン名(FQDN)は host1.nyc3.example.com *になります。 関連する詳細については、次の表を参照してください。

Host Role Private FQDN Private IP Address

ns1

Primary DNS Server

ns1.nyc3.example.com

10.128.10.11

ns2

Secondary DNS Server

ns2.nyc3.example.com

10.128.20.12

host1

Generic Host 1

host1.nyc3.example.com

10.128.100.101

host2

Generic Host 2

host2.nyc3.example.com

10.128.200.102

Note

このチュートリアルの終わりまでに、プライマリDNSサーバー* ns1 と、オプションでセカンダリDNSサーバー ns2 *があり、バックアップとして機能します。

プライマリDNSサーバーであるns1をインストールして始めましょう。

DNSサーバーへのBINDのインストール

Note

  • ns1 ns2 *の両方のDNSサーバーで、次を入力して `+ apt +`パッケージキャッシュを更新します。

sudo apt-get update

BINDをインストールします。

sudo apt-get install bind9 bind9utils bind9-doc

IPv4モードへのバインドの設定

続行する前に、プライベートネットワーキングはIPv4のみを使用するため、BINDをIPv4モードに設定します。 両方のサーバーで、次のように入力して、デフォルトの設定ファイル「+ bind9 +」を編集します。

sudo nano /etc/default/bind9

`+ OPTIONS +`パラメータの最後に「-4」を追加します。 次のようになります。

/ etc / default / bind9

. . .
OPTIONS="-u bind "

完了したら、ファイルを保存して閉じます。

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」という_new_ ACL(アクセス制御リスト)ブロックを作成します。 ここで、再帰DNSクエリを許可するクライアントのリストを定義します(つまり、 * ns1 と同じデータセンターにあるサーバー。 サンプルのプライベートIPアドレスを使用して、信頼できるクライアントのリストに ns1 ns2 host1 、および host2 *を追加します。

/etc/bind/named.conf.options-1/3

acl "trusted" {
       ;    # ns1 - can be set to localhost
       ;    # ns2
       ;  # host1
       ;  # host2
};

options {

       . . .

信頼できるDNSクライアントのリストができたので、 `+ options +`ブロックを編集します。 現在、ブロックの開始は次のようになっています。

/etc/bind/named.conf.options-2/3

       . . .
};

options {
       directory "/var/cache/bind";
       . . .
}

`+ directory +`ディレクティブの下に、強調表示された設定行を追加して(そして適切な* ns1 * IPアドレスに置き換えて)次のようになります:

/etc/bind/named.conf.options-3/3

       . . .

};

options {
       directory "/var/cache/bind";

                        # enables resursive queries
         # allows recursive queries from "trusted" clients
          # ns1 private IP address - listen on private network only
             # disable zone transfers by default






       . . .
};

終了したら、 `+ named.conf.options +`ファイルを保存して閉じます。 上記の構成では、自分のサーバー(「信頼できる」サーバー)のみがDNSサーバーに外部ドメインを照会できることを指定しています。

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

ローカルファイルの構成

  • ns1 *で、編集のために `+ named.conf.local +`ファイルを開きます。

sudo nano /etc/bind/named.conf.local

いくつかのコメントは別として、ファイルは空でなければなりません。 ここでは、順ゾーンと逆ゾーンを指定します。 * DNSゾーン*は、DNSレコードを管理および定義するための特定の範囲を指定します。 ドメインはすべて「nyc3.example.com」サブドメイン内にあるため、これをフォワードゾーンとして使用します。 サーバーのプライベートIPアドレスはそれぞれ「+ 10.128.0.0 / 16 +」IPスペースにあるため、その範囲内で逆ルックアップを定義できるように逆ゾーンを設定します。

`+ allow-transfer +`ディレクティブで、ゾーン名を自分の*セカンダリDNSサーバーのプライベートIPアドレス*で置き換えて、フォワードゾーンを追加します。

/etc/bind/named.conf.local-2の1

zone "" {
   type master;
   file "/etc/bind/zones/db."; # zone file path
   allow-transfer { ; };           # ns2 private IP address - secondary
};

プライベートサブネットが `+ 10.128.0.0 / 16 +`であると仮定して、次の行で逆ゾーンを追加します(*逆ゾーン名は「10.128」のオクテット反転である「128.10」で始まることに注意してください):

/etc/bind/named.conf.local-2/2

   . . .
};

zone ".in-addr.arpa" {
   type master;
   file "/etc/bind/zones/db.";  # 10.128.0.0/16 subnet
   allow-transfer { ; };  # 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 +」ゾーンファイルに基づいて、フォワードゾーンファイルを作成します。 次のコマンドを使用して、適切な場所にコピーします。

sudo cp /etc/bind/db.local /etc/bind/zones/db.

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

sudo nano /etc/bind/zones/db.

最初は、次のようになります。

/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」に増やします。 それは今このように見えるはずです:

/etc/bind/zones/db.nyc3.example.com-1/3を更新

@       IN      SOA     . .. (
                                      ; Serial

                             . . .

次に、ファイルの最後(SOAレコードの後)にある3つのレコードを削除します。 削除する行が不明な場合は、上記の「この行を削除」コメントでマークされます。

ファイルの最後に、次の行を使用してネームサーバーレコードを追加します(名前を独自のものに置き換えます)。 2番目の列は、これらが「NS」レコードであることを示していることに注意してください。

/etc/bind/zones/db.nyc3.example.com-3の2を更新

. . .

; name servers - NS records
   IN      NS      ns1..
   IN      NS      ns2..

次に、このゾーンに属するホストのAレコードを追加します。 これには、名前が「.nyc3.example.com」で終わるサーバーが含まれます(名前とプライベートIPアドレスを置き換えます)。 サンプル名とプライベートIPアドレスを使用して、* ns1 ns2 host1 、および host2 *のAレコードを次のように追加します。

/etc/bind/zones/db.nyc3.example.com-3/3を更新

. . .

; name servers - A records
ns1..          IN      A
ns2..          IN      A

; 10.128.0.0/16 - A records
.        IN      A
.        IN      A

`+ db.nyc3.example.com +`ファイルを保存して閉じます。

最終的なフォワードゾーンファイルの例は次のようになります。

/etc/bind/zones/db.nyc3.example.com-更新

$TTL    604800
@       IN      SOA     . admin.. (
                      ; Serial
            604800     ; Refresh
             86400     ; Retry
           2419200     ; Expire
            604800 )   ; Negative Cache TTL
;
; name servers - NS records
    IN      NS      ns1..
    IN      NS      ns2..

; name servers - A records
ns1..          IN      A
ns2..          IN      A

; 10.128.0.0/16 - A records
.        IN      A
.        IN      A

次に、逆ゾーンファイルに移動します。

逆ゾーンファイルの作成

逆ゾーンファイルは、逆DNSルックアップ用のDNS PTRレコードを定義する場所です。 つまり、DNSがIPアドレス(たとえば「10.128.100.101」)でクエリを受信すると、逆ゾーンファイルを検索して、対応するFQDN(この場合は「host1.nyc3.example.com」)を解決します。 。

  • ns1 *で、 `+ named.conf.local `ファイルで指定された逆ゾーンごとに、逆ゾーンファイルを作成します。 サンプルの「 db.127 +」ゾーンファイルに基づいて逆ゾーンファイルを作成します。 次のコマンドを使用して適切な場所にコピーします(逆ゾーン定義に一致するように宛先ファイル名を置き換えます)。

sudo cp /etc/bind/db.127 /etc/bind/zones/db.

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

sudo nano /etc/bind/zones/db.

最初は、次のようになります。

/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 *値をインクリメントします。 これは次のようになります。

/etc/bind/zones/db.10.128-1/3を更新

@       IN      SOA     . .. (
                                      ; Serial

                             . . .

ファイルの最後(SOAレコードの後)にある2つのレコードを削除します。 削除する行が不明な場合は、上記の「この行を削除」コメントでマークされます。

ファイルの最後に、次の行を使用してネームサーバーレコードを追加します(名前を独自のものに置き換えます)。 2番目の列は、これらが「NS」レコードであることを示していることに注意してください。

/etc/bind/zones/db.10.128-3の2を更新

. . .

; name servers - NS records
     IN      NS      ns1..
     IN      NS      ns2..

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

/etc/bind/zones/db.10.128-3/3を更新

. . .

; PTR Records
  IN      PTR     ns1..    ; 10.128.10.11
  IN      PTR     ns2..    ; 10.128.20.12
IN      PTR     .  ; 10.128.100.101
IN      PTR     .  ; 10.128.200.102

逆ゾーンファイルを保存して閉じます(逆ゾーンファイルをさらに追加する必要がある場合は、このセクションを繰り返します)。

最後の逆ゾーンファイルの例は次のようになります。

/etc/bind/zones/db.10.128-更新

$TTL    604800
@       IN      SOA     . admin.nyc3.example.com. (
                                      ; Serial
                        604800         ; Refresh
                         86400         ; Retry
                       2419200         ; Expire
                        604800 )       ; Negative Cache TTL
; name servers
     IN      NS      ns1..
     IN      NS      ns2..

; PTR Records
  IN      PTR     ns1..    ; 10.128.10.11
  IN      PTR     ns2..    ; 10.128.20.12
IN      PTR     .  ; 10.128.100.101
IN      PTR     .  ; 10.128.200.102

ファイルの編集が完了したので、次にファイルのエラーをチェックできます。

BIND構成構文の確認

次のコマンドを実行して、 `+ named.conf * +`ファイルの構文を確認します。

sudo named-checkconf

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

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

たとえば、「」順ゾーンの構成を確認するには、次のコマンドを実行します(順ゾーンとファイルに合わせて名前を変更します)。

sudo named-checkzone  db.

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

sudo named-checkzone .in-addr.arpa /etc/bind/zones/db.

すべての構成ファイルとゾーンファイルにエラーがない場合、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を追加します。

/etc/bind/named.conf.options-1/2の更新(セカンダリ)

acl "trusted" {
       ;   # ns1
       ;   # ns2 - can be set to localhost
       ;  # host1
       ;  # host2
};

options {

       . . .

`+ directory +`ディレクティブの下に、次の行を追加します。

/etc/bind/named.conf.options-2/2の更新(セカンダリ)

       recursion yes;
       allow-recursion { trusted; };
       listen-on { ; };      # ns2 private IP address
       allow-transfer { none; };          # disable zone transfers by default

       forwarders {
               8.8.8.8;
               8.8.4.4;
       };

`+ named.conf.options `ファイルを保存して閉じます。 このファイルは* ns1 *の ` named.conf.options +`ファイルとまったく同じように見えるはずです。ただし、* ns2 *のプライベートIPアドレスでリッスンするように構成する必要があります。

次に、 `+ named.conf.local +`ファイルを編集します。

sudo nano /etc/bind/named.conf.local

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

/etc/bind/named.conf.local-更新(セカンダリ)

zone "" {
   type slave;
   file "db.";
   masters { ; };  # ns1 private IP
};

zone ".in-addr.arpa" {
   type slave;
   file "db.";
   masters { ; };  # ns1 private IP
};

ここで、 `+ named.conf.local +`ファイルを保存して閉じます。

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

sudo named-checkconf

チェックアウトしたら、BINDを再起動します。

sudo systemctl restart bind9

UFWファイアウォールルールを変更して、サーバーへのDNS接続を許可します。

sudo ufw allow Bind9

これで、プライベートネットワーク名とIPアドレスを解決するためのプライマリおよびセカンダリDNSサーバーができました。 ここで、プライベートDNSサーバーを使用するようにクライアントサーバーを構成する必要があります。

DNSクライアントの構成

「信頼された」ACL内のすべてのサーバーがDNSサーバーを照会する前に、ネームサーバーとして* ns1 および ns2 *を使用するように各サーバーを構成する必要があります。 このプロセスはOSによって異なりますが、ほとんどのLinuxディストリビューションでは、ネームサーバーを `+ / etc / resolv.conf +`ファイルに追加する必要があります。

Ubuntu 18.04クライアント

Ubuntu 18.04では、ネットワークはNetplanで構成されます。Netplanは、標準化されたネットワーク構成を記述し、互換性のないバックエンドネットワーキングソフトウェアに適用できる抽象化です。 DNSを構成するには、Netplan構成ファイルを作成する必要があります。

最初に、 `+ ip address +`コマンドでプライベートサブネットにクエリを実行して、プライベートネットワークに関連付けられたデバイスを見つけます。

ip address show to
Output3: : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
   inet 10.128.100.101/16 brd 10.128.255.255 scope global eth1
          valid_lft forever preferred_lft forever

この例では、プライベートインターフェイスは「+ eth1 +」です。

次に、 `+ 00-private-nameservers.yaml `という名前の新しいファイルを ` / etc / netplan +`に作成します。

sudo nano /etc/netplan/00-private-nameservers.yaml

内部に、次の内容を貼り付けます。 プライベートネットワークのインターフェイス、* ns1 および ns2 * DNSサーバーのアドレス、およびDNSゾーンを変更する必要があります。

/ etc / netplan 00-private-nameservers.yaml

network:
   version: 2
   ethernets:
       :                                 # Private network interface
           nameservers:
               addresses:
               -                 # Private IP for ns1
               -                 # Private IP for ns2
               search: [  ]  # DNS zone

完了したら、ファイルを保存して閉じます。

次に、 `+ netplan try +`を使用して、新しい構成ファイルの使用を試みるようNetplanに指示します。 ネットワークの損失を引き起こす問題がある場合、Netplanはタイムアウト後に自動的に変更をロールバックします。

sudo netplan try
OutputWarning: Stopping systemd-networkd.service, but it can still be activated by:
 systemd-networkd.socket
Do you want to keep these settings?


Press ENTER before the timeout to accept the new configuration


Changes will revert in 120 seconds

カウントダウンが下部で正しく更新されている場合、新しい構成は少なくともSSH接続を切断しない程度に機能しています。 * ENTER *を押して、新しい構成を受け入れます。

次に、システムのDNSリゾルバーをチェックして、DNS構成が適用されているかどうかを確認します。

sudo systemd-resolve --status

プライベートネットワークインターフェイスのセクションが表示されるまで下にスクロールします。 DNSサーバーのプライベートIPアドレスが最初に表示され、その後にいくつかのフォールバック値が表示されます。 ドメインは「DNSドメイン」にある必要があります。

Output. . .
Link 3 (eth1)
     Current Scopes: DNS
      LLMNR setting: yes
MulticastDNS setting: no
     DNSSEC setting: no
   DNSSEC supported: no
        DNS Servers:

                     67.207.67.2
                     67.207.67.3
         DNS Domain:
. . .

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

Ubuntu 16.04およびDebianクライアント

Ubuntu 16.04およびDebian Linuxサーバーでは、 `+ / etc / network / interfaces +`ファイルを編集できます。

sudo nano /etc/network/interfaces

内部で、 `+ dns-nameservers `行を見つけ、現在存在するリストの前に独自のネームサーバーを追加します。 その行の下に、インフラストラクチャのベースドメインを指す ` dns-search +`オプションを追加します。 この場合、これは「nyc3.example.com」になります。

/ etc / network / interfaces

   . . .

   dns-nameservers   8.8.8.8


   . . .

完了したら、ファイルを保存して閉じます。

次に、ネットワークサービスを再起動し、次のコマンドを使用して新しい変更を適用します。 `+ eth0 +`をネットワークインターフェイスの名前に置き換えてください:

sudo ifdown --force  && sudo ip addr flush dev  && sudo ifup --force

これにより、現在の接続を切断せずにネットワークが再起動します。 正常に動作した場合、次のように表示されます。

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では、 `+ / etc / sysconfig / network-scripts / ifcfg- `ファイルを編集します。 ` eth0 +`をプライマリネットワークインターフェイスの名前に置き換える必要がある場合があります。

sudo nano /etc/sysconfig/network-scripts/ifcfg-

「+ DNS1 」および「 DNS2 」オプションを検索し、プライマリおよびセカンダリネームサーバーのプライベートIPアドレスに設定します。 インフラストラクチャのベースドメインに「 DOMAIN +」パラメーターを追加します。 このガイドでは、「nyc3.example.com」になります。

/ etc / sysconfig / network-scripts / ifcfg-eth0

. . .
DNS1=
DNS2=

. . .

完了したら、ファイルを保存して閉じます。

次のように入力して、ネットワークサービスを再起動します。

sudo systemctl restart network

コマンドは数秒間ハングする場合がありますが、すぐにプロンプ​​トに戻ります。

次のように入力して、変更が適用されたことを確認します。

cat /etc/resolv.conf

リストにネームサーバーと検索ドメインが表示されます。

/etc/resolv.conf

nameserver 10.128.10.11
nameserver 10.128.20.12
search nyc3.example.com

これで、クライアントはDNSサーバーに接続して使用できるようになります。

クライアントのテスト

クライアントがネームサーバーにクエリできるかどうかをテストするには、 `+ nslookup +`を使用します。 これは、設定済みで「信頼できる」ACLにあるすべてのクライアントで実行できるはずです。

CentOSクライアントの場合、次のオプションを使用してユーティリティをインストールする必要があります。

sudo yum install bind-utils

前方参照を実行することから始めます。

前方参照

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

nslookup host1

「+ search +」オプションがプライベートサブドメインに設定されているため、「host1」をクエリすると「host1.nyc3.example.com」に展開され、DNSクエリは他の場所でホストを検索する前にそのサブドメインを検索しようとします。 上記のコマンドの出力は次のようになります。

OutputServer:     127.0.0.53
Address:    127.0.0.53#53

Non-authoritative answer:
Name:   host1.nyc3.example.com
Address: 10.128.100.101

次に、逆引きをチェックできます。

逆引き

逆引きをテストするには、* host1 *のプライベートIPアドレスでDNSサーバーを照会します。

nslookup 10.128.100.101

次のような出力が表示されます。

Output11.10.128.10.in-addr.arpa   name = host1.nyc3.example.com.

Authoritative answers can be found from:

すべての名前とIPアドレスが正しい値に解決される場合、ゾーンファイルが適切に構成されていることを意味します。 予期しない値を受け取った場合は、必ずプライマリDNSサーバーのゾーンファイルを確認してください(例: + db.nyc3.example.com +`および `+ db.10.128 +)。

おめでとうございます。 これで、内部DNSサーバーが適切にセットアップされました! 次に、ゾーンレコードの管理について説明します。

DNSレコードの維持

動作する内部DNSができたので、サーバー環境を正確に反映するようにDNSレコードを維持する必要があります。

DNSへのホストの追加

(同じデータセンター内の)環境にホストを追加するたびに、DNSに追加する必要があります。 実行する必要がある手順のリストは次のとおりです。

プライマリネームサーバー
  • 順ゾーンファイル:新しいホストの「A」レコードを追加し、「シリアル」の値を増やします

  • リバースゾーンファイル:新しいホストの「PTR」レコードを追加し、「シリアル」の値を増やします

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

構成ファイルをテストします。

sudo named-checkconf
sudo named-checkzone  db.
sudo named-checkzone .in-addr.arpa /etc/bind/zones/db.

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

sudo systemctl reload bind9

ここで、プライマリサーバーを新しいホスト用に構成する必要があります。

セカンダリネームサーバー
  • 新しいホストのプライベートIPアドレスを「信頼できる」ACL( + named.conf.options)に追加します

構成構文を確認します。

sudo named-checkconf

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

sudo systemctl reload bind9

これで、セカンダリサーバーは新しいホストからの接続を受け入れます。

DNSを使用するように新しいホストを構成する
  • DNSサーバーを使用するように「+ / etc / resolv.conf +」を設定します

  • `+ nslookup +`を使用してテストする

DNSからホストを削除する

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

結論

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

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