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

検証環境

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

ＴＳＩＧキー

ＴＳＩＧ（Transaction SIGnature）キーは

/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 ＴＳＩＧキー名.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 ＴＳＩＧキー名.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. これは「!」（reject）と「 」（accept、「!」が指定されてない）のニュアンスが直感的に違うことを意味します（今まで一致・不一致に見えませんでしたか？）。
5. ネスト（{･･･}）されていた場合、その内容について下記の２つの評価を行い（ここでは一致・不一致の直感とマッチする）、その結果に対して上記３つの判断が実施されます。
   • match（一致）
   • no match（不一致）
6. 当然ネストの中に更にネストできるので、それは上記２評価の繰り返しとなる。

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

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

Ｑ．１ＩＰ＝１ＴＳＩＧキー設定したい場合はどうすればいいのでしょうか？

Ａ．君のような勘のいいガ（ｒｙ。

裸の key "ＴＳＩＧキー名." では一致しなかったときに拒絶される（accept or reject）ことから、ネストで保護してやれば（accept or no match）行けます（下記例参照）。

allow-update {
    { !{ !ＩＰｖ４アドレス; any; }; key "ＴＳＩＧキー名１."; };
    { !{ !ＩＰｖ６アドレス; any; }; key "ＴＳＩＧキー名２."; };
};

Ｑ．あれ？これ acl 定義すれば簡単になるんじゃあ？

Ａ．君のような勘のいいガ（ｒｙ。

• 設定が大量（程度による）にある、引き継ぎのためのドキュメンテーション（ラベル付け）等を目的として、設定が必要なら、acl を定義した方がよい。
• 別に一個だけの時でも設定してよいが、大抵の管理者は手抜きしたがるだろうから、まずはそちらで（設定が一カ所にまとまってるというメリットもある）。
• というわけで一概に簡単になるわけではないし、手抜きは非合理なわけではない。

acl "ＡＣＬ名１" {
    !{ !ＩＰｖ４アドレス; any; }; key "ＴＳＩＧキー名１.";
};

acl "ＡＣＬ名２" {
    !{ !ＩＰｖ６アドレス; any; }; key "ＴＳＩＧキー名２.";
};

zone "example.jp" {
    type master;
    file "/usr/local/etc/namedb/dynamic/example.jp";
    allow-update { "ＡＣＬ名１"; "ＡＣＬ名２" };
};

Ｑ．ゾーンに対して広範に任意のレコードの変更ができてしまうようですが、特定のレコードだけに制限する方法はありますか？

Ａ．ない。正確には allow-update では解決しえない。 update-policy で設定するが、これにはトレードオフがあり、結果２つのソリューションがある（後述）。

Ｑ．もしかしてダイナミックＤＮＳって設定は簡単なのですか？

Ａ．Ｙｅｓ。簡単だ。allow-update か update-policy の２つのうちのどれかがゾーン設定にあればよい。厳密には、以下の条件となる。

• ゾーンのオーナーであること。
  • ＳＯＡレコードを有する。
  • マスターサーバーである。
  • ゾーンファイルへの書き出しが可能であること。
• ゾーン内で allow-update または update-policy が設定されていること。

ＡＣＬ設定もＴＳＩＧ設定も allow-update のための設定でしかない。究極 any と設定することで動く（実際に運用しちゃダメ）。

更新したいレコードの制限

• update-policy 設定により更新したいレコードの制限は行える。
• ＴＳＩＧキーの指定による制限は可能であるが、この設定はＩＰアドレス制限ができない（allow-update 設定は無視される）。
• よって、２つの選択肢がある。
  • update-policy 設定を受け入れて、任意のＩＰアドレスからの更新を許す（もちろんＴＳＩＧキーの制限はある）。
  • 変更したいレコードを独立したゾーンに切り分けて allow-update で制限する。そのゾーン内において自由な変更を許す。

update-policy による更新レコードの制限

allow-update の代わりに下記のように記述する。

    update-policy { grant "ＴＳＩＧキー名." subdomain test TXT; };

上記の例では「test」というサブドメイン（つまり test.example.jp のこと）に対してＴＸＴレコードのみアクセス（追加・変更・削除）が許可される。

複数指定したい場合は下記の通りとなる。

    update-policy {
        grant "ＴＳＩＧキー名１." subdomain test TXT;
        grant "ＴＳＩＧキー名２." subdomain test TXT;
    };

ゾーン切り分けによる更新レコードの制限

参考文献

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

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

• BIND9(9.13) Administrator Reference Manual

• Dynamic Update Policies

• nsupdate(1)

• BIND9.9から9.11へ移行のポイント（権威ＤＮＳサーバー編）

注釈