DNSサーバには、「キャッシュサーバ」として「コンテンツサーバ(権威サーバ)」としての使い方があります。

1台のDNSサーバで、
イントラ向けには再起問合わせを受けつつ、社内ドメインのゾーンを提供する。
外部向けには再起問合わせを拒否しつつ、社外ドメインのゾーンを提供する。

といったケースも出てきます。

この場合は、VIEWを使うことで実現が可能となります。

======================================
options {
(略)
}
view naibu {                 ①
  match-clients { 192.168.1.0/24; };    ②
  recursion yes;              ③
incluede "/etc/named.rfc1912.zones";

zone "office" IN {            ④
type master;
file "office.zone"
allow-update { none; };
};
};


view gaibu {                ⑤
match-clients { any; };          ⑥ recursion no;               ⑦

zone "dns-test.com" IN {         ⑧
type master;
file "dns-test.zone"
allow-update { none; };
};
};

======================================

①VIEWを定義。ビュー名(naibu、gaibu)は任意のものでかまいません。
②match-clientで指定したクライアントに対してのみ、そのVIEWステートメント内に記述した動作をします。
③内部向けのVIEWなので再起問合わせを許可
④イントラゾーンを定義

⑤VIEWを定義。ここでは外部向けのVIEWを定義。
⑥その他ネットワークを定義
⑦再起問合わせを拒否。(オープンリゾルバ問題)
⑧外部向けゾーン「dns-test.com」を定義


この設定では、192.168.1.0/24からの問合わせに対しては、再起問合わせを許可し、社内ゾーン「office」の情報を提供する。それ以外のクライアントからの問合わせに対しては、再起問合わせを拒否し、外部ゾーンdns-test.comの情報を提供します。





★VIEWステートメント利用時の注意点


①VIEWステートメントは頭から順に評価される。
例えば、外部ゾーン向けビューのmatch-clientsでは「any」を指定しているため、これを頭に記述してしまうと、全て外部ゾーン向けのビューにマッチしてしまいます。

②VIEWステートメント利用時のZONEステートメントの書き方
VIEWステートメントの中では、ZONEステートメントやRecursion文のほか、optionsステートメント内に記述できる文の多くが記述できます。OptionsステートメントとVIEWステートメントで指定が重複した場合、VIEWステートメントが優先されます。ただし、「VIEWステートメントを利用する際には、ZONEステートメントは必ずVIEW内に入れる必要がある」という点に注意が必要です。
VIEWを利用していて、かつZONEステートメントをVIEWの外に記述すると、構文エラーになります。



★match-licent以外の絞込み

「match-destination」
  match-destination { 192.168.x.0/24; };
送信元では無く、宛先にマッチさせるというものです。


「match-recursive-only」
  match-recursive-only yes;
yesを指定するとクエリが再起問合わせである場合にのみ、そのビューが適用されます。



★VIEWステートメントの問題点
ゾーン転送を行なう際には「allow-transfer」を記述します。

上記の例ですと、
VIEWステートメント内の内部ゾーン「office」と外部ゾーン「test-dns.com」の両方にallow-transferを記述することになります。

内部ゾーン「office」と外部ゾーン「test-dns.com」を持つスレーブサーバを用意し、ゾーン転送を行うとします。

しかし、192.168.1.0/24内にあるスレーブサーバからのリクエストは内部ゾーンのみにマッチしますので、外部ゾーン「dns-test.com」のゾーン転送が受け取れないということになります。

1台のDNSサーバで両方のゾーンのスレーブサーバを構築しようとするとIPアドレスが2つあるホストを使うか、rsyncやsftpなど、ファイルを転送するツールを使ってゾーンファイルを取得する手段が必要になります。


本日はココまで!
・1台のDNSサーバで内部向け、外部向けゾーンを構築する場合はVIEWを使う。
・VIEWで送信元のアドレスにマッチさせて、内部・外部ゾーンの情報提供を振り分ける
・VIEWは頭から評価される。
・スレーブサーバを立てる場合、ゾーン転送の問題が発生する。




ゾーンファイルはいくつか省略の記述方法があります。

以下は、非省略形のゾーンファイルです。
-----------------------------------------------------------------------
$TTL    10800
dns-test.com.    IN    SOA    ns.dns-test.com.   root.dns-test.com.  (
                2014083001      ; Serial
                43200        ; Refresh
                5400        ; Retry
                3600000    ; Expire
                3600 )        ; Minimum

dns-test.com.    IN    NS    ns.dns-test.com.
ns.dns-test.com.        IN    A    1.1.1.1
www.dns-test.com.    IN    A    1.1.1.3
mail01.dns-test.com.    IN    A    1.1.1.4
mail02.dns-test.com.    IN    A    1.1.1.5
-----------------------------------------------------------------------




「ドメイン名の省略」
つぎに省略形のゾーンファイルを記述します。
-----------------------------------------------------------------------
$TTL    10800
$ORIGIN    dns-test.com.

@            IN    SOA    ns   root  (
                2014083001      ; Serial
                43200        ; Refresh
                5400        ; Retry
                3600000    ; Expire
                3600 )        ; Minimum
@        IN    NS    ns
ns        IN    A    1.1.1.1
www    IN    A    1.1.1.3
mail01    IN    A    1.1.1.4
mail02    IN    A    1.1.1.5
-----------------------------------------------------------------------
どうでしょう。
まず、「$ORIGIN    dns-test.com.」という記述が見られます。この記述がある場合、「@マーク」が記載されているレコードには、ORIGINで定義したゾーン名の値が割り当てられます。

つまり、SOAレコードとNSレコードのところにある@マーク=dns-test.com ということになります。

ついにレコードのドメイン名が全て、「.」で終了していないところに注目して下さい。「.」で終了していない場合は、そのドメインにORIGINで定義したゾーン名の値が割り当てられます。

つまり、Aレコードにはすべて、「dns-test.com.」が追記されます。wwwの場合は、www.dns-test.com、nsの場合は、ns.dns-test.com、ということになります。


「TTLの省略」
また、各レコードのTTLも省略可能です。頭に記載されている$TTLの値が適用されます。つまり、ここでは各レコードのTTLに「10800」を指定したものと同じ事になります。


「レコードの名前フィールドの省略」
レコードを記述する際、一番左側の項目の記述を完全に省略すると、その前のレコードの名前フィールドが適用されます。

例えば以下の様に記述したものと
 dns-test.com.         IN    SOA    ns   root  (
 dns-test.com.         IN    NS    ns
 dns-test.com.         IN    MX    10   mail01

以下の様に記述したものは同じになります。
 dns-test.com.         IN    SOA    ns   root  (
                                IN    NS    ns
                                IN    MX    10   mail01



「$ORIGIN」を省略する」
以下の様に$ORIGINの記述も省略することが出来ます。しかし、これでは、何が省略されているか解らなくなってしまい、ミスの原因になることが往々にしてあるのでやめておきましょう。
-----------------------------------------------------------------------
$TTL    10800
@            IN    SOA    ns   root  (
                2014083001      ; Serial
                43200        ; Refresh
                5400        ; Retry
                3600000    ; Expire
                3600 )        ; Minimum
@        IN    NS    ns
ns        IN    A    1.1.1.1
www    IN    A    1.1.1.3
mail01    IN    A    1.1.1.4
mail02    IN    A    1.1.1.5
-----------------------------------------------------------------------


本日はココまで。
・$ORIGIN の記述で、ゾーン名を省略できる。
・レコードに「@マーク」を記述した場合は、ORIGINで指定したゾーン名がそのまま割り当てられる。
・レコードが「.」で終わっていない場合は、ORIGINで指定したゾーン名が足される。




named.confやゾーンファイルに変更を加えたときは、その変更を反映させるための操作が必要となります。

変更を反映される方法は2つあります。

1つ目は、
「BINDを再起動させる」です。
再起動の際に設定ファイルやゾーンファイルが改めて読み込まれます。この場合、キャッシュに残っていたデータは全て消去されます。

2つ目は、
「設定ファイル・ゾーンファイルの再読み込み」です。
全てのゾーンファイル(ゾーンファイルの指定も可能)とnamed.confが再読み込みされます。
この方法ではキャッシュのデータは消去されることなく変更を反映させることが出来ます。


本日はココまで!

・設定変更を反映させるには、「BINDを再起動させる」方法と、「設定ファイル・ゾーンファイルの再読み込み」方法の2つがあり、前者はキャッシュデータが全てクリアされ、後者はキャッシュデータは消去されない。

↑このページのトップヘ