Ubuntu 16.04でキャッシュまたは転送DNSサーバーとしてバインドを構成する方法

前書き

DNS、またはドメインネームシステムは、多くの場合、Webサイトとサーバーの構成方法を学習するときに適切なコンポーネントを取得するのが困難です。 ほとんどの人はおそらくホスティング会社またはドメインレジストラが提供するDNSサーバーを使用することを選択しますが、独自のDNSサーバーを作成することにはいくつかの利点があります。

このガイドでは、Bind9 DNSサーバーをUbuntu 16.04マシンでキャッシュまたは転送DNSサーバーとしてインストールおよび構成する方法について説明します。 これら2つの構成には、マシンのネットワークを提供する場合に両方の利点があります。

前提条件と目標

このガイドを完了するには、まずいくつかの一般的なDNS用語に精通する必要があります。 このガイドで実装するいくつかの概念については、https://www.digitalocean.com/community/tutorials/an-introduction-to-dns-terminology-components-and-concepts [このガイド]をご覧ください。

同様の目標を達成する2つの個別の構成、キャッシングと転送DNSサーバーのデモを行います。

これに従うには、2台のコンピューター(少なくとも1台はUbuntu 16.04サーバーでなければなりません)にアクセスする必要があります。 1つはクライアントとして機能し、もう1つはDNSサーバーとして構成されます。 サーバーを適切な予備状態にするには、https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-16-04 [Ubuntu 16.04サーバーの初期セットアップガイド]に従ってください。

サンプル構成の詳細は次のとおりです。

Role IP Address

DNS Server

192.0.2.2

Client

192.0.2.100

クエリにDNSサーバーを使用するようにクライアントマシンを構成する方法を示します。 ニーズに応じて、2つの異なる構成でDNSサーバーを構成する方法を示します。

DNSサーバーのキャッシュ

最初の構成は、キャッシュ DNSサーバー用です。 このタイプのサーバーは、再帰クエリを処理し、一般に他のサーバーからのDNSデータを追跡する面倒な作業を処理できるため、リゾルバーとも呼ばれます。

キャッシュDNSサーバーは、クライアントのクエリに対する回答を追跡すると、その回答をクライアントに返します。 ただし、レコードのTTL値で許可されている期間、回答をキャッシュに保存します。 その後、キャッシュを後続のリクエストのソースとして使用して、総ラウンドトリップ時間を短縮できます。

ネットワーク構成に含まれる可能性のあるほぼすべてのDNSサーバーは、DNSサーバーをキャッシュします。 これらは、ほとんどのクライアントマシンに実装された適切なDNSリゾルバーライブラリの不足を補います。 キャッシングDNSサーバーは、多くの状況に適しています。 ISPのDNSまたは他の公的に利用可能なDNSサーバーに依存したくない場合は、独自のキャッシュサーバーを作成することをお勧めします。 クライアントマシンに物理的に近接している場合、DNSクエリ時間も改善される可能性が非常に高くなります。

転送DNSサーバー

デモする2番目の構成は、* forwarding * DNSサーバーです。 転送DNSサーバーは、クライアントの観点からはキャッシュサーバーとほとんど同じように見えますが、メカニズムと作業負荷はまったく異なります。

転送DNSサーバーには、キャッシュを維持してクライアントのDNS解決時間を改善するという同じ利点があります。 ただし、実際には再帰クエリ自体は実行されません。 代わりに、すべての要求を外部の解決サーバーに転送し、その後のクエリに使用する結果をキャッシュします。

これにより、転送サーバーはキャッシュから応答できますが、再帰クエリのすべての作業を実行する必要はありません。 これにより、サーバーは再帰ルーチン全体を実行する代わりに、単一の要求(転送されたクライアント要求)のみを作成できます。 これは、外部帯域幅の転送にコストがかかる環境、キャッシュサーバーを頻繁に変更する必要がある環境、またはローカルクエリを1つのサーバーに転送し、外部クエリを別のサーバーに転送する環境で有利です。

DNSサーバーにバインドをインストールする

使用する構成の選択に関係なく、バインドDNSサーバーを実装する最初の手順は、実際のソフトウェアをインストールすることです。

BindソフトウェアはUbuntuのデフォルトリポジトリ内で使用できるため、ローカルパッケージインデックスを更新し、 `+ apt +`を使用してソフトウェアをインストールするだけです。 ドキュメントと一般的なユーティリティも含まれます。

sudo apt-get update
sudo apt-get install bind9 bind9utils bind9-doc

バインドコンポーネントがインストールされたので、サーバーの構成を開始できます。 転送サーバーはジャンプサーバーとしてキャッシュサーバー構成を使用するため、最終目標に関係なく、最初にサーバーをキャッシュサーバーとして構成します。

キャッシュDNSサーバーとして構成する

最初に、キャッシュDNSサーバーとして機能するようにバインドを構成する方法について説明します。 この構成では、クライアントがクエリを発行したときに、サーバーが他のDNSサーバーからの回答を再帰的に検索するように強制します。 これは、応答全体が見つかるまで、関連する各DNSサーバーを順番に照会する作業を行っていることを意味します。

バインド設定ファイルはデフォルトで `+ / etc / bind +`のディレクトリに保存されます。 今すぐそのディレクトリに移動します。

cd /etc/bind

このディレクトリ内の大部分のファイルには関心がありません。 メインの設定ファイルは `+ named.conf `と呼ばれます( ` named `と ` bind `は同じアプリケーションの2つの名前です)。 このファイルは、単に ` named.conf.options `ファイル、 ` named.conf.local `ファイル、および ` named.conf.default-zones +`ファイルをソースします。

キャッシュDNSサーバーの場合、 `+ named.conf.options +`ファイルのみを変更します。 これをsudo特権でテキストエディターで開きます。

sudo nano named.conf.options

読みやすくするためにコメントを削除すると、ファイルは次のようになります。

/etc/bind/named.conf.options

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

       dnssec-validation auto;

       auth-nxdomain no;    # conform to RFC1035
       listen-on-v6 { any; };
};

キャッシングを構成するための最初のステップは、アクセス制御リスト(ACL)をセットアップすることです。

再帰クエリを解決するために使用されるDNSサーバーとして、悪意のあるユーザーによってDNSサーバーが悪用されることは望ましくありません。 * DNS増幅攻撃*と呼ばれる攻撃は、サーバーが分散型サービス拒否攻撃に参加する可能性があるため、特に厄介です。

DNS増幅攻撃は、悪意のあるユーザーがインターネット上のサーバーまたはサイトを停止しようとする1つの方法です。 そのために、再帰クエリを解決するパブリックDNSサーバーを見つけようとします。 被害者のIPアドレスをスプーフィングし、DNSサーバーに大きな応答を返すクエリを送信します。 その際、DNSサーバーは、被害者のサーバーに向けられた大きなペイロードで小さなリクエストに応答し、攻撃者の利用可能な帯域幅を効果的に増幅します。

パブリックで再帰的なDNSサーバーをホストするには、大量の特別な構成と管理が必要です。 サーバーが悪意のある目的で使用される可能性を回避するために、信頼するIPアドレスまたはネットワーク範囲のリストを構成します。

`+ options `ブロックの上に、 ` acl +`という新しいブロックを作成します。 設定しているACLグループのラベルを作成します。 このガイドでは、グループを* goodclients *と呼びます。

/etc/bind/named.conf.options

options {
   . . .

このブロック内で、このDNSサーバーの使用を許可する必要があるIPアドレスまたはネットワークをリストします。 この例では、サーバーとクライアントの両方が同じ/ 24サブネット内で動作しているため、このネットワークに限定します。 これを調整して、独自のクライアントを含め、外部の関係者を含めないでください。 また、これを自動的に実行しようとする `+ localhost `と ` localnets +`を追加します。

/etc/bind/named.conf.options

acl goodclients {



};

options {
   . . .

リクエストを解決したいクライアントのACLができたので、 `+ options +`ブロックでそれらの機能を設定できます。 このブロック内に、次の行を追加します。

/etc/bind/named.conf.options

. . .

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



   . . .

明示的に再帰をオンにし、ACL仕様を使用するように `+ allow-query `パラメーターを設定しました。 ACLグループを参照するために、「 allow-recursion 」などの別のパラメーターを使用することもできます。 存在し、再帰がオンの場合、 ` allow-recursion +`は再帰サービスを使用できるクライアントのリストを指示します。

ただし、 `+ allow-recursion `が設定されていない場合、バインドは ` allow-query-cache `リスト、次に ` allow-query `リスト、最後にデフォルトの ` localnets `および ` + localhost + `のみ。 キャッシング専用サーバーを設定しているため(独自の権限ゾーンはなく、リクエストを転送しません)、 ` allow-query +`リストは常に再帰にのみ適用されます。 ACLを指定する最も一般的な方法であるため、これを使用しています。

これらの変更が完了したら、ファイルを保存して閉じます。

DNSサーバーのキャッシングに必要なのは実際にはこれだけです。 これが使用するサーバーの種類であると判断した場合は、構成ファイルの確認、サービスの再起動、およびクライアント構成の実装方法を学ぶために、お気軽にスキップしてください。

それ以外の場合は、読み進めて代わりに転送DNSサーバーをセットアップする方法を学習してください。

転送DNSサーバーとして構成する

転送DNSサーバーがインフラストラクチャに適している場合は、代わりに簡単に設定できます。

キャッシングサーバー構成で中断した構成から始めます。 `+ named.conf.options +`ファイルは次のようになります。

/etc/bind/named.conf.options

acl goodclients {
       192.0.2.0/24;
       localhost;
       localnets;
};

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

       recursion yes;
       allow-query { goodclients; };

       dnssec-validation auto;

       auth-nxdomain no;    # conform to RFC1035
       listen-on-v6 { any; };
};

DNSサーバーを特定のクライアントリストに制限するために、同じACLリストを使用します。 ただし、サーバーが再帰クエリを実行しようとしないように構成を変更する必要があります。

これを行うために、 `+ recursion +`をnoに変更しないでください。 転送サーバーは、権限のないゾーンのクエリに応答することにより、依然として再帰サービスを提供しています。 代わりに、リクエストを転送するキャッシュサーバーのリストを設定する必要があります。

これは、 + options {} +`ブロック内で行われます。 最初に、リクエストを転送したい再帰ネームサーバーのIPアドレスを含む「+ forwarders +」と呼ばれるブロックを作成します。 このガイドでは、GoogleのパブリックDNSサーバー( `+ 8.8.8.8 +`および `+ 8.8.4.4 +)を使用します。

/etc/bind/named.conf.options

. . .

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

       recursion yes;
       allow-query { goodclients; };





       . . .

その後、このサーバーはすべてのリクエストを転送し、それ自体でリクエストを解決しようとするべきではないため、 `+ forward +`ディレクティブを“ only”に設定する必要があります。

終了すると、構成ファイルは次のようになります。

/etc/bind/named.conf.options

. . .

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

       recursion yes;
       allow-query { goodclients; };

       forwarders {
               8.8.8.8;
               8.8.4.4;
       };


       dnssec-validation auto;

       auth-nxdomain no;    # conform to RFC1035
       listen-on-v6 { any; };
};

最後に行う必要がある変更の1つは、「+ dnssec +」パラメーターの変更です。 現在の構成では、転送されたDNSサーバーの構成によっては、ログに次のようなエラーが表示される場合があります。

Jun 25 15:03:29 cache named[2512]: error (chase DS servers) resolving 'in-addr.arpa/DS/IN': 8.8.8.8#53
Jun 25 15:03:29 cache named[2512]: error (no valid DS) resolving '111.111.111.111.in-addr.arpa/PTR/IN': 8.8.4.4#53

これを回避するには、「+ dnssec-validation +」設定を「yes」に変更し、dnssecを明示的に有効にします。

/etc/bind/named.conf.options

. . .

forward only;


dnssec-validation ;

auth-nxdomain no;    # conform to RFC1035
. . .

完了したら、ファイルを保存して閉じます。 これで、転送DNSサーバーが配置されました。 次のセクションに進み、構成ファイルを検証してデーモンを再起動します。

設定をテストし、バインドを再起動します

バインドサーバーがキャッシュDNSサーバーまたは転送DNSサーバーとして構成されたので、変更を実装する準備が整いました。

思い切ってシステムのBindサーバーを再起動する前に、Bindに含まれているツールを使用して構成ファイルの構文を確認する必要があります。

次のように入力することで、これを簡単に行うことができます。

sudo named-checkconf

構成に構文エラーがない場合、シェルプロンプトは出力を表示せずにすぐに戻ります。

構成ファイルに構文エラーがある場合は、エラーとエラーが発生した行番号について警告されます。 この場合は、戻ってファイルのエラーを確認してください。

構成ファイルに構文エラーがないことを確認したら、バインドデーモンを再起動して変更を実装します。

sudo systemctl restart bind9

サーバーの初期セットアップガイドに従った場合、サーバーでUFWファイアウォールが有効になっています。 クライアントのリクエストに応答するには、サーバーへのDNSトラフィックを許可する必要があります。

次を入力して、バインドのファイアウォールポリシーの例外を有効にします。

sudo ufw allow Bind9

その後、クライアントマシンをセットアップする間、サーバーログに注意して、すべてがスムーズに進むようにします。 サーバーでこれを実行したままにします。

sudo journalctl -u bind9 -f

次に、新しいターミナルウィンドウを開いて、クライアントマシンを構成します。

クライアントマシンを構成する

サーバーが稼働しているので、クエリにこのDNSサーバーを使用するようにクライアントマシンを構成できます。

クライアントマシンにログインします。 使用しているクライアントが、DNSサーバーに設定したACLグループで指定されていることを確認してください。 そうしないと、DNSサーバーはクライアントへの要求の処理を拒否します。

`+ / etc / resolv.conf`ファイルを編集して、サーバーがネームサーバーを指すようにする必要があります。 ここで行った変更は、再起動するまで持続します。これはテストに最適です。 テストの結果に満足したら、これらの変更を永続的にすることができます。

テキストエディターでsudo権限でファイルを開きます。

sudo nano /etc/resolv.conf

このファイルは、 `+ nameserver `ディレクティブを設定することでクエリを解決するために使用するDNSサーバーをリストします。 現在のすべてのエントリをコメントアウトし、DNSサーバーを指す ` nameserver +`行を追加します。

/etc/resolv.conf

nameserver
# nameserver 8.8.4.4
# nameserver 8.8.8.8
# nameserver 209.244.0.3

ファイルを保存して閉じます。

これで、いくつかの一般的なツールを使用して、クエリが正しく解決できるかどうかをテストできます。

`+ ping +`を使用して、ドメインに接続できることをテストできます。

ping -c 1 google.com
OutputPING google.com (173.194.33.1) 56(84) bytes of data.
64 bytes from sea09s01-in-f1.1e100.net (173.194.33.1): icmp_seq=1 ttl=55 time=63.8 ms

--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 63.807/63.807/63.807/0.000 ms

これは、クライアントがDNSサーバーを使用して `+ google.com`に接続できることを意味します。

`+ dig +`のようなDNS固有のツールを使用して、より詳細な情報を取得できます。 今回は別のドメインを試してください:

dig linuxfoundation.org
Output; <<>> DiG 9.9.5-3-Ubuntu <<>> linuxfoundation.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35417
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;linuxfoundation.org.       IN  A

;; ANSWER SECTION:
linuxfoundation.org.    6017    IN  A   140.211.169.4

;; Query time:
;; SERVER: 192.0.2.2#53(192.0.2.2)
;; WHEN: Wed Jun 25 15:45:57 EDT 2014
;; MSG SIZE  rcvd: 64

クエリに36ミリ秒かかったことがわかります。 再度リクエストを行うと、サーバーはキャッシュからデータをプルし、応答時間を短縮する必要があります。

dig linuxfoundation.org
Output; <<>> DiG 9.9.5-3-Ubuntu <<>> linuxfoundation.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18275
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;linuxfoundation.org.       IN  A

;; ANSWER SECTION:
linuxfoundation.org.    6012    IN  A   140.211.169.4

;; Query time:
;; SERVER: 192.0.2.2#53(192.0.2.2)
;; WHEN: Wed Jun 25 15:46:02 EDT 2014
;; MSG SIZE  rcvd: 64

ご覧のとおり、キャッシュされた応答は非常に高速です。

digの「+ -x 」オプションを使用して、見つかったIPアドレス(この例では「+140.211.169.4」)を使用して、逆ルックアップをテストすることもできます。

dig -x 140.211.169.4
Output; <<>> DiG 9.9.5-3-Ubuntu <<>> -x 140.211.169.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61516
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;4.169.211.140.in-addr.arpa.    IN  PTR

;; ANSWER SECTION:
4.169.211.140.in-addr.arpa. 3402 IN CNAME   4.0-63.169.211.140.in-addr.arpa.
4.0-63.169.211.140.in-addr.arpa. 998 IN PTR load1a.linux-foundation.org.

;; Query time: 31 msec
;; SERVER: 192.0.2.2#53(192.0.2.2)
;; WHEN: Wed Jun 25 15:51:23 EDT 2014
;; MSG SIZE  rcvd: 117

ご覧のとおり、逆引きも成功します。

DNSサーバーに戻って、テスト中にエラーが記録されているかどうかを確認する必要があります。 表示される可能性のある一般的なエラーの1つは次のとおりです。

Output from sudo journalctl -u bind9 -f. . .
Jun 25 13:16:22 cache named[2004]: error (network unreachable) resolving 'ns4.apnic.net/A/IN': 2001:dc0:4001:1:0:1836:0:140#53
Jun 25 13:16:22 cache named[2004]: error (network unreachable) resolving 'ns4.apnic.com/A/IN': 2001:503:a83e::2:30#53
Jun 25 13:16:23 cache named[2004]: error (network unreachable) resolving 'sns-pb.isc.org/AAAA/IN': 2001:500:f::1#53
Jun 25 13:16:23 cache named[2004]: error (network unreachable) resolving 'ns3.nic.fr/A/IN': 2a00:d78:0:102:193:176:144:22#53

これらは、サーバーがIPv6情報を解決しようとしているが、サーバーがIPv6用に構成されていないことを示します。 この問題は、バインドにIPv4のみを使用するように指示することで修正できます。

これを行うには、Bind9を開始するsystemdユニットファイルを変更します。

sudo systemctl edit --full bind9

表示されるファイル内で、「+ ExecStart 」行の最後に「 -4 +」を追加して、サーバーをIPv4リクエストに制限します。

bind9 systemdユニットファイルの編集

[Unit]
Description=BIND Domain Name Server
Documentation=man:named(8)
After=network.target

[Service]
ExecStart=/usr/sbin/named -f -u bind
ExecReload=/usr/sbin/rndc reload
ExecStop=/usr/sbin/rndc stop

[Install]
WantedBy=multi-user.target

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

systemdデーモンをリロードして、変更されたユニットファイルをinitシステムに読み込みます。

sudo systemctl daemon-reload

Bind9サービスを再起動して、変更を実装します。

sudo systemctl restart bind9

これらのエラーがログに再び表示されることはありません。

クライアントDNS設定を永続的にする

前に述べたように、クライアントマシンをDNSサーバーにポイントする「+ / etc / resolv.conf +」設定は、再起動後も存続しません。 最後に変更を行うには、このファイルの生成に使用されるファイルを変更する必要があります。

クライアントマシンがDebianまたはUbuntuを実行している場合、sudo権限で `+ / etc / network / interfaces +`ファイルを開きます:

sudo nano /etc/network/interfaces

`+ dns-nameservers +`パラメーターを探します。 既存のエントリを削除してDNSサーバーに置き換えるか、DNSサーバーをオプションの1つとして追加することができます。

/ etc / network / interfaces

. . .

iface eth0 inet static
       address 192.168.2.100
       netmask 255.255.255.0
       gateway 192.168.2.1
       dns-nameservers

. . .

完了したら、ファイルを保存して閉じます。 次回の起動時に、設定が適用されます。

クライアントがCentOSまたはFedoraを実行している場合、代わりに `+ / etc / sysconfig / network / network-scripts / ifcfg-eth0 +`ファイルを開く必要があります。

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

内部で、「+ DNS 」で始まる行を探します。 DNSサーバーに「 DNS1 +」を変更します。 他のDNSサーバーをフォールバックとして使用したくない場合は、他のエントリを削除します。

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

. . .
DNS1=
. . .

完了したら、ファイルを保存して閉じます。 クライアントは、次回の起動時にこれらの設定を使用する必要があります。

結論

これで、クライアントにサービスを提供するようにDNSサーバーまたはキャッシュDNSサーバーを構成する必要があります。 これは、管理しているマシンのDNSクエリを高速化する素晴らしい方法です。

Related