強いBIND DNSサーバを構築する 第四回 マスターサーバのゾーン設定


前回にひきつづきBIND9の設定を解説します。前回までは、キャッシュDNSサーバについての設定でしたが、今回は外部向けDNSサーバです。一般的なマスターゾーン、スレーブゾーンの定義設定と、各ファイルの効果的な整理方法を解説します。

自社ドメインのマスターゾーンをDNSサーバに登録する

前回までは、キャッシュDNSサーバの設定について解説しました。今回は、外部向けのプライマリDNSサーバを構成してみます。

サンプル環境の概要

下の表の構成のサイトを題材とします。実践的な設定例としてわかりやすいものにするためにドメイン名、ネットワークアドレスについては当社が実際に使用しているものを使用しました(ホスト名、IPアドレスの割り当て等は架空のものです)。

ドメイン名 eis.co.jp  
ネットワーク 124.34.146.120/28  
プライマリDNSサーバ ns1.eis.co.jp 124.34.146.121
セカンダリDNSサーバ ns2.eis.co.jp 124.34.146.122
メールサーバ mail.eis.co.jp 124.34.146.123
WEBサーバ www.eis.co.jp 124.34.146.124

named.confファイルの設定 – recursionを禁止する

前回のキャッシュDNSサーバでは、不特定多数のドメインやIPアドレスの名前解決をすることが目的であるため、recursion(再帰的参照)が必須でした。一方、recursionは、ゾーン情報を不特定多数の外部DNSホストから受け取るため、なりすましによる「キャッシュポイズンニング」と呼ばれる攻撃の対象となりやすい機能です。DNS参照クエリーがUDPである点も、TCPサービスに比べパケットを捏造した攻撃の標的となりすい性格は否めません。

この危険を考慮すれば、自身が所有するゾーンの情報を不特定多数の第三者ホストに提供することが目的である、いわゆる「プライマリDNSサーバ」や「セカンダリDNSサーバ」については、キャッシュ専用サーバを別途たてるなどして、自身が所有するゾーン情報のみを処理させるために極力recursionを禁止すべきです。

以上を反映させたDNSサーバのnamed.confファイルの内容は以下のようになります。

named.conf

options {
    version “unknown”
    hostname “somehost.some.domain”;
    directory “/var/named/”;
    dump-file “/var/named/data/cache_dump.db”;
    statistics-file “/var/named/data/named_stats.txt”;
    pid-file “/var/run/named/named.pid”;
//
    listen-on port 53 {
        127.0.0.1;
        192.168.0.2;
    };
    auth-nxdomain yes;;
    // Zone transfer specifications
    notify no;
    max-transfer-time-in 60;
    transfer-format many-answers;
    transfers-in 10;
    transfers-per-ns 2;
    //
    allow-transfer { none; };
    allow-query-cache { none; };
    allow-query { any; };
    //
    recursion no;
};
include “/etc/myzones.zones”;

 

前回までのnamed.confから削除

第三回で追加した、以下のルートゾーンの定義、特殊なゾーンの定義も、recursionを行わない場合不要ですので削除します。

zone “.” IN {
    type hint;
    file “named.root”;
    allow-update { none; };
};
include “/etc/named.special.zones”;

代わって加わった「include “/etc/myzones.zones”;」については、次の項で説明します。

notify, allow-transfer等、ゾーン転送にかかわる設定項目は、各ゾーンの宣言に記載がない場合、このoptions部の設定がデフォルト値として使用されます。すべてのゾーンについて同じセカンダリサーバが使用される場合は、options部でまとめて設定し、ゾーン宣言での記載を省略できるという利便性もありますが、多数のゾーンを抱えるASPサービスのサイトなどの場合、そうはいきません。ゾーン転送はセキュリティにもかかわることですので、私たちは、原則として、横着をせず各ゾーン宣言で明示的に指定するようにしています(allow-queryの設定については、よほどのことがない限りanyですので、options部で設定、ゾーン宣言では省略しています)。

注意:
このように構成されたnameサーバサービスは、自分がゾーン情報を持っているゾーン以外のゾーンに対するクエリー要求には答えません。汎用的なDNS名前解決には使用できませんので、resolv.confに加えてはなりません。マスターサーバをこのように構成する場合、キャッシュDNSサーバを別に用意することが前提です。

参考:
VIEW機能を使用して、ゾーン情報やオプション設定を、外部向け、内部向け別々に設定し一台のホストに同居されることが可能ですが、追って、別な回に解説します。

ゾーン宣言ファイルを作って、named.confにincludeする

定義するゾーンが正逆それぞれひとつだけというような場合は、named.confにゾーン宣言を直接書いてしまっても不都合はないのですが、二桁に近づくと、named.confが非常に読みにくくなり、誤りのもととなります。

named.confの前半は、BINDの基本的な動作やセキュリティに拘わる設定項目が多数ありますので、named.confへの編集がなべく発生しないように、include文を利用してゾーン定義を他のファイルに分離したいものです(Apacheのように、include文でワイルドカード(例:  zones/*.zone )が利用できると良いのですが、残念ながら、BINDはワイルドカードの使用を許していません)。

named.confにincludeするファイルのファイル名は任意の文字列で結構です。私たちの例ではmyzones.zonedefとしましょう。eis.co.jpゾーンに対する正引きと、ネットワーク124.34.146.120/28に対する逆引きゾーンを以下のように定義します。

myzones.zonedef (マスターサーバ側)

// EIS.CO.JP.
zone “eis.co.jp” IN {
    type master;
    file “zones_master_forward/eis.co.jp.zone”;
    allow-transfer { 124.34.146.122; };
    notify yes;
    also-notify { 124.34.146.123; };
};
// 124.34.146.120/28
zone “120/28.146.34.124.in-addr.arpa” IN {
    type master;
    file “zones_master_rev/rev_124.34.146.120_28.zone”;
    allow-transfer { 124.34.146.122; };
    notify yes;
    also-notify { 124.34.146.123; };
};

ゾーン定義の基本となるパラメータはゾーン名、「type」と「file」です。

  • ゾーン名
    いわゆるドメイン名(上記の例では「eis.co.jp)をIPアドレスに変換する「正引き」ゾーンのゾーン名は、そのドメイン名を指定します(ここでの記述に限り、ルートゾーンをあらわす最後の「.」は必要ありません)。逆にIPアドレスをドメイン名に変換する「逆引きゾーン」の場合、インターネットに拘わるすべてのIPアドレスのルートはARPA NETの「in-addr.arpa.」であり、これを起点にIPアドレスを逆に並べた表記となります。上記の例では、クラスC未満のネットワークであるため、プロバイダが独自に定めたサブネットのエリアスである、”120/28.46.34.124.in-addr.arpa”がゾーン名として使用されています。
  • type
    マスターゾーンであれば「master」、他のサーバのゾーン情報をバックアップするスレーブサーバであれば「slave」とします。
  • file
    ゾーンファイルのファイルパスです。named.confの「directory」で指定したディレクトリをルートとする相対パス、または、絶対パスで記述します。
    上記の例では、正引き、逆引き用にディレクトリを分け、整理していますが、ゾーンの数、それぞれのドメインの用途の違い等を元に、それぞれ異なるディレクトリに収容すると、整理、メンテナンスの役に立ちます。
  • allow-transfer
    ゾーン転送要求を許可するスレーブサーバのIPアドレス指定します。私たちの例では、スレーブサーバは一台ですが、複数ある場合は、それらを列挙します。
  • notify
    このサーバでゾーン情報に変更が加えられた際に、他のネームサーバ(スレーブサーバ)にそれを通達し、ゾーン情報の更新を促す機能です。値にyesが設定された場合、(1)NSレコードで登録されている他のネームサーバ(SOAのパラメータによりプライマリサーバとされているサーバは除く)と、(2)次の「also-notify」で指定されたスレーブサーバに通達が送信されます。
  • also-notify
    前項のnotifyにyesが設定されている場合に有効の、ゾーン情報の更新通知の対象とするネームサーバのIPアドレスを指定します。allow-transfer同様、複数ある場合は列挙することができます。NSレコードにより当該ゾーンのネームサーバとして登録されているサーバは、ここに記載しなくても通知されます。「このゾーンのネームサーバ(NSレコードで指定されたサーバ)に加えて、これらのサーバにも(”ALSO”)通達する」という意味での「also」なのです。
    上記の例ではホストmail.eis.co.jpが、ホスト内部での参照のみを目的としたDNSサービスを持っていると想定し、そのDNSサービスにゾーン情報の更新を通達するよう、also-notifyに、mail.eis.co.jpのIPアドレス123.34.146.123を設定しています

参考
mail.eis.co.jpをNSレコードで登録しないのは、NSレコードにて登録すると外部のホストからのクエリーの対象となるからです。メールサーバにとってDNSサービスはセキュリティ上も非常に重要であり、SMTPサービスからのDNSクエリーのトラフィックをホスト内部にとどめ、また、高速化を図るためにも、ホスト内部にDNSサーバサービスを設けていますが、recursionを行うDNSサービスですので、外部からのクエリーは禁止しなければなりません。

myzones.zones (スレーブサーバ側)

// EIS.CO.JP.
zone “eis.co.jp” IN {
    type slave;
    file “zones_slave_forward/eis.co.jp.slave.zone”;
    masters { 124.34.146.121; };
};
// 124.34.146.120/28 USEN
zone “120/28.146.34.124.in-addr.arpa” IN {
    type slave;
    file “zones_slave_rev/rev_124.34.146.120_28.slave.zone”;
    masters { 124.34.146.121; }
};
  • type
    「slave」を値に設定し、スレーブサーバであることを示します。
  • file
    ゾーン定義ファイルへのパスを設定することはマスターサーバと同じです。マスターサーバとの違いは、このファイルが、マスターサーバからのゾーン転送により自動生成される点です。このファイルをあらかじめ用意する必要はありません。
  • masters
    ゾーン転送する際のゾーン情報の送り元であるマスターサーバのIPアドレスを指定します。この例では、マスターサーバが一台ですが、複数列挙することも可能です。

ゾーンファイルを作成する

以下が、eis.co.jpゾーン用の定義ファイルの内容です。ゾーンファイル(myzones.zones)での宣言にしたがい、この内容でeis.co.jp.zoneというファイルを、/var/named/zones_master_forwardディレクトリ下に作成します。

eis.co.jp.zone

$ORIGIN eis.co.jp.
$TTL 3600 ; 1 hour
@ IN SOA ns1.eis.co.jp. postmaster.eis.co.jp. (
    2009082401 ; serial
    3600 ; refresh (1 hour)
    1200 ; retry (20 min.)
    1209600 ; expire (2 weeks)
    900 ; minimum (15 min.)
)
@ IN NS ns1.eis.co.jp.
@ IN NS ns2.eis.co.jp.
@ IN MX 10 mail.eis.co.jp.
@ IN TXT “v=spf1 mx ~all” ; SPF record
ns1 IN A 124.34.146.121
ns2 IN A 124.34.146.122
mail IN A 124.34.146.123
server4 IN A 124.34.146.124
www IN CNAME server4

以下は、逆引き用ゾーンファイルの内容です。ゾーン定義ファイル(myzones.zones)での宣言にしたがい、この内容でrev_124.34.46.120_28.zoneというファイルを、/var/named/zones_master_revディレクトリ下に作成します。

rev_124.34.146.120_28.zone

$ORIGINのパラメータ等、いろいろな書き方が可能です。私たちの例では、あいまいさを避けるために、敢えて、「$ORIGIN .」のような省略表記を避けています。次回、これらのゾーンファイルの各項目の詳細を説明します。

$ORIGIN 120/28.146.34.124-in-addr.arpa.
$TTL 3600
@ IN SOA ns1.eis.co.jp. postmaster.eis.co.jp. (
    2009082401; serial
    3600 ; refresh (1 hour)
    1200 ; retry (20 min.)
    1209600 ; expire (2 weeks)
    900 ; minimum (15 min.)
)
121 IN PTR ns1.eis.co.jp.
122 IN PTR ns2.eis.co.jp.
123 IN PTR mail.eis.co.jp.
124 IN PTR server4.eis.co.jp.
2010年6月27日 | カテゴリー : DNS, BIND | 投稿者 : eurotec