DNS設定 · 2 min read · Oct 02, 2025

BIND9を使用した二重DNSサーバー

このチュートリアルでは、BIND9 DNSサーバーを設定して、異なる情報セットを持つ内部ネットワークと外部ネットワークの両方に同時にサービスを提供する方法を示します。その目標を達成するために、BIND9の新機能であるビューを使用します。チュートリアルとして、全体のセットアップを案内しますが、BINDとDNSの初歩的な知識が必要です。その情報をカバーする文書はインターネット上にたくさんあります。

元のサイトで続きを読むか、PDFをダウンロードしてください。

目次

  • 1 問題
  • 2 初期設定
  • 3 内部と外部
  • 4 セキュリティ
  • 5 設定ファイル - 5.1 /etc/bind/named.conf.local
  • 5.2 /etc/bind/externals/db.example.com
  • 5.3 /etc/bind/internals/db.example.com
  • 参考文献

1 問題

成長している組織において典型的な問題は、同時に二つの問題を解決しなければならないことです:

  • 会社の内部ネットワーク用のDNSサーバーを持つこと。なぜなら、ずっと前からコンピュータが多すぎてIPを覚えられなくなってしまったからです 1、そしてホストファイルのセットを維持するにはコンピュータが多すぎるからです 2。
  • 外部サーバー、外部クライアントなどのためのDNSサーバーを持つこと。

この問題を解決することは、成長する組織が1つのDNSサーバー以上のリソースを提供できない場合には、さらに大きな問題になります 3。これは、すべての名前(公開とプライベート)でサーバーを構成すると、プライベートアドレスでインターネットを汚染してしまうことになり、非常に悪いことです。また、内部ネットワークのトポロジーの一部を世界に示すことにもなります。これは、攻撃者やクラッカーに持たれたくない情報です。

問題のもう一つの側面は、効率のために、内部にいるときは内部IPに解決し、外部にいるときは外部IPに解決したい場合があることです。ここでは、公開およびプライベート接続を持つコンピュータについて話しています。

この問題に対するさまざまな解決策があり、私はBIND4を使って解決したこともありますが、今回はBIND9を使用して非常にクリーンな解決策を作成します。これはDebian GNU/Linux 3.1サーバーに展開されましたが、BIND9を実行する他のオペレーティングシステムでも動作するはずですので、適切にパスを変更してください。

2 初期設定

私が働いている組織が何かの例を作成すると想像してみましょう…何の?わかりませんが、example.comで注文できます。Examples Corporationはネットワーク192.0.2.0/24が割り当てられており、内部では10.0.0.0/24を使用しています。

外部の名前とIPを提供し始めましょう。/etc/bind/named.conf.local 4を編集して、次のように追加します:

zone "example.com" {  
    type master;  
    file "/etc/bind/db.example.com";  
};

次に、/etc/bind/db.example.comを以下の内容で作成します:

; example.com  
$TTL    604800  
@       IN      SOA     ns1.example.com. root.example.com. (  
                     2006020201 ; シリアル  
                         604800 ; リフレッシュ  
                          86400 ; 再試行  
                        2419200 ; 有効期限  
                         604800); ネガティブキャッシュTTL  
;  
@       IN      NS      ns1  
        IN      MX      10 mail  
        IN      A       192.0.2.1  
ns1     IN      A       192.0.2.1  
mail    IN      A       192.0.2.128 ; メールサーバーは別の場所にあります。  
www     IN      A       192.0.2.1  
client1 IN      A       192.0.2.201 ; client1に非常に頻繁に接続します。

ご覧のとおり、私たちのスタートアップにはすべてのコンピュータをサービスする1台のコンピュータがありますが、メールは除きます。それはIP転送といくつかのデータベースも保持しています。

良いDNS設定には少なくとも1台のセカンダリサーバーが必要であり、実際にいくつかのレジストラ(ドメイン名を登録する場所)はこれを強制します。私たちには2台目のコンピュータがないので、XNameに行き、アカウントを開設し、192.0.2.1を転送元のIPとしてexample.comをセカンダリとして登録します。次に、XNameのIPに転送を行わせる必要があります。私たちは小さな組織ですが、成功するスタートアップになりたいので、できるだけ賢くすべてを行おうとします。そこで、BIND9の設定ディレクティブaclを使用して、XNameのIPアドレスにエイリアスを付ける識別子を定義します。/etc/bind/named.conf.localの最初に次のように追加します:

acl slaves {  
    195.234.42.0/24;    // XName  
    193.218.105.144/28; // XName  
    193.24.212.232/29;  // XName  
};

そして、ゾーン宣言を次のように変更します:

zone "example.com" {  
    type master;  
    file "/etc/bind/db.example.com";  
    allow-transfer { slaves; };  
};

「slaves」と記載した場所にIPを直接入力することもできます。

3 内部と外部

しっかりとした基盤ができたので、内部ネットワークと外部ネットワークに異なるコンテンツを提供することを考え始めることができますが、まず、内部と外部が何であるかを定義する必要があります。

/etc/bind/named.conf.localに次の定義を追加します(最上部またはslavesの定義の下に):

acl internals {  
    127.0.0.0/8;  
    10.0.0.0/24;  
};

内部ネットワークがさらにある場合は、そこに追加することができます。外部は定義しません。なぜなら、内部でないすべてが外部だからです。異なるインターネットの部分に異なるコンテンツを提供したい場合は、異なる外部のセットを定義することもできます。

BIND9の新機能であるビューを使用します。ビューは、条件に基づいて構成の一部を配置できるようにします。この場合、内部に依存します。/etc/bind/named.conf.localのゾーン宣言を次のように置き換えます:

view "internal" {  
    match-clients { internals; };  
    zone "example.com" {  
        type master;  
        file "/etc/bind/internals/db.example.com";  
    };  
};  
view "external" {  
    match-clients { any; };  
    zone "example.com" {  
        type master;  
        file "/etc/bind/externals/db.example.com";  
        allow-transfer { slaves; };  
    };  
};

match clientsの設定ディレクティブにより、IPのセットに基づいて条件付きでそのビューを表示できます。「any」は任意のIPを意味します。内部IPは内部ビューによってキャッシュされ、その他は外部ビューでドロップされます。外部の世界は内部ビューを見ることができず、それにはXName、私たちのセカンダリDNSプロバイダーも含まれますが、内部ビューの内容を転送できる人がいないようにallow-transferを内部ビューから削除しました。

また、パスも変更しました。/etc/bind/externalsおよび/etc/bind/internalsディレクトリを作成し、/etc/bind/db.example.comを/etc/bind/externals/に移動する必要があります。

/etc/bind/internals/db.example.comに、外部の対応物と似たゾーンファイルを内部IPを保持して配置します:

; example.com  
$TTL    604800  
@       IN      SOA     ns1.example.com. root.example.com. (  
                     2006020201 ; シリアル  
                         604800 ; リフレッシュ  
                          86400 ; 再試行  
                        2419200 ; 有効期限  
                         604800); ネガティブキャッシュTTL  
;  
@       IN      A       10.0.0.1  
boss    IN      A       10.0.0.100  
printer IN      A       10.0.0.101  
scrtry  IN      A       10.0.0.102  
sip01   IN      A       10.0.0.201  
lab     IN      A       10.0.0.103

素晴らしい、今やボスのコンピュータにpingを送ることができます:

ping boss.example.com

しかし、mail.example.comにアクセスしようとすると失望します。何が起こったのでしょうか?内部ゾーンファイルにはmail.example.comへの参照がなく、内部ネットワークにいるため、mail.example.comを解決できません。よし、外部ゾーンファイルの内容を内部ゾーンファイルにコピーしましょう。それでうまくいくでしょう。

しかし、私たちは小さくて賢いスタートアップです。ゾーンファイルに各変更をコピー&ペーストするよりも良い方法があります。さらに、それは非常にエラーが発生しやすいです(外部ゾーンファイルを変更したときに内部ゾーンファイルを変更することを常に覚えているでしょうか、それとも忘れてネットワークの問題を数日間デバッグすることになりますか?)。

私たちが行うことは、内部ファイルに外部ゾーンファイルを含めることです。このように:

$include "/etc/bind/external/db.example.com"  
@       IN      A       10.0.0.1  
boss    IN      A       10.0.0.100  
printer IN      A       10.0.0.101  
scrtry  IN      A       10.0.0.102  
sip01   IN      A       10.0.0.201  
lab     IN      A       10.0.0.103

そして、これで完了です!現在のドキュメントで$includeディレクティブを見つけるのは難しかったですが、外部ゾーンファイルを内部ゾーンファイルを変更するたびにシリアルを変更することを忘れないでください。しかし、それは大したことではありません。忘れても、何も悪いことは起こりません。なぜなら、自分の小さなネットワーク内にキャッシングサーバーが存在する可能性は低いからです。

4 セキュリティ

同じDNSサーバーをドメインのプライマリとして使用することは推奨されません(この場合、example.com)およびキャッシングDNSサーバーとして使用することは推奨されませんが、私たちのケースではそれを行わざるを得ません。外部の世界から見ると、192.0.2.1はexample.comのプライマリDNSサーバーですが、私たちの内部ネットワークからは、192.0.2.1(またはそのプライベートアドレス、10.0.0.1)は、各ワークステーションで使用するように設定されたキャッシングネームサーバーです。

問題の1つは、誰かが外部から私たちのキャッシングネームサーバーを使用し始める可能性があることです。キャッシュポイズニングと呼ばれる攻撃や、他にも多くの悪質なことが行われる可能性があり、SINSに文書化されています(それらを回避する方法も含まれています)。

セキュリティを少し向上させるために、設定ファイルにいくつかのディレクティブを追加します:

view "internal" {  
    match-clients { internals; };  
    recursion yes;  
    zone "example.com" {
        type master;
        file "/etc/bind/internals/db.example.com";
    };
};
view "external" {
    match-clients { any; };
    recursion no;

    zone "example.com" {
        type master;
        file "/etc/bind/externals/db.example.com";
        allow-transfer { slaves; };
    };
};

これにより、危険なインターネット上の誰もが私たちのサーバーを再帰的に使用することを防ぎつつ、私たち自身のネットワーク内ではそれを行うことができます。

5 設定ファイル

5.1 /etc/bind/named.conf.local

acl slaves {  
    195.234.42.0/24;    // XName  
    193.218.105.144/28; // XName  
    193.24.212.232/29;  // XName  
};  
  
acl internals {  
    127.0.0.0/8;  
    10.0.0.0/24;  
};  
  
view "internal" {  
    match-clients { internals; };  
    recursion yes;  
    zone "example.com" {  
        type master;  
        file "/etc/bind/internals/db.example.com";  
    };  
};  
view "external" {  
    match-clients { any; };  
    recursion no;  
    zone "example.com" {  
        type master;  
        file "/etc/bind/externals/db.example.com";  
        allow-transfer { slaves; };  
    };  
};

5.2 /etc/bind/externals/db.example.com

; example.com  
$TTL    604800  
@       IN      SOA     ns1.example.com. root.example.com. (  
                     2006020201 ; シリアル  
                         604800 ; リフレッシュ  
                          86400 ; 再試行  
                        2419200 ; 有効期限  
                         604800); ネガティブキャッシュTTL  
;  
@       IN      NS      ns1  
        IN      MX      10 mail  
        IN      A       192.0.2.1  
ns1     IN      A       192.0.2.1  
mail    IN      A       192.0.2.128 ; メールサーバーは別の場所にあります。  
www     IN      A       192.0.2.1  
client1 IN      A       192.0.2.201 ; client1に非常に頻繁に接続します。

5.3 /etc/bind/internals/db.example.com

$include "/etc/bind/external/db.example.com"  
@       IN      A       10.0.0.1  
boss    IN      A       10.0.0.100  
printer IN      A       10.0.0.101  
scrtry  IN      A       10.0.0.102  
sip01   IN      A       10.0.0.201  
lab     IN      A       10.0.0.103

参考文献

SINS

インターネットネームサーバーのセキュリティ

脚注

… IPs

1 私にとって、2台のコンピュータはすでにIPを覚えるには多すぎると見なされます。

… files

2 ホストファイルは/etc/hostsにあり、名前からIPへの単純なマッピングです。これは、名前をIPに解決する最初の方法であり、長い間中央の大きなホストファイルが維持され、後にFTPや類似の方法で配布されました。それは急速に問題に成長し、DNSの発明によって解決されました。ホストファイルが問題に成長する前にDNSに移行することを学びましょう。

… server

3 または、完璧主義者であり、これが1台のサーバーで実行可能であると信じている場合。

…/etc/bind/named.conf.local

4 それはあなたのオペレーティングシステムによっては単に/etc/bind/named.confである可能性があります。Debianでない場合。

Share: X/Twitter LinkedIn

新しい投稿を受信箱で受け取る

スパムはありません。いつでも購読を解除できます。