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

DNS Networking Ubuntu

導入

サーバー構成とインフラの管理の重要な部分は、ネットワークインターフェースとIPアドレスを名前で検索する方法を維持することです。これを行う方法の1つは、適切なドメイン名システム（DNS）を設定することです。IPアドレスの代わりに完全修飾ドメイン名（FQDN）を使用してネットワークアドレスを指定すると、サービスとアプリケーションの構成を最適化し、構成ファイルの保守性を向上させることができます。プライベートネットワーク用に独自のDNSを設定することは、サーバーの管理を向上させる素晴らしい方法です。

このチュートリアルでは、2つのUbuntu 22.04サーバーを使用して内部DNSサーバーを設定します。BIND名前サーバーソフトウェア（BIND9）を使用して、プライベートホスト名とプライベートIPアドレスを解決します。これにより、内部ホスト名とプライベートIPアドレスを管理する中央的な方法が提供されます。これは、環境がいくつかのホストを超えるときに不可欠です。

前提条件

このチュートリアルを完了するには、次のインフラストラクチャが必要です。各サーバーを同じデータセンターでプライベートネットワーキングが有効になっていることを確認してください。：

A fresh Ubuntu 22.04 server to serve as the Primary DNS server, ns1.
（推奨）セカンダリDNSサーバーとして機能するための2番目のUbuntu 22.04サーバー、ns2。
少なくとも1つの追加サーバーが必要です。このガイドでは、2つの追加サーバーがあることを前提としています。これらはクライアントサーバーと呼ばれます。これらのクライアントサーバーは、DNSサーバーが配置されているデータセンターと同じ場所に作成する必要があります。

これらのサーバーのそれぞれについて、管理者のsudoユーザーを設定し、当社のUbuntu 22.04初期サーバーセットアップガイドに従ってファイアウォールを設定してください。

DNSの概念に馴染みがない場合は、少なくとも当社のDNS管理入門の最初の3部を読むことをお勧めします。

DigitalOceanでは、新しく作成されたDropletはデフォルトで仮想プライベートクラウド（VPC）に配置されます。詳細は当社のVPC製品のドキュメントを参照してください。

例示的なインフラストラクチャーと目標

この記事の目的のために、以下を前提とします：

あなたは2つのサーバーを持っており、これらをDNS名前サーバーとして指定します。このガイドではこれらをns1とns2と呼びます。
お客様の作成するDNSインフラストラクチャを使用する追加のクライアントサーバーが2台あります。このガイドでは、それぞれhost1とhost2と呼びます。必要に応じてクライアントサーバーを追加できます。
これらのサーバーはすべて同じデータセンターに存在します。このチュートリアルでは、このデータセンターをnyc3と呼ぶことになります。
これらのサーバーはすべてプライベートネットワーキングが有効になっており、10.128.0.0/16サブネットに存在しています（おそらくサーバーに合わせて調整する必要があります）。
すべてのサーバーはexample.com上で実行されているプロジェクトに接続されています。このガイドでは、内部のプライベートDNSシステムを設定する方法について説明します。したがって、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`

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

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

このチュートリアルに従うと、この設定の特定のサーバーで特定のコマンドを実行する必要がある場合があります。 ns1で実行する必要があるコマンドには、次のように青い背景が表示されます:

同様に、ns2で実行する必要があるコマンドには、次のように赤い背景が表示されます:

そして、クライアントサーバーの1つで実行する必要があるコマンドには、次のように緑色の背景が表示されます:

そして、複数のサーバーで実行する必要があるコマンドには、標準のネイビーの背景が表示されます:

最後に、コマンドやコードブロックにこのようにハイライトされたテキストが含まれている場合は、そのテキストが重要であることを意味します。このガイド全体でこのようなハイライトが使用され、自分自身の設定に置き換える必要がある詳細や、設定ファイルに変更または追加する必要があるハイライトされたテキストを示すために使用されます。たとえば、例えば host1.nyc3.example.com のようなものが含まれている場合、それを自分自身のサーバーのFQDNに置き換えます。

では、まず、ns1 と ns2 の両方のプライマリおよびセカンダリDNSサーバーにBINDをインストールすることから始めましょう。

ステップ 1 — DNSサーバーにBINDをインストールする

両方のDNSサーバー、ns1 と ns2で、次のコマンドを入力して apt パッケージキャッシュを更新します：

sudo apt update

次に、各マシンにBINDをインストールします：

sudo apt install bind9 bind9utils bind9-doc

DigitalOceanのプライベートネットワーキングはIPv4のみを使用しています。あなたの場合も同様であれば、BINDをIPv4モードに設定します。両方のサーバーで、お好みのテキストエディタを使って named のデフォルト設定ファイルを編集します。以下の例では、nano を使用しています：

sudo nano /etc/default/named

OPTIONS パラメータの末尾に -4 を追加します：

/etc/default/named

. . .
OPTIONS="-u bind -4"

編集が完了したら、ファイルを保存して閉じます。ファイルを編集するために nano を使用した場合は、CTRL + X、Y、ENTER を押して保存します。

BINDを再起動して変更を実装します：

sudo systemctl restart bind9

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

ステップ2 — プライマリDNSサーバーの構成

BINDの構成は、メインの構成ファイルnamed.confから含まれる複数のファイルで構成されています。これらのファイル名はnamedで始まります。なぜなら、それがBINDが実行するプロセスの名前であり（namedは「name daemon」の略です。つまり、「domain name daemon」の意味です）。最初にnamed.conf.optionsファイルの構成を始めましょう。

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

ns1で、named.conf.optionsファイルを編集します：

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

既存のoptionsブロックの上に、新しいACL（アクセス制御リスト）ブロックを作成し、trustedと呼びます。これは、再帰的なDNSクエリを許可するクライアントのリストを定義する場所です（つまり、ns1と同じデータセンターにあるサーバー）。以下の行を追加して、信頼できるクライアントリストにns1、ns2、host1、およびhost2を追加してください。ただし、例のプライベートIPアドレスは、自分のサーバーのものに置き換えてください：

/etc/bind/named.conf.options — 1 of 3

acl "trusted" {
        10.128.10.11;    # ns1 
        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 recursive 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;
        };

        . . .
};

forwardersブロックに注目してください。ここには2つのIPアドレスが含まれています：8.8.8.8と8.8.4.4。このブロックは、BINDが外部ネームサーバーへのリンク上のトラフィックを減らすために使用するforwardersという特別なメカニズムを定義しています。 BINDはまた、インターネットへの直接アクセス権がないサーバーによるクエリを許可するためにフォワーダーを使用できます。これにより、これらのクエリへの応答がローカルネットワークへの負荷を減少させることで、応答が速くなります：

このブロック内の2つのIPアドレスは、GoogleのパブリックDNSリゾルバーを表していますが、ここには任意のパブリック再帰名前サーバーのIPアドレスを使用できます。たとえば、CloudflareのDNSサーバーのIPアドレス（1.1.1.1）を使用することもできます。

完了したら、named.conf.options ファイルを保存して閉じます。上記の設定では、（trusted としての）自分自身のサーバーのみが外部ドメインのDNSサーバーにクエリを送信できるように指定されています。

次に、named.conf.local ファイルを構成して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 — 1 of 2

. . .

zone "nyc3.example.com" {
    type primary;
    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 の逆の8ビット順で始まることに注意してください）：

/etc/bind/named.conf.local — 2 of 2

    . . .
};

zone "128.10.in-addr.arpa" {
    type primary;
    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、DNSはhost1の対応するプライベートIPアドレスを解決するためにフォワードゾーンファイルを参照します。

ゾーンファイルが存在するディレクトリを作成します。指定された場所は/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

. . .
;
$TTL    604800
@       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (
                              3         ; Serial

                              . . .

次に、ファイルの末尾にある3つのレコード（SOAレコードの後）を削除します。削除すべき行がわからない場合は、前の例でdelete this lineと書かれたコメントでマークされています。

ファイルの最後に、次の行で名前サーバーレコードを追加します（名前は自分のものに置き換えてください）。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

最終的なフォワードゾーンファイルの例は、次の内容になります：

/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

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

次に、リバースゾーンファイルに移動しましょう。

リバースゾーンファイルの作成

リバースゾーンファイルは、逆引きDNSルックアップのためにDNS PTRレコードを定義する場所です。つまり、DNSがIPアドレスによるクエリ（例えば、10.128.100.101）を受け取った場合、このリバースゾーンファイルを参照して対応するFQDN（この場合はhost1.nyc3.example.com）を解決します。

ns1では、named.conf.localファイルで指定された各リバースゾーンに対してリバースゾーンファイルを作成します。例として、サンプルのdb.127ゾーンファイルを基にしたリバースゾーンファイルを作成します。BINDはこのファイルを使用して、ローカルループバックインターフェースの情報を保存します。ここで127は、localhost（127.0.0.1）を表すIPアドレスの最初のオクテットです。以下のコマンドを使用して、このファイルを適切な場所にコピーします（宛先のファイル名をリバースゾーンの定義に合わせて置き換えてください）。

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レコードを編集してシリアル値を増やす必要があります：

/etc/bind/zones/db.10.128 — updated 1 of 3

@       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (
                              3         ; Serial

                              . . .

次に、ファイルの末尾の2つのレコード（SOAレコードの後）を削除します。どの行を削除すればいいか分からない場合は、前の例の中でdelete this lineとコメントが付いている行です。

ファイルの末尾に、以下の行を追加して名前サーバーレコードを設定します（名前は適宜置き換えてください）。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.102

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

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

BIND構成構文の確認

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

sudo named-checkconf

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

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

例えば、nyc3.example.comのフォワードゾーン構成を確認する場合は、次のコマンドを実行します（フォワードゾーンとファイルの名前を変更してください）：

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

Outputzone nyc3.example.com/IN: loaded serial 3
OK

そして、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サーバーの設定に移りましょう。

ステップ3 — セカンダリ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 
        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ファイルを保存して閉じてください。このファイルは、ns1のnamed.conf.optionsファイルと同じである必要がありますが、ns2のプライベートIPアドレスでリスンするように構成されている必要があります。

次に、named.conf.localファイルを編集してください。

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

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

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

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

zone "128.10.in-addr.arpa" {
    type secondary;
    file "db.10.128";
    primaries { 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サーバーを使用するように設定する必要があります。

ステップ4 — DNSクライアントの設定

`trusted` ACL内のすべてのサーバーがDNSサーバーに問い合わせる前に、それぞれをns1およびns2を名前サーバーとして使用するように設定する必要があります。

クライアントサーバーがUbuntuを実行していると仮定すると、プライベートネットワークに関連付けられているデバイスを見つける必要があります。これは、プライベートサブネットを`ip address`コマンドで照会することによって行うことができます。クライアントマシンのそれぞれで、以下のコマンドを実行し、ハイライトされたサブネットを自分のものに置き換えてください：

ip address show to 10.128.0.0/16

Output
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    altname enp0s4
    altname ens4
    inet 10.128.100.101/16 brd 10.128.255.255 scope global eth1
       valid_lft forever preferred_lft forever

この例では、プライベートインターフェイスは`eth1`です。このセクション全体を通じての例では、プライベートインターフェイスとして`eth1`を参照しますが、これらの例を自分のサーバーのプライベートインターフェイスに合わせて変更する必要があります。

Ubuntu 22.04では、ネットワーキングはNetplanで設定されています。これは標準化されたネットワーク設定を書き、互換性のあるバックエンドネットワーキングソフトウェアに適用できる抽象化です。DNSを設定するには、Netplan設定ファイルを書く必要があります。

`/etc/netplan`に`00-private-nameservers.yaml`という新しいファイルを作成します：

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

中に、以下の内容を追加してください。プライベートネットワークのインターフェースを変更し、ns1とns2のDNSサーバーのアドレス、およびDNSゾーンを変更する必要があります。

注意：Netplanは、設定ファイルにYAMLデータシリアライゼーション形式を使用します。 YAMLはインデントと空白を使用してデータ構造を定義するため、定義が一貫したインデントを使用していることを確認し、エラーを回避してください。

YAML LintのようなYAMLチェッカーを使用してYAMLファイルをトラブルシューティングできます。YAML Lint。

/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 resolvectl status

プライベートネットワークインターフェースのセクションをスクロールダウンしてください。 DNSサーバーのプライベートIPアドレスが最初にリストされ、いくつかのフォールバック値が続きます。ドメインはDNS Domainの後にリストされます。

Output. . .

Link 3 (eth1)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 67.207.67.3
       DNS Servers: 10.128.10.11 10.128.20.12 67.207.67.3 67.207.67.2
        DNS Domain: nyc3.example.com

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

ステップ5 — クライアントのテスト

クライアントが名前サーバーにクエリを送信できるかどうかをテストするには、nslookupを使用します。設定済みでtrusted ACL内にあるすべてのクライアントでこれを行えるはずです。

最初に、フォワードルックアップを実行してみてください。

フォワードルックアップ

host1.nyc3.example.comのIPアドレスを取得するために、次のコマンドを実行します：

nslookup host1

host1のクエリはsearchオプションがプライベートサブドメインに設定されているため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

次に、リバースルックアップを確認できます。

リバースルックアップ

リバースルックアップをテストするには、DNSサーバーにhost1のプライベートIPアドレスでクエリを送信します：

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のゾーンファイル）のゾーンファイルを確認してください。

最終ステップとして、このチュートリアルではゾーンレコードのメンテナンス方法について説明します。

ステップ6 — DNSレコードのメンテナンス

内部DNSが機能するようになったので、サーバー環境を正確に反映するようにDNSレコードをメンテナンスする必要があります。

DNSへのホストの追加

環境にホストを追加するたびに（同じデータセンター内で）、DNSに追加する必要があります。以下は、実行する必要がある手順のリストです：

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

フォワードゾーンファイル：新しいホストのAレコードを追加し、Serialの値を増やします。
リバースゾーンファイル：新しいホストのPTRレコードを追加し、Serialの値を増やします。
新しいホストのプライベートIPアドレスをtrusted ACLに追加します（named.conf.options）

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

sudo named-checkconf
sudo named-checkzone nyc3.example.com /etc/bind/zones/db.nyc3.example.com
sudo named-checkzone 128.10.in-addr.arpa /etc/bind/zones/db.10.128

その後、BINDを再読み込みしてください：

sudo systemctl reload bind9

新しいホストのプライマリサーバーは今、設定されているはずです。

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

新しいホストのプライベートIPアドレスをtrusted ACL（named.conf.options）に追加してください。

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

sudo named-checkconf

その後、BINDを再読み込みしてください：

sudo systemctl reload bind9

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

新しいホストをDNSに使用するように構成してください。

/etc/resolv.confを使用してDNSサーバーを構成してください。
nslookupを使用してテストしてください。

DNSからホストを削除する

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

結論

今後は、サーバーのプライベートネットワークインターフェースをIPアドレスではなく名前で参照できるようになりました。これにより、サービスやアプリケーションの設定がより簡単になります。プライベートIPアドレスを覚える必要がなくなり、ファイルの読みやすさと理解が向上します。また、新しいサーバーを指すように構成を変更する場合でも、複数の分散構成ファイルを編集する必要がなく、1か所の主DNSサーバーを指定するだけで済みます。これにより、メンテナンスが最適化されます。

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

DNSについて詳しく学びたい場合は、当社の記事DNS用語、コンポーネント、および概念の紹介をご覧いただくことをお勧めします。

Source:
https://www.digitalocean.com/community/tutorials/how-to-configure-bind-as-a-private-network-dns-server-on-ubuntu-22-04