Ubuntu 18.04でBINDをプライベートネットワークDNSサーバーとして構成する方法

前書き

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

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

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

前提条件

このチュートリアルを完了するには、次のインフラストラクチャが必要です。各サーバーin the same datacenterをprivate networking enabledで作成します。

プライマリDNSサーバーとして機能する新しいUbuntu18.04サーバーns1
（推奨）セカンダリDNSサーバーとして機能する2番目のUbuntu 18.04サーバー、ns2
DNSサーバーを使用する同じデータセンター内の追加サーバー

これらの各サーバーで、Ubuntu 18.04 initial server setup guideに従って、sudoユーザーとファイアウォールを介した管理アクセスを構成します。

DNSの概念に慣れていない場合は、少なくともIntroduction to Managing DNSの最初の3つの部分を読むことをお勧めします。

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

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

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	プライベートFQDN	プライベートIPアドレス
ns1	プライマリDNSサーバー	ns1.nyc3.example.com	10.128.10.11
ns2	セカンダリDNSサーバー	ns2.nyc3.example.com	10.128.20.12
host1	ジェネリックホスト1	host1.nyc3.example.com	10.128.100.101
host2	ジェネリックホスト2	host2.nyc3.example.com	10.128.200.102

Host

Role

プライベートFQDN

プライベートIPアドレス

ns1

プライマリDNSサーバー

ns1.nyc3.example.com

10.128.10.11

ns2

セカンダリDNSサーバー

ns2.nyc3.example.com

10.128.20.12

host1

ジェネリックホスト1

host1.nyc3.example.com

10.128.100.101

host2

ジェネリックホスト2

host2.nyc3.example.com

10.128.200.102

Note

[.note]＃既存の設定は異なりますが、名前とIPアドレスの例を使用して、機能する内部DNSを提供するようにDNSサーバーを構成する方法を示します。ホスト名とプライベートIPアドレスを独自のものに置き換えることにより、このセットアップを独自の環境に簡単に適合させることができるはずです。命名スキームでデータセンターの地域名を使用する必要はありませんが、ここでは、これらのホストが特定のデータセンターのプライベートネットワークに属していることを示すために使用します。複数のデータセンターを利用する場合は、それぞれのデータセンター内に内部DNSを設定できます。
＃

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

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

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

Note

[.note]＃redで強調表示されているテキストは重要です！多くの場合、独自の設定に置き換える必要があるもの、または構成ファイルに変更または追加する必要があるものを示すために使用されます。たとえば、host1.nyc3.example.comのようなものが表示された場合は、それを独自のサーバーのFQDNに置き換えます。同様に、host1_private_IPが表示された場合は、それを自分のサーバーのプライベートIPアドレスに置き換えます。
＃

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 -4"

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

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 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
};

options {

        . . .

信頼できる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 nano /etc/bind/named.conf.local

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

次の行でフォワードゾーンを追加し、ゾーン名を独自のゾーン名に置き換え、allow-transferディレクティブのsecondary DNS server’s private IP addressを置き換えます。

/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であると仮定して、次の行（note that our reverse zone name starts with “128.10” which is the octet reversal of “10.128”）を使用して逆引きゾーンを追加します。

/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ゾーンファイルに基づいてフォワードゾーンファイルを作成します。次のコマンドを使用して、適切な場所にコピーします。

sudo cp /etc/bind/db.local /etc/bind/zones/db.nyc3.example.com

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

sudo nano /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.102

db.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ゾーンファイルに基づいてリバースゾーンファイルを作成します。次のコマンドを使用して適切な場所にコピーします（逆ゾーン定義に一致するように宛先ファイル名を置き換えます）。

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

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

sudo nano /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つのレコードを削除します。削除する行が不明な場合は、上記の「この行を削除」コメントでマークされます。

/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オクテット（reversed order）で構成されていることに注意してください。サーバーに合わせて名前とプライベート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.102

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

BIND構成構文の確認

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

sudo named-checkconf

名前付き構成ファイルに構文エラーがない場合、シェルプロンプトに戻り、エラーメッセージは表示されません。構成ファイルに問題がある場合は、エラーメッセージと「プライマリDNSサーバーの構成」セクションを確認してから、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 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 — 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
};

options {

        . . .

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 nano /etc/bind/named.conf.local

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

/etc/bind/named.conf.local — updated (secondary)

zone "nyc3.example.com" {
    type slave;
    file "db.nyc3.example.com";
    masters { 10.128.10.11; };  # ns1 private IP
};

zone "128.10.in-addr.arpa" {
    type slave;
    file "db.10.128";
    masters { 10.128.10.11; };  # 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で構成されます。これは、標準化されたネットワーク構成を記述し、互換性のないバックエンドネットワーキングソフトウェアに適用できる抽象化です。 DNSを構成するには、Netplan構成ファイルを作成する必要があります。

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

ip address show to 10.128.0.0/16

Output3: eth1:  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ゾーンを変更する必要があります。

[.note]＃Note: Netplanは、構成ファイルにYAML data serialization formatを使用します。 YAMLはインデントと空白を使用してデータ構造を定義するため、エラーを回避するために、定義で一貫したインデントを使用するようにしてください。
＃

/etc/netplan 00-private-nameservers.yaml

network:
    version: 2
    ethernets:
        eth1:                                 # Private network interface
            nameservers:
                addresses:
                - 10.128.10.11                # Private IP for ns1
                - 10.132.20.12                # Private IP for ns2
                search: [ nyc3.example.com ]  # 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: 10.128.10.11
                      10.128.20.12
                      67.207.67.2
                      67.207.67.3
          DNS Domain: nyc3.example.com
. . .

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

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

Ubuntu16.04およびDebianLinuxサーバーでは、/etc/network/interfacesファイルを編集できます。

sudo nano /etc/network/interfaces

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

/etc/network/interfaces

    . . .

    dns-nameservers 10.128.10.11 10.128.20.12 8.8.8.8
    dns-search nyc3.example.com

    . . .

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

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

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

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

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

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

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

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

. . .
DNS1=10.128.10.11
DNS2=10.128.20.12
DOMAIN='nyc3.example.com'
. . .

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

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

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 nyc3.example.com db.nyc3.example.com
sudo named-checkzone 128.10.in-addr.arpa /etc/bind/zones/db.10.128

次に、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サーバーが適切に維持されるのはcriticalです。両方が使用できなくなった場合、それらに依存するサービスとアプリケーションは適切に機能しなくなります。これが、少なくとも1つのセカンダリサーバーでDNSをセットアップし、それらすべての作業バックアップを維持することが推奨される理由です。

TOC

Ubuntu 18.04でBINDをプライベートネットワークDNSサーバーとして構成する方法

前書き

前提条件

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

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

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

プライマリDNSサーバーの構成

オプションファイルの構成

ローカルファイルの構成

順ゾーンファイルの作成

逆ゾーンファイルの作成

BIND構成構文の確認

BINDの再起動

セカンダリDNSサーバーの構成

DNSクライアントの構成

Ubuntu 18.04クライアント

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

CentOSクライアント

クライアントのテスト

前方参照

逆引き

DNSレコードの維持

DNSへのホストの追加

プライマリネームサーバー

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

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

DNSからホストを削除する

結論

Related