Ubuntu18.04でBINDをプライベートネットワークDNSサーバーとして構成する方法
序章
サーバー構成とインフラストラクチャの管理の重要な部分には、適切なドメインネームシステム(DNS)を設定することにより、ネットワークインターフェイスとIPアドレスを名前で簡単に検索する方法を維持することが含まれます。 IPアドレスの代わりに完全修飾ドメイン名(FQDN)を使用してネットワークアドレスを指定すると、サービスとアプリケーションの構成が容易になり、構成ファイルの保守性が向上します。 プライベートネットワーク用に独自のDNSを設定することは、サーバーの管理を改善するための優れた方法です。
このチュートリアルでは、Ubuntu 18.04でBINDネームサーバーソフトウェア(BIND9)を使用して、サーバーがプライベートホスト名とプライベートIPアドレスを解決するために使用できる内部DNSサーバーをセットアップする方法について説明します。 これは、内部ホスト名とプライベートIPアドレスを管理するための中心的な方法を提供します。これは、環境が少数のホストを超える場合に不可欠です。
前提条件
このチュートリアルを完了するには、次のインフラストラクチャが必要です。 プライベートネットワークを有効にして、同じデータセンターに各サーバーを作成します。
- プライマリDNSサーバーとして機能する新しいUbuntu18.04サーバーns1
- (推奨)セカンダリDNSサーバーとして機能する2番目のUbuntu18.04サーバーns2
- DNSサーバーを使用する同じデータセンター内の追加サーバー
これらの各サーバーで、を介して管理アクセスを構成します。 sudo
Ubuntu18.04初期サーバーセットアップガイドに従ってユーザーとファイアウォール。
DNSの概念に慣れていない場合は、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
. 次の表に関連する詳細を参照してください。
亭主 | 役割 | プライベート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 |
注:既存の設定は異なりますが、名前とIPアドレスの例を使用して、機能する内部DNSを提供するようにDNSサーバーを構成する方法を示します。 ホスト名とプライベートIPアドレスを独自の環境に置き換えることで、この設定を独自の環境に簡単に適合させることができるはずです。 命名スキームでデータセンターのリージョン名を使用する必要はありませんが、ここでは、これらのホストが特定のデータセンターのプライベートネットワークに属していることを示すために使用します。 複数のデータセンターを利用する場合は、それぞれのデータセンター内に内部DNSを設定できます。
このチュートリアルの終わりまでに、プライマリDNSサーバー ns1 と、オプションでバックアップとして機能するセカンダリDNSサーバーns2ができます。
まず、プライマリDNSサーバーとセカンダリDNSサーバーの両方であるns1とns2のBINDをインストールしてみましょう。
DNSサーバーへのBINDのインストール
注:こののようにで強調表示されているテキストは重要です! 多くの場合、独自の設定に置き換える必要があること、または構成ファイルに変更または追加する必要があることを示すために使用されます。 たとえば、次のようなものが表示された場合 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
お好みのテキストエディタを使用したデフォルト設定ファイル。 次の例では、 nano
:
- sudo nano /etc/default/bind9
追加 -4
の終わりまで OPTIONS
パラメータ。 次のようになります。
. . .
OPTIONS="-u bind -4"
終了したら、ファイルを保存して閉じます。 使用した場合 nano
ファイルを編集するには、を押して編集できます CTRL + X
, Y
、 それから ENTER
.
BINDを再起動して、変更を実装します。
- sudo systemctl restart bind9
BINDがインストールされたので、プライマリDNSサーバーを構成しましょう。
プライマリDNSサーバーの構成
BINDの構成は、メイン構成ファイルから含まれている複数のファイルで構成されています。 named.conf
. これらのファイル名はで始まります named
これは、BINDが実行するプロセスの名前であるためです( named
「ドメイン名デーモン」のように、「 named aemon」の略です)。 構成から始めます named.conf.options
ファイル。
オプションファイルの構成
ns1 で、 named.conf.options
編集用ファイル:
- sudo nano /etc/bind/named.conf.options
既存の上 options
ブロック、と呼ばれる新しいACL(アクセス制御リスト)ブロックを作成します trusted
. ここで、再帰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
};
options {
. . .
信頼できるDNSクライアントのリストができたので、 options
ブロック。 現在、ブロックの開始は次のようになります。
. . .
};
options {
directory "/var/cache/bind";
. . .
}
下 directory
ディレクティブで、強調表示された構成行を追加します(そして、適切な ns1 プライベートIPアドレスに置き換えます)。次のようになります。
. . .
};
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
ファイル。 上記の構成では、独自のサーバー( trusted
1つ)外部ドメインについてDNSサーバーにクエリを実行できるようになります。
次に、DNSゾーンを設定してDNSゾーンを指定します named.conf.local
ファイル。
ローカルファイルの構成
ns1 で、 named.conf.local
編集用ファイル:
- sudo nano /etc/bind/named.conf.local
いくつかのコメントを除いて、ファイルは空である必要があります。 ここでは、順方向ゾーンと逆方向ゾーンを指定します。 DNSゾーンは、DNSレコードを管理および定義するための特定のスコープを指定します。 サンプルドメインはすべて、 nyc3.example.com
サブドメインでは、それをフォワードゾーンとして使用します。 私たちのサーバーのプライベートIPアドレスはそれぞれ 10.128.0.0/16
IPスペースでは、その範囲内で逆引き参照を定義できるように、逆引きゾーンを設定します。
次の行で転送ゾーンを追加します。ゾーン名を独自のゾーン名に置き換え、セカンダリDNSサーバーのプライベートIPアドレスを allow-transfer
指令:
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
、次の行で逆引きゾーンを追加します(逆引きゾーン名は10.128 のオクテット反転である128.10で始まることに注意してください):
. . .
};
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
最初は、次のようになります。
$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
. ゾーンファイルを編集するたびに、をインクリメントする必要があります Serial
再起動する前の値 named
処理する。 インクリメントします 3
. これで、次のようになります。
@ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. (
3 ; Serial
. . .
次に、ファイルの最後(SOAレコードの後)にある3つのレコードを削除します。 削除する行がわからない場合は、コメントでマークされます。 delete this line
その上。
ファイルの最後に、ネームサーバーレコードを次の行で追加します(名前を独自のレコードに置き換えます)。 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を解決します。 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
最初は、次のようになります。
$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値をインクリメントします。 次のようになります。
@ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. (
3 ; Serial
. . .
次に、ファイルの最後(SOAレコードの後)にある2つのレコードを削除します。 削除する行がわからない場合は、 delete this line
上記のコメント。
ファイルの最後に、ネームサーバーレコードを次の行で追加します(名前を独自のレコードに置き換えます)。 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
名前付き構成ファイルに構文エラーがない場合は、シェルプロンプトに戻り、エラーメッセージは表示されません。 構成ファイルに問題がある場合は、エラーメッセージと Configure Primary DNS Server
セクション、次に試してください named-checkconf
また。
The named-checkzone
コマンドを使用して、ゾーンファイルの正確さを確認できます。 その最初の引数はゾーン名を指定し、2番目の引数は対応するゾーンファイルを指定します。これらは両方ともで定義されています。 named.conf.local
.
たとえば、 nyc3.example.com
転送ゾーンの構成では、次のコマンドを実行します(転送ゾーンとファイルに一致するように名前を変更します)。
- sudo named-checkzone nyc3.example.com /etc/bind/zones/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を追加します。
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
ディレクティブには、次の行を追加します。
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サーバーのマスターゾーンに対応するスレーブゾーンを定義します。 タイプは slave
、ファイルにパスが含まれておらず、 masters
プライマリDNSサーバーのプライベートIPアドレスに設定する必要があるディレクティブ。 プライマリDNSサーバーで複数のリバースゾーンを定義した場合は、必ずここにすべて追加してください。
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クライアントの構成
内のすべてのサーバーの前に trusted
ACLはDNSサーバーにクエリを実行できます。ネームサーバーとしてns1およびns2を使用するように各サーバーを構成する必要があります。 このプロセスはOSによって異なりますが、ほとんどのLinuxディストリビューションでは、ネームサーバーをに追加する必要があります。 /etc/resolv.conf
ファイル。
Ubuntu18.04クライアント
Ubuntu 18.04では、ネットワークはNetplanで構成されます。これは、標準化されたネットワーク構成を記述して、互換性のないバックエンドネットワークソフトウェアに適用できるようにする抽象化です。 DNSを構成するには、Netplan構成ファイルを作成する必要があります。
まず、プライベートサブネットにクエリを実行して、プライベートネットワークに関連付けられているデバイスを見つけます。 ip address
指図:
- ip address show to 10.128.0.0/16
Output3: eth1: <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
.
次に、で新しいファイルを作成します /etc/netplan
と呼ばれる 00-private-nameservers.yaml
:
- sudo nano /etc/netplan/00-private-nameservers.yaml
中に、以下の内容を貼り付けます。 プライベートネットワークのインターフェイス、ns1およびns2 DNSサーバーのアドレス、およびDNSゾーンを変更する必要があります。
注: Netplanは、構成ファイルにYAMLデータシリアル化形式を使用します。 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に指示します。 netplan try
. ネットワークの損失を引き起こす問題がある場合、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 Domain
:
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サーバーを使用するようにクライアントを構成する必要があります。
Ubuntu16.04およびDebianクライアント
Ubuntu16.04およびDebianLinuxサーバーでは、 /etc/network/interfaces
ファイル:
- sudo nano /etc/network/interfaces
内部で、 dns-nameservers
行を入力し、現在そこにあるリストの前に独自のネームサーバーを追加します。 その行の下に、 dns-search
オプションは、インフラストラクチャのベースドメインを指します。 私たちの場合、これは nyc3.example.com
:
. . .
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
:
. . .
DNS1=10.128.10.11
DNS2=10.128.20.12
DOMAIN='nyc3.example.com'
. . .
終了したら、ファイルを保存して閉じます。
次に、次のように入力してネットワークサービスを再起動します。
- sudo systemctl restart network
コマンドは数秒間ハングする場合がありますが、すぐにプロンプトに戻るはずです。
次のように入力して、変更が適用されたことを確認します。
- cat /etc/resolv.conf
リストにネームサーバーと検索ドメインが表示されます。
nameserver 10.128.10.11
nameserver 10.128.20.12
search nyc3.example.com
これで、クライアントはDNSサーバーに接続して使用できるようになります。
クライアントのテスト
使用する nslookup
クライアントがネームサーバーにクエリを実行できるかどうかをテストします。 構成し、にあるすべてのクライアントでこれを実行できるはずです。 trusted
ACL。
CentOSクライアントの場合、次の機能を使用してユーティリティをインストールする必要があります。
- sudo yum install bind-utils
前方参照を実行することから始めることができます。
フォワードルックアップ
のIPアドレスを取得するために前方参照を実行するには host1.nyc3.example.com
、次のコマンドを実行します。
- nslookup host1
クエリ host1
に拡大 host1.nyc3.example.com
なぜなら search
オプションがプライベートサブドメインに設定されている場合、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にホストを追加する必要があります。 実行する必要のある手順のリストは次のとおりです。
プライマリネームサーバー
- 転送ゾーンファイル:を追加します
A
新しいホストのレコード、値をインクリメントしますSerial
- リバースゾーンファイル:追加
PTR
新しいホストのレコード、値をインクリメントしますSerial
- 新しいホストのプライベートIPアドレスをに追加します
trusted
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アドレスをに追加します
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サーバーを適切に維持することが重要です。 両方が利用できなくなると、それらに依存するサービスとアプリケーションは適切に機能しなくなります。 これが、少なくとも1つのセカンダリサーバーを使用してDNSを設定し、それらすべてのバックアップを維持することをお勧めする理由です。