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

検証環境

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

検証作業内容

• ＤＮＳコンテンツサーバーでは「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）は、共有秘密鍵と一方向ハッシュ関数を使用してトランザクションレベルの認証をＤＮＳプロトコルにもたらす仕組みである。

ＴＳＩＧはＴＳＩＧキー名と秘密鍵（ｓｅｃｒｅｔ）からなり、以下のようなフォーマットになる（ＢＩＮＤ９では）。

key "ns-www." {
    algorithm hmac-sha256;
    secret "PfzeGvXiOqtPOwQJY/iNFrvlD3/eKAHRZ0TbyK5GYII=";
};

• 通常、これの発行は tsig-keygen コマンドを使用して作成する。
• 決めないと行けないのは「ＴＳＩＧキー名」（上記例では ns-www.）となる。
• algorithm は今のところ「hmac-sha256」で十分で変える必要は無い（数年レベルで）。
• secret は自動生成に任すに限る。

肝心のＴＳＩＧキー名についてだが、

• ＢＩＮＤ９．１３のマニュアルによれば「ホスト名１-ホスト名２.」を例示している。

• ホスト１はＤＮＳサーバー側、ホスト２はダイナミックＤＮＳアップデート（ＤＮＳ）クライアント側とし、ショートネームで指定している。
• 例えば、ＤＮＳサーバーが ns.example.jp、ダイナミックＤＮＳアップデートクライアント側 www.example.jp である場合、「ns-www.」とするのが妥当（ほんと？）。
• まぁなんでもいいけど、わかりやすいようにね。

/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 ANY test.example.jp @ダイナミックＤＮＳサーバーのＩＰアドレス
# /usr/local/bin/nsupdate -k ＴＳＩＧキー名.key
> server ダイナミックＤＮＳサーバーのＩＰアドレス
> update add test.example.jp. 5 TXT "hello, world."
> send
> quit
# dig +short ANY test.example.jp @ダイナミックＤＮＳサーバーのＩＰアドレス
"hello, world."
# 

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

よくある質問とその答え

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

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

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

Ａ．ＢＩＮＤ９のＡＣＬ（Access Controll Lists）の癖となります。詳しくは参考文献をお読みください。 というのは不親切なので、解説すると、

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 "ＴＳＩＧキー名." NAME test.example.jp. TXT; };

上記の例では「test.example.jp.」に完全一致かつＴＸＴレコードの場合のみアクセス（追加・変更・削除）が許可される。

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

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

update-policy の指定方法

先に見て通り「;」で区切って、複数の設定を行うことができる。 また複数指定した場合、上から順に評価される（条件が確定するとそこで評価を終了する）。 その指定方法については以下のパターンとなっている（update-policy local; という特殊事例は除く）。

update-policy {
    モード "アイデンティティ" ルールタイプ レコード名 タイプ;
};

モード

• grant と deny の２つある。通常は grant を使用することになる。

アイデンティティ

• ＴＳＩＧキー名を指定する（厳密には SIG(0) が絡むが･･･）。

ルールタイプ

• NAME, SUBDOMAIN, ZONESTAB, WILDCARD, SELF, SELFWILD, MS-SELF, MS-SUBDOMAIN, KRB5-SELF, KRB5-SUBDOMAIN, TCP-SELF, 6TO4-SELF, EXTERNAL の１３種類存在する（大文字小文字は区別しない）。

レコード名

• 限定したいレコード名を指定する。

タイプ

• 限定したいリソースタイプを指定する。これは０個以上（空白区切り）の指定が可能である（０個はほぼ全てのリソースタイプを許す※後述）。

ルールタイプとレコード名、タイプには相関（指定可能なオプション）に相違があるので、代表的なものをピックアップする。

ルールタイプ：NAME

update-policy {
    モード "アイデンティティ" NAME ＦＱＤＮ. [[タイプ] ...];
};

• 指定した「ＦＱＤＮ.」と完全一致に対する許可／拒絶します。
• 例えば「grant "アイデンティティ" name test.example.jp.」とした時、「test.example.jp」レコードの更新を許します。
• 厳密にマッチするので、test.example.jp のサブドメインすら一致しません。
• 当然、ゾーンに内包していないときは永久に一致しないことになります（文法エラーになりません）。

ルールタイプ：SUBDOMAIN

update-policy {
    モード "アイデンティティ" subdomain ワード [[タイプ] ...];
};

• 一応、当該ゾーンのサブドメイン「ワード」と「ゾーン名」に対する更新を許可／拒絶することになってます。
• 例えば「grant "アイデンティティ" subdomain test」とした時、「test.example.jp」と「example.jp」レコードの更新を許するはずです。
• でもそんなの関係なく「foo.example.jp.」が登録できちゃいました。何か解釈間違ってるのかな？

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

• 制限したいレコードを別レコードとして分ける。
• ここでは example.jp ゾーンから test.example.jp レコードを独立させる。

• いわゆる「共用ＤＮＳにおける『親子同居問題』」が存在するので、参考文献を確認しておくこと。

※ゾーンを分ける以外は、今までの話と同じであることから、上記の流れを参照すること。 ここでは再度説明しない。

/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-10-08 00:53:08.437564000 +0900
   3 @@ -383,3 +383,16 @@
   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/master/example.jp";
  13 +};
  14 +
  15 +zone "test.example.jp" {
  16 +    type master;
  17 +    file "/usr/local/etc/namedb/dynamic/test.example.jp";
  18 +    allow-update { !{ !ＩＰｖ４アドレス; !ＩＰｖ６アドレス; any; }; key "ＴＳＩＧキー名."; };
  19 +};
  20 

• example.jp ゾーンは「master」ディレクトリに設置する。
• test.example.jp ゾーンを定義する。

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

$TTL    300

@       IN SOA ns.example.jp. domain.example.jp. (
                20181001   ; 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 ＩＰｖ６アドレス
test    IN NS   ns

/usr/local/etc/namedb/dynamic/test.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.example.jp.

※本ファイル作成後のオーナー・パーミッションに注意すること。

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

参考文献

• 設定ガイド：オープンリゾルバー機能を停止するには【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へ移行のポイント（権威ＤＮＳサーバー編）

• RFC2845:DNSにおける秘密鍵のトランザクション認証(TSIG)

• 親の心子知らず？委任にまつわる諸問題について考える - ＪＰＲＳ

注釈