開発者ドキュメント

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

getdocs

序章

DNS（ドメインネームシステム）は、Webサイトやサーバーの構成方法を学ぶときに、正しく理解するのが難しいコンポーネントであることがよくあります。 ほとんどの人はおそらくホスティング会社またはドメインレジストラが提供するDNSサーバーを使用することを選択しますが、独自のDNSサーバーを作成することにはいくつかの利点があります。

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

前提条件と目標

このガイドを完了するには、最初にいくつかの一般的なDNS用語に精通している必要があります。 このガイドをチェックして、このガイドで実装するいくつかの概念について学習してください。

同様の目標を達成する2つの別個の構成（キャッシュと転送DNSサーバー）を示します。

フォローするには、2台のコンピューターにアクセスできる必要があります（そのうちの少なくとも1台はUbuntu 14.04サーバーである必要があります）。 1つはクライアントとして機能し、もう1つはDNSサーバーとして構成されます。 構成例の詳細は次のとおりです。

役割 IPアドレス
DNSサーバー 192.0.2.1
クライアント 192.0.2.100

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

DNSサーバーのキャッシュ

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

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

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

DNSサーバーの転送

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

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

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

DNSサーバーにBindをインストールします

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

BindソフトウェアはUbuntuのデフォルトのリポジトリ内で利用できるため、ローカルパッケージインデックスを更新し、を使用してソフトウェアをインストールする必要があります。 apt. ドキュメントといくつかの一般的なユーティリティも含まれます。

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

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

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

最初に、キャッシングDNSサーバーとして機能するようにBindを構成する方法について説明します。 この構成では、クライアントがクエリを発行したときに、サーバーが他の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

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

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.

acl goodclients {
};

options {
    . . .

このブロック内に、このDNSサーバーの使用を許可する必要があるIPアドレスまたはネットワークをリストします。 サーバーとクライアントの両方が同じ/24サブネット内で動作しているため、例をこのネットワークに限定します。 また、追加します localhost と localnets これは自動的にこれを行おうとします：

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

options {
    . . .

要求を解決するクライアントのACLができたので、これらの機能をで構成できます。 options ブロック。 このブロック内に、次の行を追加します。

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

    recursion yes;
    allow-query { goodclients; };
    . . .

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

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

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

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

それ以外の場合は、読み続けて、代わりに転送DNSサーバーを設定する方法を学習してください。

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

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

キャッシングサーバー構成で中断した構成から始めます。 The 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; };
};

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

これを行うには、変更しない変更を行います recursion いいえ。 転送サーバーは、権限のないゾーンのクエリに応答することにより、引き続き再帰サービスを提供しています。 代わりに、リクエストを転送するキャッシュサーバーのリストを設定する必要があります。

これは、 options {} ブロック。 まず、と呼ばれる内部にブロックを作成します forwarders これには、リクエストの転送先となる再帰的なネームサーバーのIPアドレスが含まれています。 このガイドでは、GoogleのパブリックDNSサーバーを使用します（8.8.8.8 と 8.8.4.4):

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

        recursion yes;
        allow-query { goodclients; };

        forwarders {
                8.8.8.8;
                8.8.4.4;
        };
        . . .

その後、設定する必要があります forward このサーバーはすべての要求を転送し、それ自体で要求を解決しようとすべきではないため、「のみ」へのディレクティブ。

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

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

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

        recursion yes;
        allow-query { goodclients; };

        forwarders {
                8.8.8.8;
                8.8.4.4;
        };
        forward only;

        dnssec-validation auto;

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

最後に行うべき変更は、 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を明示的に有効にします。

. . .
forward only;

dnssec-enable yes;
dnssec-validation yes;

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

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

構成をテストしてバインドを再開します

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

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

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

sudo named-checkconf

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

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

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

sudo service bind9 restart

その後、クライアントマシンをセットアップする間、サーバーログを監視して、すべてがスムーズに行われることを確認します。 これをサーバー上で実行したままにします。

sudo tail -f /var/log/syslog

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

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

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

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

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

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

sudo nano /etc/resolv.conf

このファイルには、クエリを解決するために使用するDNSサーバーが一覧表示されます。 nameserver ディレクティブ。 現在のすべてのエントリをコメントアウトし、 nameserver DNSサーバーを指す行：

nameserver 192.0.2.1
# nameserver 8.8.4.4
# nameserver 8.8.8.8
# nameserver 209.244.0.3

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

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

使用できます ping ドメインへの接続が可能であることをテストするには：

ping -c 1 google.com

PING 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

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

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

dig linuxfoundation.org

; <<>> 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: 36 msec
;; SERVER: 192.0.2.1#53(192.0.2.1)
;; WHEN: Wed Jun 25 15:45:57 EDT 2014
;; MSG SIZE  rcvd: 64

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

dig linuxfoundation.org

; <<>> 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: 1 msec
;; SERVER: 192.0.2.1#53(192.0.2.1)
;; WHEN: Wed Jun 25 15:46:02 EDT 2014
;; MSG SIZE  rcvd: 64

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

見つかったIPアドレスを使用して逆引き参照をテストすることもできます（140.211.169.4 私たちの場合）dig’s -x オプション：

dig -x 140.211.169.4

; <<>> 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.1#53(192.0.2.1)
;; WHEN: Wed Jun 25 15:51:23 EDT 2014
;; MSG SIZE  rcvd: 117

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

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

. . .
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用に構成されていないことを示しています。 BindにIPv4のみを使用するように指示することで、この問題を修正できます。

これを行うには、 /etc/default/bind9 sudo権限を持つファイル：

sudo nano /etc/default/bind9

内部で、 OPTIONS 含めるパラメータ -4 IPv4のみの動作を強制するフラグ：

OPTIONS="-u bind -4"

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

サーバーを再起動します。

sudo service bind9 restart

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

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

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

クライアントマシンがDebianまたはUbuntuを実行している場合は、 /etc/network/interfaces sudo権限を持つファイル：

sudo nano /etc/network/interfaces

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

. . .
iface eth0 inet static
        address 111.111.111.111
        netmask 255.255.255.0
        gateway 111.111.0.1
        dns-nameservers 192.0.2.1
. . .

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

クライアントがCentOSまたはFedoraを実行している場合は、 /etc/sysconfig/network/network-scripts/ifcfg-eth0 代わりにファイル：

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

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

DNS1=192.0.2.1

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

結論

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

独自のドメインゾーンに対して権限のあるDNSサーバーを作成する場合は、権限のみのDNSサーバーを構成するか、これらのソリューションを組み合わせることができます。

モバイルバージョンを終了