外部向けDNSサーバです。一般的なマスターゾーン、スレーブゾーンの定義設定
自社ドメインのマスターゾーンをDNSサーバに登録する
外部向けのプライマリDNSサーバを構成してみます。
サンプル環境の概要
下の表の構成のサイトを題材とします。実践的な設定例としてわかりやすいものにするためにドメイン名、ネットワークアドレスについては当社が実際に使用しているものを使用しました(ホスト名、IPアドレスの割り当て等は架空のものです)。
ドメイン名 | network-learning.jp | |
---|---|---|
ネットワーク | 172.16.10.120/28 | |
プライマリDNSサーバ | ns1.network-learning.jp | 172.16.10.121 |
セカンダリDNSサーバ | ns2.network-learning.jp | 172.16.10.122 |
メールサーバ | mail.network-learning.jp | 172.16.10.123 |
WEBサーバ | www.network-learning.jp | 172.16.10.124 |
named.confファイルの設定 – recursionを禁止する
キャッシュDNSサーバでは、不特定多数のドメインやIPアドレスの名前解決をすることが目的であるため、recursion(再帰的参照)が必須 でした。一方、recursionは、ゾーン情報を不特定多数の外部DNSホストから受け取るため、なりすましによる「キャッシュポイズンニング」と呼ば れる攻撃の対象となりやすい機能です。DNS参照クエリーがUDPである点も、TCPサービスに比べパケットを捏造した攻撃の標的となりすい性格は否めま せん。
この危険を考慮すれば、自身が所有するゾーンの情報を不特定多数の第三者ホストに提供することが目的である、いわゆる「プライマリDNSサーバ」や 「セカンダリDNSサーバ」については、キャッシュ専用サーバを別途たてるなどして、自身が所有するゾーン情報のみを処理させるために極力 recursionを禁止すべきです。
以上を反映させたDNSサーバのnamed.confファイルの内容は以下のようになります。
named.conf
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
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”; |
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としま しょう。network-learning.jpゾーンに対する正引きと、ネットワーク124.34.146.120/28に対する逆引きゾーンを以下のように定義します。
myzones.zonedef (マスターサーバ側)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
// network-learning.jp. zone “network-learning.jp” IN { type master; file “zones_master_forward/network-learning.jp.zone”; allow-transfer { 172.16.10.122; }; notify yes; also-notify { 172.16.10.123; }; }; // 172.16.10.120/28 zone “120/28.10.16.172.in-addr.arpa” IN { type master; file “zones_master_rev/rev_172.16.10.120_28.zone”; allow-transfer { 172.16.10.122; }; notify yes; also-notify { 172.16.10.123; }; }; |
ゾーン定義の基本となるパラメータはゾーン名、「type」と「file」です。
- ゾーン名
いわゆるドメイン名(上記の例では「network-learning.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.network-learning.jpが、ホスト内部での参照のみを目的としたDNSサービスを持っていると想定し、そのDNSサービスにゾーン情報の更新を通達 するよう、also-notifyに、mail.network-learning.jpのIPアドレス123.34.146.123を設定しています
参考
mail.network-learning.jpをNSレコードで登録しないのは、NSレコードにて登録すると外部のホストからのクエリーの対象となるか らです。メールサーバにとってDNSサービスはセキュリティ上も非常に重要であり、SMTPサービスからのDNSクエリーのトラフィックをホスト内部にと どめ、また、高速化を図るためにも、ホスト内部にDNSサーバサービスを設けていますが、recursionを行うDNSサービスですので、外部からのク エリーは禁止しなければなりません。
myzones.zones (スレーブサーバ側)
1 2 3 4 5 6 7 8 9 10 11 12 |
// network-learning.jp. zone “network-learning.jp.” IN { type slave; file “zones_slave_forward/network-learning.jp.slave.zone”; masters { 172.16.10.122; }; }; // 172.16.10.120/28 zone “120/28.10.16.172.in-addr.arpa” IN { type slave; file “zones_slave_rev/rev_172.16.10.120_28.slave.zone”; masters { 172.16.10.122; } }; |
- type
「slave」を値に設定し、スレーブサーバであることを示します。 - file
ゾーン定義ファイルへのパスを設定することはマスターサーバと同じです。マスターサーバとの違いは、このファイルが、マスターサーバからのゾーン転送により自動生成される点です。このファイルをあらかじめ用意する必要はありません。 - masters
ゾーン転送する際のゾーン情報の送り元であるマスターサーバのIPアドレスを指定します。この例では、マスターサーバが一台ですが、複数列挙することも可能です。
ゾーンファイルを作成する
以下が、network-learning.jpゾーン用の定義ファイルの内容です。ゾーンファイル(myzones.zones)での宣言にしたがい、この内容で network-learning.jp.zoneというファイルを、/var/named/zones_master_forwardディレクトリ下に作成します。
network-learning.jp.zone
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
$ORIGIN network-learning.jp. $TTL 3600 ; 1 hour @ IN SOA ns1.network-learning.jp. postmaster.network-learning.jp. ( 2015090901 ; serial 3600 ; refresh (1 hour) 1200 ; retry (20 min.) 1209600 ; expire (2 weeks) 900 ; minimum (15 min.) ) @ IN NS ns1.network-learning.jp. @ IN NS ns2.network-learning.jp. @ IN MX 10 mail.network-learning.jp. @ IN TXT “v=spf1 mx ~all” ; SPF record ns1 IN A 172.16.10.121 ns2 IN A 172.16.10.122 mail IN A 172.16.10.123 server4 IN A 172.16.10.124 www IN CNAME server4 |
以下は、逆引き用ゾーンファイルの内容です。ゾーン定義ファイル(myzones.zones)での宣言にしたがい、この内容で rev_172.16.10.120_28.zoneというファイルを、/var/named/zones_master_revディレクトリ下に作成し ます。
rev_172.16.10.120_28.zone
$ORIGINのパラメータ等、いろいろな書き方が可能です。私たちの例では、あいまいさを避けるために、敢えて、「$ORIGIN .」のような省略表記を避けています。次回、これらのゾーンファイルの各項目の詳細を説明します。
1 2 3 4 5 6 7 8 9 10 11 12 13 |
$ORIGIN 120/28.10.16.172-in-addr.arpa. $TTL 3600 @ IN SOA ns1.network-learning.jp. postmaster.network-learning.jp. ( 2015090901; serial 3600 ; refresh (1 hour) 1200 ; retry (20 min.) 1209600 ; expire (2 weeks) 900 ; minimum (15 min.) ) 121 IN PTR ns1.network-learning.jp. 122 IN PTR ns2.network-learning.jp. 123 IN PTR mail.network-learning.jp. 124 IN PTR server4.network-learning.jp. |