DNSのレプリケーション設定と運用

Contents

  1. DNSのレプリケーション設定と運用
    1. 検証環境
    2. 検証内容
    3. レプリケーションについて
  2. DNSコンテンツサーバーの基本設定(準備)
    1. DNSコンテンツマスターサーバーの基本設定
      1. /etc/rc.conf
      2. /usr/local/etc/namedb/named.conf
      3. /usr/local/etc/namedb/ns0-nsN.key
      4. /usr/local/etc/namedb/master/catalog.example.db
    2. DNSコンテンツスレーブサーバーの基本設定
      1. /etc/rc.conf
      2. /usr/local/etc/namedb/catalog/ ディレクトリ
      3. /usr/local/etc/namedb/named.conf
      4. /usr/local/etc/namedb/ns0-nsN.key
  3. ゾーンの追加
    1. /usr/local/etc/namedb/master/example.jp.db
    2. /usr/local/etc/namedb/named.conf
    3. /usr/local/etc/namedb/master/catalog.example.db
    4. リロード
      1. マスターサーバーのログ
      2. スレーブサーバーのログ
      3. スレーブサーバーで運用しているゾーン情報の確認
      4. スレーブサーバーでのゾーン個別の転送状態の確認
      5. スレーブサーバーでのマスターサーバーの状態の確認
      6. マスターサーバーでのスレーブサーバーの状態の確認
  4. ゾーンの削除
    1. /usr/local/etc/namedb/master/catalog.example.db
    2. リロード
      1. マスターサーバーのログ
      2. スレーブサーバーのログ
  5. マスターサーバーによるスレーブサーバーへのポリシーの強制
    1. ポリシーの種類
      1. 素のマスターサーバーの指定
      2. TSIGキー付きマスターサーバーの指定
      3. 二種類のマスターサーバー指定の振る舞いについての注意
      4. クエリ許可の指定
      5. ゾーン転送許可の指定
  6. よくある質問とその答え
    1. Q.ポリシーの強制はどこまで設定すればいいですか?
    2. Q.カタログゾーン内でTSIGキー名の指定はできる、つまりTSIGキー名は配布できるようですが、TSIGキー自体は配布できないのですか?
    3. Q.allow-query/allow-transfer の指定が意味不明です。まずは解説を!
    4. Q.最初に allow-* の設定を明示してるのは何故ですか?デフォルトでも十分だと思いますが。
    5. Q.参考文献にある「やってみた」系サイトの解説を見たところ、ダイナミックDNSアップデートしてるけど、実際のところどうなの?
    6. Q.なぜBIND9で?オワコンでは?
  7. 参考文献
  8. 付録1.APLレコード
  9. 注釈

検証環境

検証内容

レプリケーションについて

DNSコンテンツサーバーの基本設定(準備)

DNSコンテンツマスターサーバーの基本設定

/etc/rc.conf

以下の設定を追加する。

named_enable="YES"
named_chrootdir="/var/named"
altlog_proglist="named"

※altlog_proglist が既に設定済みの場合、「 named」を追加する。

あるいは下記コマンドを実行する(結果は同じ)。

sysrc named_enable=YES
sysrc named_chrootdir=/var/named
sysrc altlog_proglist+=named

/usr/local/etc/namedb/named.conf

   1 --- /usr/local/etc/namedb/named.conf.orig       2018-09-25 03:54:24.724317000 +0900
   2 +++ /usr/local/etc/namedb/named.conf    2018-11-10 21:38:31.343856000 +0900
   3 @@ -16,15 +16,22 @@
   4         dump-file       "/var/dump/named_dump.db";
   5         statistics-file "/var/stats/named.stats";
   6 
   7 +       recursion       no;
   8 +       allow-query       { none; };
   9 +       allow-recursion   { none; };
  10 +       allow-query-cache { none; };
  11 +
  12 +       allow-new-zones yes;
  13 +
  14  // If named is being used only as a local resolver, this is a safe default.
  15  // For named to be accessible to the network, comment this option, specify
  16  // the proper IP address, or delete this option.
  17 -       listen-on       { 127.0.0.1; };
  18 +       listen-on       { any; };
  19 
  20  // If you have IPv6 enabled on this system, uncomment this option for
  21  // use as a local resolver.  To give access to the network, specify
  22  // an IPv6 address, or the keyword "any".
  23 -//     listen-on-v6    { ::1; };
  24 +       listen-on-v6    { any; };
  25 
  26  // These zones are already covered by the empty zones listed below.
  27  // If you remove the related empty zones below, comment these lines out.
  28 @@ -378,3 +385,23 @@
  29         };
  30  };
  31  */
  32 +
  33 +include "/usr/local/etc/namedb/ns0-nsN.key";
  34 +
  35 +zone "catalog.example" {
  36 +       type    master;
  37 +       file    "/usr/local/etc/namedb/master/catalog.example.db";
  38 +       notify  explicit;
  39 +       allow-query {
  40 +               { !{ !ns1のIPアドレス; any; }; key "ns0-nsN."; };
  41 +               { !{ !ns2のIPアドレス; any; }; key "ns0-nsN."; };
  42 +       };
  43 +       allow-transfer {
  44 +               { !{ !ns1のIPアドレス; any; }; key "ns0-nsN."; };
  45 +               { !{ !ns2のIPアドレス; any; }; key "ns0-nsN."; };
  46 +       };
  47 +       also-notify {
  48 +                     ns1のIPアドレス          key "ns0-nsN.";
  49 +                     ns2のIPアドレス          key "ns0-nsN.";
  50 +       };
  51 +};
  52 

※カタログゾーン運用のための設定

※catalog.exmaple ゾーンに関する諸設定

/usr/local/etc/namedb/ns0-nsN.key

以下のコマンドを使用してTSIGキーを作成する。内容例については特に記載しない。

tsig-keygen -a hmac-sha256 ns0-nsN. > /usr/local/etc/namedb/ns0-nsN.key
chown bind:wheel /usr/local/etc/namedb/ns0-nsN.key
chmod 0400       /usr/local/etc/namedb/ns0-nsN.key

/usr/local/etc/namedb/master/catalog.example.db

$TTL    3600
@               IN      SOA     . . ( 1 86400 3600 86400 3600 )
                IN      NS      invalid.
version         IN      TXT     "1"

DNSコンテンツスレーブサーバーの基本設定

/etc/rc.conf

以下の設定を追加する。

named_enable="YES"
named_chrootdir="/var/named"
altlog_proglist="named"

※altlog_proglist が既に設定済みの場合、「 named」を追加する。

あるいは下記コマンドを実行する(結果は同じ)。

sysrc named_enable=YES
sysrc named_chrootdir=/var/named
sysrc altlog_proglist+=named

/usr/local/etc/namedb/catalog/ ディレクトリ

install -d -o bind -g wheel -m 0755 /usr/local/etc/namedb/catalog

/usr/local/etc/namedb/named.conf

   1 --- /usr/local/etc/namedb/named.conf.orig       2018-10-11 00:09:07.998066000 +0900
   2 +++ /usr/local/etc/namedb/named.conf    2018-11-10 22:10:47.557521000 +0900
   3 @@ -16,15 +16,28 @@
   4         dump-file       "/var/dump/named_dump.db";
   5         statistics-file "/var/stats/named.stats";
   6 
   7 +       recursion       no;
   8 +       allow-query       { any;  };
   9 +       allow-recursion   { none; };
  10 +       allow-query-cache { none; };
  11 +
  12 +       allow-new-zones yes;
  13 +       catalog-zones {
  14 +               zone            "catalog.example"
  15 +               zone-directory  "/usr/local/etc/namedb/catalog"
  16 +               in-memory       no
  17 +               default-masters { ns0のIPアドレス key "ns0-nsN."; };
  18 +       };
  19 +
  20  // If named is being used only as a local resolver, this is a safe default.
  21  // For named to be accessible to the network, comment this option, specify
  22  // the proper IP address, or delete this option.
  23 -       listen-on       { 127.0.0.1; };
  24 +       listen-on       { any; };
  25 
  26  // If you have IPv6 enabled on this system, uncomment this option for
  27  // use as a local resolver.  To give access to the network, specify
  28  // an IPv6 address, or the keyword "any".
  29 -//     listen-on-v6    { ::1; };
  30 +       listen-on-v6    { any; };
  31 
  32  // These zones are already covered by the empty zones listed below.
  33  // If you remove the related empty zones below, comment these lines out.
  34 @@ -378,3 +391,20 @@
  35         };
  36  };
  37  */
  38 +
  39 +include "/usr/local/etc/namedb/ns0-nsN.key";
  40 +
  41 +zone "catalog.example" {
  42 +       type    slave;
  43 +       file    "/usr/local/etc/namedb/slave/catalog.example.db";
  44 +       notify  no;
  45 +       masters {
  46 +               ns0のIPアドレス key "ns0-nsN.";
  47 +       };
  48 +       allow-query {
  49 +               !{ !ns0のIPアドレス; any; }; key "ns0-nsN.";
  50 +       };
  51 +       allow-transfer {
  52 +               !{ !ns0のIPアドレス; any; }; key "ns0-nsN.";
  53 +       };
  54 +};
  55 

※カタログゾーン運用のための設定

※catalog.exmaple ゾーンに関する諸設定

/usr/local/etc/namedb/ns0-nsN.key

ns0.example.jp サーバーよりTSIGキーをコピーする。

scp -p root@ns0.example.jp:/usr/local/etc/namedb/ns0-nsN.key /usr/local/etc/namedb/
chown bind:wheel /usr/local/etc/namedb/ns0-nsN.key
chmod 0400       /usr/local/etc/namedb/ns0-nsN.key

ゾーンの追加

※実際に作業を実施してみるとわかるが、確認以外のいわゆる上記作業内容において、マスターサーバーでのみ作業すれば良いことが理解できると思う。

/usr/local/etc/namedb/master/example.jp.db

$TTL   300

@               IN SOA ns0.example.jp. domain.example.jp. (
                        2018111101 ; serial
                        7200      ; refresh (2 hours)
                        900       ; retry (15 minutes)
                        2419200   ; expire (4 weeks)
                        86400     ; minimum (1 day)
                       )
                IN NS ns1
                IN NS ns2
ns1             IN A  ns1のIPアドレス
ns2             IN A  ns2のIPアドレス

/usr/local/etc/namedb/named.conf

   1 --- /usr/local/etc/namedb/named.conf.orig       2018-11-11 20:34:01.464258000 +0900
   2 +++ /usr/local/etc/namedb/named.conf    2018-11-11 20:50:14.935238000 +0900
   3 @@ -405,3 +405,21 @@
   4                       ns2のIPアドレス                        key "ns0-nsN.";
   5         };
   6  };
   7 +
   8 +zone "example.jp" {
   9 +       type    master;
  10 +       file    "/usr/local/etc/namedb/master/example.jp.db";
  11 +       notify  explicit;
  12 +       allow-query {
  13 +               { !{ !ns1のIPアドレス; any; }; key "ns0-nsN."; };
  14 +               { !{ !ns2のIPアドレス; any; }; key "ns0-nsN."; };
  15 +       };
  16 +       allow-transfer {
  17 +               { !{ !ns1のIPアドレス; any; }; key "ns0-nsN."; };
  18 +               { !{ !ns2のIPアドレス; any; }; key "ns0-nsN."; };
  19 +       };
  20 +       also-notify {
  21 +                     ns1のIPアドレス          key "ns0-nsN.";
  22 +                     ns2のIPアドレス          key "ns0-nsN.";
  23 +       };
  24 +};
  25 

/usr/local/etc/namedb/master/catalog.example.db

   1 --- /usr/local/etc/namedb/master/catalog.example.db.orig        2018-11-11 19:22:56.198224000 +0900
   2 +++ /usr/local/etc/namedb/master/catalog.example.db     2018-11-11 21:32:18.140863000 +0900
   3 @@ -1,4 +1,5 @@
   4  $TTL   3600
   5 -@              IN      SOA     . . ( 1 86400 3600 86400 3600 )
   6 +@              IN      SOA     . . ( 2 86400 3600 86400 3600 )
   7                 IN      NS      invalid.
   8  version                IN      TXT     "1"
   9 +eb7b38678a581b9e32078e8b009d0c5c789bce7a.zones IN      PTR     example.jp.
  10 

※カタログゾーン機能の一番の肝がこの行に集約される。

「eb7b38678a581b9e32078e8b009d0c5c789bce7a」というハッシュ値と思われる文字列の作り方は、 『「example.jp」のワイヤーフォーマット(wire format)をSHA1通して16進変換したもの』 というまさに正統なハッシュ値だったのである。

意味不明なので個別に作業工程を分解する。

  1. 「example.jp」を「.」で分解する(最後に暗黙の「.」がある前提)。結果は「example」「jp」「」の3つに分かれる。
  2. それぞれの文字数をカウントする。「example」=「7」、「jp」=「2」、「」=「0」。
  3. 文字数をバイナリとして各文字列破片に対するプレフィックスとして、分解した文字列破片を結合する。
  4. 得られたバイナリデータ(「0x07 0x65 0x78 0x61 0x6d 0x70 0x6c 0x65 0x02 0x6a 0x70 0x00」)、これがワイヤーフォーマットと言われるものである。
  5. バイナリの編集は難しいので、コマンドで実行する場合は、以下の通り。

printf '\7example\2jp\0'
  1. これをさらにSHA1通して16進数に変換する。

printf '\7example\2jp\0' | openssl sha1

リロード

マスターサーバーにて、以下のコマンドで再読み込みする。

rndc reload

コマンド実行後のログの振る舞いを以下に示す。

マスターサーバーのログ

named[12189]: received control channel command 'reload'
named[12189]: loading configuration from '/usr/local/etc/namedb/named.conf'
   :
named[12189]: reloading configuration succeeded
named[12189]: reloading zones succeeded
named[12189]: zone example.jp/IN: loaded serial 2018111101
named[12189]: all zones loaded
named[12189]: zone example.jp/IN: sending notifies (serial 2018111101)
named[12189]: zone catalog.example/IN: loaded serial 2
named[12189]: zone catalog.example/IN: sending notifies (serial 2)
named[12189]: running
named[12189]: client @0x802b09800 ns1のIPアドレス#38989/key ns0-nsn (catalog.example): transfer of 'catalog.example/IN': AXFR-style IXFR started: TSIG ns0-nsn (serial 2)
named[12189]: client @0x802b09800 ns1のIPアドレス#38989/key ns0-nsn (catalog.example): transfer of 'catalog.example/IN': AXFR-style IXFR ended
   :
named[12189]: client @0x802b0a600 ns1のIPアドレス#58236/key ns0-nsn (example.jp): transfer of 'example.jp/IN': AXFR started: TSIG ns0-nsn (serial 2018111101)
named[12189]: client @0x802b0a600 ns1のIPアドレス#58236/key ns0-nsn (example.jp): transfer of 'example.jp/IN': AXFR ended
named[12189]: client @0x802b01a00 ns1のIPアドレス#51278: received notify for zone 'example.jp'

スレーブサーバーのログ

named[38318]: client @0x802b02800 ns0のIPアドレス#61756/key ns0-nsn: received notify for zone 'example.jp': TSIG 'ns0-nsn': not authoritative
named[38318]: client @0x802b01a00 ns0のIPアドレス#55618/key ns0-nsn: received notify for zone 'catalog.example': TSIG 'ns0-nsn'
named[38318]: zone catalog.example/IN: notify from ns0のIPアドレス#55618: serial 2
named[38318]: zone catalog.example/IN: Transfer started.
named[38318]: transfer of 'catalog.example/IN' from ns0のIPアドレス#53: connected using ns1のIPアドレス#38989 TSIG ns0-nsn
named[38318]: catz: updating catalog zone 'catalog.example' with serial 2
named[38318]: zone catalog.example/IN: transferred serial 2: TSIG 'ns0-nsn'
named[38318]: transfer of 'catalog.example/IN' from ns0のIPアドレス#53: Transfer status: success
named[38318]: transfer of 'catalog.example/IN' from ns0のIPアドレス#53: Transfer completed: 1 messages, 15 records, 578 bytes, 0.001 secs (578000 bytes/sec)
named[38318]: catz: adding zone 'example.jp' from catalog 'catalog.example' - success
named[38318]: zone example.jp/IN: Transfer started.
named[38318]: transfer of 'example.jp/IN' from ns0のIPアドレス#53: connected using ns1のIPアドレス#58236 TSIG ns0-nsn
named[38318]: zone example.jp/IN: transferred serial 2018111101: TSIG 'ns0-nsn'
named[38318]: transfer of 'example.jp/IN' from ns0のIPアドレス#53: Transfer status: success
named[38318]: transfer of 'example.jp/IN' from ns0のIPアドレス#53: Transfer completed: 1 messages, 6 records, 259 bytes, 0.003 secs (86333 bytes/sec)
named[38318]: zone example.jp/IN: sending notifies (serial 2018111101)

スレーブサーバーで運用しているゾーン情報の確認

ゾーン転送された内容はバイナリ化されてるので、named-compilezone コマンドを使用してゾーンファイル(テキストフォーマット)に変換できる。

named-compilezone -f raw -F text -o /dev/stdout catalog.example /usr/local/etc/namedb/slave/catalog.example.db

※なお -f と -o オプションは必須である。-F オプションは体裁整えただけ(-f, -F オプションともに text がデフォルト)、ということで。

これに例えば | awk '/PTR/{ print $3 }' とフィルタしてしまえば、運用ゾーンの一覧が取得できたりする。

スレーブサーバーでのゾーン個別の転送状態の確認

カタログゾーンにより転送されたゾーン情報は /usr/local/etc/namedb/catalog/__catz___default_catalog.example_example.jp.db というファイルに保存される。

この事から、スレーブサーバーでは、複数のマスターサーバーからの同期を想定していることが予想される。 今回 view は使わなかったけど、view を使わないとできない使い方については後述。

またゾーン転送された内容はバイナリ化されてるので、named-compilezone コマンドを使用してゾーンファイル(テキストフォーマット)に変換できる。

named-compilezone -f raw -F text -o /dev/stdout example.jp /usr/local/etc/namedb/catalog/__catz___default_catalog.example_example.jp.db

※なお -f と -o オプションは必須である。-F オプションは体裁整えただけ(-f, -F オプションともに text がデフォルト)、ということで。

スレーブサーバーでのマスターサーバーの状態の確認

マスターサーバーのゾーン定義で許可された allow-query 設定により、スレーブサーバーからマスターサーバーの状態を確認できる。

dig -k /usr/local/etc/namedb/ns0-nsN.key +short example.jp      soa  @ns0のIPアドレス
dig -k /usr/local/etc/namedb/ns0-nsN.key +short catalog.example soa  @ns0のIPアドレス

ゾーン転送もお手の物。これと先のファイルの内容と比較して転送されているかを確認する。

dig -k /usr/local/etc/namedb/ns0-nsN.key        example.jp      axfr @ns0のIPアドレス
dig -k /usr/local/etc/namedb/ns0-nsN.key        catalog.example axfr @ns0のIPアドレス

マスターサーバーでのスレーブサーバーの状態の確認

本例ではそれができるよう設定を行ったため、スレーブからマスターを見た先の例と同じく、マスターからスレーブの状態を確認することができる。

※なお下記例でのnsNはns1またはns2を示す。

dig -k /usr/local/etc/namedb/ns0-nsN.key +short example.jp      soa  @nsNのIPアドレス
dig -k /usr/local/etc/namedb/ns0-nsN.key +short catalog.example soa  @nsNのIPアドレス

ゾーン転送もお手の物。これとオリジナルのファイルの内容と比較して転送されているかを確認する。

dig -k /usr/local/etc/namedb/ns0-nsN.key        example.jp      axfr @nsNのIPアドレス
dig -k /usr/local/etc/namedb/ns0-nsN.key        catalog.example axfr @nsNのIPアドレス

ゾーンの削除

※実際に作業を実施してみるとわかるが、確認以外のいわゆる上記作業内容において、マスターサーバーでのみ作業すれば良いことが理解できると思う。

/usr/local/etc/namedb/master/catalog.example.db

   1 --- /usr/local/etc/namedb/master/catalog.example.db.orig        2018-11-11 21:32:18.140863000 +0900
   2 +++ /usr/local/etc/namedb/master/catalog.example.db     2018-11-11 23:44:01.315413000 +0900
   3 @@ -1,5 +1,4 @@
   4  $TTL   3600
   5 -@              IN      SOA     . . ( 2 86400 3600 86400 3600 )
   6 +@              IN      SOA     . . ( 3 86400 3600 86400 3600 )
   7                 IN      NS      invalid.
   8  version                IN      TXT     "1"
   9 -eb7b38678a581b9e32078e8b009d0c5c789bce7a.zones IN      PTR     example.jp.
  10 

リロード

マスターサーバーにて、以下のコマンドで再読み込みする。

rndc reload

あるいは本ケース(手抜き)の場合、以下の手順でもよい。

rndc reload catalog.example

マスターサーバーのログ

named[12189]: received control channel command 'reload'
named[12189]: loading configuration from '/usr/local/etc/namedb/named.conf'
   :
named[12189]: zone catalog.example/IN: loaded serial 3
named[12189]: zone catalog.example/IN: sending notifies (serial 3)
named[12189]: client @0x802b03600 ns1のIPアドレス#26365/key ns0-nsn (catalog.example): transfer of 'catalog.example/IN': AXFR-style IXFR started: TSIG ns0-nsn (serial 3)
named[12189]: client @0x802b03600 ns1のIPアドレス#26365/key ns0-nsn (catalog.example): transfer of 'catalog.example/IN': AXFR-style IXFR ended

スレーブサーバーのログ

named[38318]: client @0x802b01a00 ns0のIPアドレス#51757/key ns0-nsn: received notify for zone 'catalog.example': TSIG 'ns0-nsn'
named[38318]: zone catalog.example/IN: notify from ns0のIPアドレス#51757: serial 3
named[38318]: zone catalog.example/IN: Transfer started.
named[38318]: transfer of 'catalog.example/IN' from ns0のIPアドレス#53: connected using ns1のIPアドレス#26365 TSIG ns0-nsn
named[38318]: catz: updating catalog zone 'catalog.example' with serial 3
named[38318]: zone catalog.example/IN: transferred serial 3: TSIG 'ns0-nsn'
named[38318]: transfer of 'catalog.example/IN' from ns0のIPアドレス#53: Transfer status: success
named[38318]: transfer of 'catalog.example/IN' from ns0のIPアドレス#53: Transfer completed: 1 messages, 9 records, 358 bytes, 0.005 secs (71600 bytes/sec)
named[38318]: catz: deleting zone 'example.jp' from catalog 'catalog.example' - success
named[38318]: catz: catz_delzone_taskaction: zone 'example.jp' deleted

マスターサーバーによるスレーブサーバーへのポリシーの強制

物々しいタイトルではあるが、カタログゾーンを通じて、いくつかのポリシーをスレーブ側に強制することができる。 このポリシーは、スレーブ側の設定によらず、マスター側の設定が正となる(設定の上書き)。 更にそのポリシーはゾーン毎に制御可能で、以下の優先度で設定がオーバーライドできる。

  1. ゾーン毎の個別設定
  2. カタログゾーンのデフォルト設定
  3. スレーブサーバーのグローバル設定

上記優先順位の意味するところは以下の通りである。よってこれらポリシーが混ざることはない。

  1. 「ゾーン個別設定」が【無ければ】「カタログゾーンデフォルト設定」に従う。
  2. 「カタログゾーンデフォルト設定」が【無ければ】「スレーブサーバーのグローバル設定」に従う。

また当然だが、このポリシ-の強制はカタログゾーン「catalog.example」自体には適用されない。

ポリシーの種類

allow-query、allow-trasnfer 設定についてはよく見る設定なので特に説明の必要は無いと思う。

マスターサーバーの「デフォルト」の指定は今までのBINDには無かった設定で、 「catalog-zones」中の「default-masters」設定で行う1

よって設定において masters のデフォルトと聞いた時は「catalog-zones 中の default-masters」であることを意味する。

素のマスターサーバーの指定

options {
  catalog-zones {
     :
    default-masters { ns0のIPアドレス; };
  };
};

$TTL    3600
@               IN      SOA     . . ( 1 86400 3600 86400 3600 )
                IN      NS      invalid.
version         IN      TXT     "1"
masters         IN      A       ns0のIPv4アドレス

$TTL    3600
@               IN      SOA     . . ( 1 86400 3600 86400 3600 )
                IN      NS      invalid.
version         IN      TXT     "1"
eb7b38678a581b9e32078e8b009d0c5c789bce7a.zones          IN      PTR     example.jp.
masters.eb7b38678a581b9e32078e8b009d0c5c789bce7a.zones  IN      A       ns0のIPv4アドレス

TSIGキー付きマスターサーバーの指定

options {
  catalog-zones {
     :
    default-masters { ns0のIPアドレス key "TSIGキー名"; };
  };
};

$TTL    3600
@               IN      SOA     . . ( 1 86400 3600 86400 3600 )
                IN      NS      invalid.
version         IN      TXT     "1"
label.masters   IN      A       ns0のIPv4アドレス
label.masters   IN      TXT     "TSIGキー名"

$TTL    3600
@               IN      SOA     . . ( 1 86400 3600 86400 3600 )
                IN      NS      invalid.
version         IN      TXT     "1"
eb7b38678a581b9e32078e8b009d0c5c789bce7a.zones          IN      PTR     example.jp.
label.masters.eb7b38678a581b9e32078e8b009d0c5c789bce7a.zones    IN      A       ns0のIPv4アドレス
label.masters.eb7b38678a581b9e32078e8b009d0c5c789bce7a.zones    IN      TXT     "TSIGキー名"

二種類のマスターサーバー指定の振る舞いについての注意

クエリ許可の指定

options {
  allow-query {
    ACLs:
  };
};

$TTL    3600
@               IN      SOA     . . ( 1 86400 3600 86400 3600 )
                IN      NS      invalid.
version         IN      TXT     "1"
allow-query     IN      APL     1:0.0.0.0/0 2:0:0:0:0:0:0:0:0/0

$TTL    3600
@               IN      SOA     . . ( 1 86400 3600 86400 3600 )
                IN      NS      invalid.
version         IN      TXT     "1"
eb7b38678a581b9e32078e8b009d0c5c789bce7a.zones                  IN      PTR     example.jp.
allow-query.eb7b38678a581b9e32078e8b009d0c5c789bce7a.zones      IN      APL     1:0.0.0.0/0  2:0:0:0:0:0:0:0:0/0

ゾーン転送許可の指定

options {
  allow-transfer {
    ACLs:
  };
};

$TTL    3600
@               IN      SOA     . . ( 1 86400 3600 86400 3600 )
                IN      NS      invalid.
version         IN      TXT     "1"
allow-transfer  IN      APL     !1:0.0.0.0/0 !2:0:0:0:0:0:0:0:0/0

$TTL    3600
@               IN      SOA     . . ( 1 86400 3600 86400 3600 )
                IN      NS      invalid.
version         IN      TXT     "1"
eb7b38678a581b9e32078e8b009d0c5c789bce7a.zones                  IN      PTR     example.jp.
allow-transfer.eb7b38678a581b9e32078e8b009d0c5c789bce7a.zones   IN      APL     !1:0.0.0.0/0 !2:0:0:0:0:0:0:0:0/0

よくある質問とその答え

Q.ポリシーの強制はどこまで設定すればいいですか?

A.カタログゾーンのデフォルトとして定義しておけば、以下の理由でメリットあると思われ。

よってマスターサーバーで最初に作る /usr/local/etc/namedb/master/catalog.example.db の内容は下記の通りにしておけばよい。

$TTL    3600
@               IN      SOA     . . ( 1 86400 3600 86400 3600 )
                IN      NS      invalid.
version         IN      TXT     "1"
label.masters   IN      A       ns0のIPv4アドレス
label.masters   IN      TXT     "TSIGキー名"
allow-query     IN      APL      1:0.0.0.0/0  2:0:0:0:0:0:0:0:0/0
allow-transfer  IN      APL     !1:0.0.0.0/0 !2:0:0:0:0:0:0:0:0/0

またスレイブサーバーの catalog-zones 設定は下記の通り default-masters 設定を削除する。

        catalog-zones {
                zone            "catalog.example"
                zone-directory  "/usr/local/etc/namedb/catalog"
                in-memory       no;
        };

Q.カタログゾーン内でTSIGキー名の指定はできる、つまりTSIGキー名は配布できるようですが、TSIGキー自体は配布できないのですか?

A.おっと。ゾーン転送はTSIGキーそのもの(これは秘密鍵です)を配布できるほど、安全な通信経路ではないです。 TSIGキーを配布したければ、SCP/RSYNCを使用するか、 さらにマスターサーバーで実行するかスレーブサーバーで実行するか、 といった点を検討の上、運用する必要があります。

あるいはSIG(0)(公開鍵暗号ベースの鍵共有プロトコル)やGSS-TSIG(Generic Security Service Algorithm for TSIG)といったDNS内に閉じた鍵配布する仕組みが用意されているようですが、 軽くググってでも出てこないことからお察しで。

Q.allow-query/allow-transfer の指定が意味不明です。まずは解説を!

A.BIND9のACL(Access Controll Lists)の癖となります。詳しくは参考文献をお読みください。 というのは不親切なので、解説すると、

  1. ACLの処理はリストの左から右へ評価されます。これはAND結合であるということを意味しません。
  2. よってブール論理で解釈するのではなく、ファーストマッチ・ファーストアウトで解釈する必要があります。
  3. 接続元IPアドレスに対して、以下の3つが判断されます。
    • match and accept(一致かつ受諾)
    • match and reject(一致かつ拒絶)
    • no match(一致しない、なので次のリストに委ねる)
  4. これは「!」(reject)と「 」(accept、「!」が指定されてない)のニュアンスが直感的に違うことを意味します(今まで一致・不一致に見えませんでしたか?)。
  5. ネスト({・・・})されていた場合、その内容について下記の2つの評価を行い(ここでは一致・不一致の直感とマッチする)、その結果に対して上記3つの判断が実施されます。
    • match(一致)
    • no match(不一致)
  6. 当然ネストの中に更にネストできるので、それは上記2評価(match または no match)の繰り返しとなる。

上記ルールを踏まえ、問題のルールを解析すると・・・。

  • 大枠は2つのリストに分かれる(「!」の意味に注意)。
    1. !{ !IPv4アドレス; !IPv6アドレス; any; } → match and reject
    2. key "TSIGキー名." → accept or reject
  • 最初のネストを分解すると、3つのリストに分かれる。
    1. !IPv4アドレス → 一致した場合「no match」という評価で完了
    2. !IPv6アドレス → 一致した場合「no match」という評価で完了
    3. any → 一致(常に一致する)した場合「match」という評価で完了

上記をまとめて解釈すると、

  • 最初のネスト内では以下の評価を行う(「!」の評価に注意)。
    1. 「IPv4アドレス『ではない』」の評価をする。
      • 指定された「IPv4アドレス」であれば「no match」として評価完了。
      • そうでないなら「match」として次の評価。
    2. 「IPv6アドレス『ではない』」の評価をする。
      • 指定された「IPv6アドレス」であれば「no match」として評価完了。
      • そうでないなら「match」として次の評価。
    3. 「any」(任意の全てのアドレス)に・・・とここまで来ると常に match と解釈され、評価が終了する。
    4. また any の時点で既に、「match」評価されてるので、この場合の「any」の指定のあり/無しに意味はない
      • ※人間の直感には反するから入れておいた方がいい。
  • このネストでの結果を全体「!」=match and reject で評価することから、「no match」(つまり次のリストの評価)の時は、次のリスト key が評価される。

Q.最初に allow-* の設定を明示してるのは何故ですか?デフォルトでも十分だと思いますが。

A.ポリティカル・コレクトネスです。以下の4つの設定のデフォルトは下記の通りとなります。

設定

デフォルト値

今回の設定値

備考

recursion

yes

no

allow-query

any

any(none)

隠れマスター運用なので none を指定しただけ

allow-recursion

localnets, localhost

none

allow-query-cache

localnets, localhost

none

よって「recursion」設定以外は「対インターネット」向けサービスとして見た場合、 意味はあまり変わりません。もちろんローカルネットワーク内での不用意なアクセスに 対して防御する意味合いはありますので、そこを含めて「ポリコレ」的に設定を実施します。

詳しくは参考文献をご確認ください。

Q.参考文献にある「やってみた」系サイトの解説を見たところ、ダイナミックDNSアップデートしてるけど、実際のところどうなの?

A.カタログゾーン機能の運用に当たり、ダイナミックDNSアップデートによる更新は必須ではありません。 ただし、本例で解説したカタログゾーンであるところ「catalog.example」については、 ダイナミックDNSアップデートによる設定および運用は推奨されています。

これはSOAレコードのシリアル番号更新忘れ対策として一番のメリットがあります。 またデメリットであるところのNSUPDATEスクリプトを書いてのコマンド実行については、 シェルスクリプトによる工で運用負荷を下げることができます。

いずれにせよ追加ゾーン(本例では example.jp)の設定までダイナミックDNSアップデートするかは、 今までの運用を見て判断するところだと思います。 全てを頑張る必要はありません。

ダイナミックDNSアップデートについては、ダイナミックDNSサーバーの設定を参照して欲しい。

Q.なぜBIND9で?オワコンでは?

A.ええ。オワコンでしょうね。キャッシュサーバーとしてはUnbound使えば十分で、 唯一コンテンツサーバーとして生きる道しか残ってないと思います。

そのコンテンツサーバーとしても、PowerDNS、NSD等がより有力な存在としてリストアップされてるようですが、 その辺りは 参考文献をご覧ください。 「結論」については自分もそう思います。

ただBIND9を出て行った先は今時AWS Rotue53ではないでしょうか。 費用面(1ゾーン百数十円/月)、運用面(管理画面の存在、APIのよる外部アクセス)、 セキュリティ面(たくさんのDNSサーバーにゾーンを分散、AWSへの運用委託)。

最近になって自社運用からRoute53へ切り替えましたが、これらを理由として上げられて、否定できる要素は全くありませんでした。

こんな話もありますが(賛同しますが)、 同時に自ら運用することの是非について考えるべきだと思います。

参考文献

付録1.APLレコード

注釈

  1. masters 設定は zone 設定内で、つまりゾーン毎に設定するため、「デフォルトのマスターサーバーの指定」という設定は存在しない。 (1)

  2. 原理的にマスターサーバーを自身のマスター以外に、かつ、次々に乗り換えさせることができそうだが、カタログゾーン自体が静的に定義されてるので、意図しないマスターサーバーに仕向けることができるかは不明。 (2)

bind9/DNSのレプリケーション設定と運用 (last edited 2019-05-08 19:35:18 by NorikatsuShigemura)