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

前書き


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

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

前提条件と目標

このガイドを完了するには、まずいくつかの一般的なDNS用語に精通する必要があります。 このガイドで実装するいくつかの概念については、this guideを確認してください。

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

これに従うには、2台のコンピューター(少なくとも1台はUbuntu 14.04サーバーである必要があります)にアクセスする必要があります。 1つはクライアントとして機能し、もう1つはDNSサーバーとして構成されます。 サンプル構成の詳細は次のとおりです。

Role IPアドレス

DNSサーバー

192.0.2.1

クライアント

192.0.2.100

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

DNSサーバーのキャッシュ

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

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

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

転送DNSサーバー

これから説明する2番目の構成は、forwardingDNSサーバーです。 転送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と呼ばれます(namedbindは同じアプリケーションの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 amplification attackと呼ばれる攻撃は、サーバーが分散型サービス拒否攻撃に参加する可能性があるため、特に厄介です。

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

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

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

acl goodclients {
};

options {
    . . .

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

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

options {
    . . .

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

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

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

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

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

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

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

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

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

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

キャッシングサーバー構成で中断した構成から始めます。 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サーバーを特定のクライアントリストに制限します。 ただし、サーバーが再帰クエリを実行しようとしないように構成を変更する必要があります。

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

これは、options {}ブロック内で実行されます。 まず、リクエストの転送先となる再帰ネームサーバーのIPアドレスを含むforwardersというブロックを内部に作成します。 このガイドでは、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; };
};

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

. . .
forward only;

dnssec-enable yes;
dnssec-validation yes;

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

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

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

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

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

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

sudo named-checkconf

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

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

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

sudo service bind9 restart

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

sudo tail -f /var/log/syslog

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

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

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

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

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

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

sudo nano /etc/resolv.conf

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

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

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

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

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

. . .
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のみを使用するように指示することで修正できます。

これを行うには、sudo権限で/etc/default/bind9ファイルを開きます。

sudo nano /etc/default/bind9

内部で、OPTIONSパラメータを変更して-4フラグを含め、IPv4のみの動作を強制します。

OPTIONS="-u bind -4"

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

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

sudo service bind9 restart

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

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

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

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

sudo nano /etc/network/interfaces

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

. . .
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サーバーを作成する場合は、authoritative-only DNS serverを構成するか、これらのソリューションを組み合わせることができます。

Related