ＢＩＮＤ９によるダイナミックＤＮＳサーバーの運用

検証環境

• 以下のソフトウェアの利用を前提に検証を実施した。いずれも現時点で最新のリリースに基づいて検証しているが、ある程度古い環境、より新しい環境でも問題無いと思われる。
  • ＯＳ： FreeBSD 11.2-R
  • ＤＮＳコンテンツサーバー： BIND9 9.13.2
• 上記以外の環境では、以下の点に相違が発生する。当該環境に応じて読み替えたし。
  • インストール方法
  • インストールされるディレクトリ
• 逆に以下の点は参考にできる。
  • 設定パラメータとその意味
  • 運用事例

検証作業内容

• ＤＮＳコンテンツサーバーでは「example.jp」ゾーンを運用する。
• 本サーバーでは外部（自身を含む）からのダイナミックアップデート要求に対し、「exmaple.jp」ゾーンに対してレコードの追加・変更・削除を実施する。

ＤＮＳコンテンツサーバーの基本設定

• ＤＮＳサーバーは ports/dns/bind913 をインストールする。

• ここでは特にカスタムする要素は無いので、デフォルトのままとする。
• 説明のため、稼働に必要な最低限の設定とする。

/etc/rc.conf

以下の設定を追加する。

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

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

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

   1 --- /usr/local/etc/namedb/named.conf.sample     2018-09-13 22:12:15.847935000 +0900
   2 +++ /usr/local/etc/namedb/named.conf    2018-09-13 22:46:26.048986000 +0900
   3 @@ -16,15 +16,20 @@
   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  // If named is being used only as a local resolver, this is a safe default.
  13  // For named to be accessible to the network, comment this option, specify
  14  // the proper IP address, or delete this option.
  15 -       listen-on       { 127.0.0.1; };
  16 +       listen-on       { any; };
  17 
  18  // If you have IPv6 enabled on this system, uncomment this option for
  19  // use as a local resolver.  To give access to the network, specify
  20  // an IPv6 address, or the keyword "any".
  21 -//     listen-on-v6    { ::1; };
  22 +       listen-on-v6    { any; };
  23 
  24  // These zones are already covered by the empty zones listed below.
  25  // If you remove the related empty zones below, comment these lines out.

• ＤＮＳコンテンツサーバーとして、以下の設定を行うものとする。
  • ＩＰｖ４／ＩＰｖ６問わず、全てのクエリを受け付ける。
  • 再帰問い合わせには答えないものとする。
  • よって本設定が行われているゾーン情報のみクエリに対して答える（ルートゾーンを含む）。
• ログ出力設定、ビュー設定、アクセス制御、マスター／スレイブ構成、といった機能については説明しない。
• なお原理上、本設定はマスターサーバーで実施するものであり、スレイブサーバーには適用しない／するものではない。

example.jp ゾーンの定義

/usr/local/etc/namedb/ＴＳＩＧキー名.key

下記コマンドを実行してＴＳＩＧキーを発行する。

tsig-keygen -a hmac-sha256 ＴＳＩＧキー名. > /usr/local/etc/namedb/ＴＳＩＧキー名.key
chown bind:wheel /usr/local/etc/namedb/ＴＳＩＧキー名.key
chmod 0400       /usr/local/etc/namedb/ＴＳＩＧキー名.key

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

   1 --- /usr/local/etc/namedb/named.conf.orig       2018-09-13 22:46:26.048986000 +0900
   2 +++ /usr/local/etc/namedb/named.conf    2018-09-26 14:33:08.706240000 +0900
   3 @@ -383,3 +383,11 @@
   4         };
   5  };
   6  */
   7 +
   8 +include "/usr/local/etc/namedb/ＴＳＩＧキー名.key";
   9 +
  10 +zone "example.jp" {
  11 +    type master;
  12 +    file "/usr/local/etc/namedb/dynamic/example.jp";
  13 +    allow-update { !{ !ＩＰｖ４アドレス; !ＩＰｖ６アドレス; any; }; key "ＴＳＩＧキー名."; };
  14 +};
  15 

/usr/local/etc/namedb/dynamic/example.jp

$TTL    300

@       IN SOA ns.example.jp. domain.example.jp. (
                1          ; serial
                7200       ; refresh (2 hours)
                900        ; retry (15 minutes)
                2419200    ; expire (4 weeks)
                86400      ; minimum (1 day)
                )
        IN NS   ns
ns      IN A    ＩＰｖ４アドレス
        IN AAAA ＩＰｖ６アドレス

• ここでは参考として SOA と NS レコードのみ設定するものとする。
• また本ファイル作成後、オーナーとパーミッションを以下の通り設定すること。

chown bind:wheel /usr/local/etc/namedb/dynamic/example.jp
chmod 0644       /usr/local/etc/namedb/dynamic/example.jp

動作検証

動作検証環境

• 以下のソフトウェアの利用を前提に検証を実施した。いずれも現時点で最新のリリースに基づいて検証しているが、ある程度古い環境、より新しい環境でも問題無いと思われる。
  • ＯＳ： FreeBSD 11.2-R

  • ＤＮＳクライアントツール： BIND9（ports/dns/bind-tools） ※現時点では 9.12.2P2

• ただし、古いＦｒｅｅＢＳＤ（９．ｘ等）標準の nsupdate コマンドは、ＴＳＩＧを取り扱えない（コンパイル時無効）ため、やはり ports からインストールする必要がある。
• また既にＢＩＮＤ９サーバー（ports/dns/bind913 など）をインストールしている環境では ports/dns/bind-tools をインストールする必要は無い。

動作検証環境構築および確認

• ダイナミックＤＮＳクライアント側に「/usr/local/etc/namedb/ＴＳＩＧキー名.key」ファイルをコピーする。
• その際オーナー・パーミッション設定に留意すること。この時、具体的な設置場所については利用するツールに応じて決める。
• クライアントは「allow-update」で指定した「ＩＰｖ４アドレス」ないし（and/or）は「ＩＰｖ６アドレス」であることを確認する。
• つまり「allow-update」による指定は、指定ＩＰアドレス以外のダイナミックＤＮＳ更新は許可しないことに注意。
• その代わり当該ゾーンの全てのレコードに対してアクセス（追加・変更・削除）可能である。

動作検証の実施

以下のコマンドを実行することにより検証を行う（インタラクティブモードで検証）。

# dig +short txt test.example.jp @ダイナミックＤＮＳサーバーのＩＰアドレス
# /usr/local/bin/nsupdate -k tsig.key
> server ダイナミックＤＮＳサーバーのＩＰアドレス
> update add test.example.jp. 5 TXT "hello, world."
> send
> quit
# dig +short txt test.example.jp @ダイナミックＤＮＳサーバーのＩＰアドレス
"hello, world."
# 

• この時正常に動作すれば「send」送信後には何もメッセージは表示されない。
• 許可ＩＰアドレス設定（allow-update）にミスがあれば「update failed: REFUSED」が表示される。

よくある質問とその答え

Ｑ．「response to SOA query was unsuccessful」という見慣れないエラーが発生しました。なぜです？設定は完璧なはずです！

# dig +short txt test.example.jp @ダイナミックＤＮＳサーバーのＩＰアドレス
# /usr/local/bin/nsupdate -k tsig.key
> server ダイナミックＤＮＳサーバーのＩＰアドレス
> update add test.example.jp. 5 TXT "hello, hello, world!"
> send
response to SOA query was unsuccessful
# dig +short txt test.example.jp @ダイナミックＤＮＳサーバーのＩＰアドレス
# 

Ａ．甘いな。激甘だな。完璧などとおこがましい。 ログファイル¹を見れば、 named 起動時に下記のようなメッセージを確認できるはず。

Sep 26 15:12:10 DynamicDNSServer named[21358]: zone example.jp/IN: loading from master file /usr/local/etc/named/dynamic/example.jp failed: file not found
Sep 26 15:12:10 DynamicDNSServer named[21358]: zone example.jp/IN: not loaded due to errors.

このケースの場合「file not found」つまりファイル名の指定に間違いがある（×etc/named/、○etc/namedb/）。精進すべし。

正しく設定した場合はログファイルには以下の通り出ている。

Sep 26 15:15:22 DynamicDNSServer named[21470]: zone example.jp/IN: loaded serial 1

Ｑ．実環境でテストしてしまいました！どうやって削除すればいいですか？ゾーンファイル編集すれば良いですか？

Ａ．ダイナミックＤＮＳで追加したならダイナミックＤＮＳで削除しないと。 （サービス停止して）オフラインであるならゾーンファイル編集でもかまいません。 ゾーンファイルは独特なフィードバックが行われています（機械処理故の限界な）ので、編集の際驚かないでください。

# dig +short txt test.example.jp @ダイナミックＤＮＳサーバーのＩＰアドレス
"hello, world."
# /usr/local/bin/nsupdate -k tsig.key
> server ダイナミックＤＮＳサーバーのＩＰアドレス
> update delete test.example.jp. TXT
> send
> quit
# dig +short txt test.example.jp @ダイナミックＤＮＳサーバーのＩＰアドレス

Ｑ．allow-update の指定が意味不明です。まずは解説を！

Ａ．ＢＩＮＤ９のＡＣＬ（アクセスコントロールリスト）の癖となります。詳しくは参考文献をお読みください。 というのは不親切なので、解説すると、

1. ＡＣＬの処理は左から右へ評価されます。これはＡＮＤ結合であるということを意味しません。
2. よってブール論理で解釈するのではなく、ファーストマッチ・ファーストアウトで解釈する必要があります。
3. 接続元ＩＰアドレスに対して、以下の３つが判断されます。
   • match and accept（一致かつ受諾）
   • match and reject（一致かつ拒絶）
   • no match（一致しない、なので次のリストに委ねる）
4. この時、ネスト（{･･･}）されていた場合、その内容について下記の２つの評価を行い、その結果に対して上記３つの判断が実施されます。
   • match（一致）
   • no match（不一致）
5. 当然ネストの中に更にネストできるので、それは上記２評価の繰り返しとなる。

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

1. 大枠は２つリストに分かれる。
   1. !{ !ＩＰｖ４アドレス; !ＩＰｖ６アドレス; any; }
   2. key "ＴＳＩＧキー名."
2. 最初のネストを分解すると、３つのリストに分かれる。
   1. !ＩＰｖ４アドレス
   2. !ＩＰｖ６アドレス
   3. any
3. 最初のネスト内では以下の評価を行う（「!」の評価に注意）。
   1. 「ＩＰｖ４アドレス『ではない』」の評価をする。「ＩＰｖ４アドレス」であれば「not match」として評価完了。そうでないなら「match」として次の評価。
   2. 「ＩＰｖ６アドレス『ではない』」の評価をする。「ＩＰｖ６アドレス」であれば「not match」として評価完了。そうでないなら「match」として次の評価。
   3. 「任意のアドレス」に･･･とここまで来ると match で解釈され、評価が終了する。また既に「match」評価されてるので、この場合の「any」の指定のあり／無しに意味はない（人間の直感には反するから入れておいた方がいい）。
   4. このネストでの結果を全体「!」＝match and reject で評価することから、「not match」（つまり次のリストの評価）の時は、次のリスト key が評価される。

参考文献

• 設定ガイド：オープンリゾルバー機能を停止するには【BIND編】

• Using Access Control Lists (ACLs) with both addresses and keys

• BIND9(9.13) Administrator Reference Manual

• nsupdate(1)

注釈