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

ＢＩＮＤ９によるダイナミックＤＮＳサーバーの運用
example.jp ゾーンの定義
動作検証
よくある質問とその答え
更新したいレコードの制限
1. update-policy による更新レコードの制限
  1. update-policy の指定方法
2. ゾーン切り分けによる更新レコードの制限
【付録】動的更新の安定性について
参考文献
注釈

検証環境

以下のソフトウェアの利用を前提に検証を実施した。いずれも現時点で最新のリリースに基づいて検証しているが、ある程度古い環境、より新しい環境でも問題無いと思われる。
- ＯＳ： 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 -v -k ＴＳＩＧキー名.key
> local allow-updateで許可したダイナミックＤＮＳクライアントのＩＰアドレス
> 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」が表示される。

※検証時における「local」指定について

通常の運用においてクライアント自身のＩＰを指定する「local」の指定は行う必要は無い。
設定が正しいかをまず確認するために指定するもので、検証段階で問題があれば実運用もおぼつかないため、切り分けのために指定する。
この段階で問題無いことを確認したならば、「local」指定を無くし、正常に動作することを確認すること。
nsupdate コマンドが自動で見つけてくる「ダイナミックＤＮＳクライアントのＩＰアドレス」が適切か検証できる。

よくある質問とその答え

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

# dig +short ANY test.example.jp @ダイナミックＤＮＳサーバーのＩＰアドレス
# /usr/local/bin/nsupdate -v -k ＴＳＩＧキー名.key
> local allow-updateで許可したダイナミックＤＮＳクライアントのＩＰアドレス
> 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 起動時に下記のようなメッセージを確認できるはず。

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

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

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

named[21470]: zone example.jp/IN: loaded serial 1

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

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

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

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

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

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

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

大枠は２つのリストに分かれる（「!」の意味に注意）。
1. !{ !ＩＰｖ４アドレス; !ＩＰｖ６アドレス; any; } → match and reject
2. key "ＴＳＩＧキー名." → accept or reject
最初のネストを分解すると、３つのリストに分かれる。
1. !ＩＰｖ４アドレス → 一致した場合「no match」という評価で完了
2. !ＩＰｖ６アドレス → 一致した場合「no match」という評価で完了
3. any → 一致（常に一致する）した場合「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

【付録】動的更新の安定性について

ダイナミックＤＮＳはＤＮＳプロトコルに乗って更新を行うため、いくつかの不安定さがある。

デフォルトＵＤＰなので、ＵＤＰパケットの「ロス」と「成功」の区別がつかない。
- 一応構成されるパケットの大きさに合わせてＵＤＰとＴＣＰの選択は行われるが･･･。
- nsupdate コマンドで「-v」オプションを付けることで、ＴＣＰ接続を強制することができる。
- これにより、少なくともダイナミックＤＮＳサーバーへの接続性の担保は取れる（サーバーの生死程度は）。
更新の確実性。
- 「成功」の応答が無いので、確実に更新されたわからない。
- またマスターの更新は問題無いにせよ、スレーブサーバーへの伝播まで確実にわからない。
実装毎の揺らぎ。
- ＢＩＮＤ９のバージョンにも寄るが、既に登録済みの、同一レコード・同一タイプの同一内容の時の振る舞い（エラーか無視か）など。

よって更新（追加・変更・削除）において一定のパターンがある。それを以下に示す。

一レコード追加の担保方法（上書き）

# /usr/local/bin/nsupdate -v -k tsig.key
> local allow-updateで許可したダイナミックＤＮＳクライアントのＩＰアドレス
> server ダイナミックＤＮＳサーバーのＩＰアドレス
> prereq yxrrset test.example.jp. TXT
> update delete test.example.jp. TXT
> send
> prereq nxrrset test.example.jp. TXT
> update add test.example.jp. 5 TXT "THIS IS A TEST MESSAGE."
> send
> quit

まず prereq yxrrset で「レコードが存在する」場合に「update delete」を実行するようにする。
この結果、当該レコード（text.example.jp. の TXT レコード）はゼロであることが担保される。
次に prereq nxdomain で「レコードが存在しない」場合に「update add」を実行する。
逆に１個でも存在すれば更新されないことを意味する。
上記更新（update add/delete）は「アトミック」に実施されないため、prereq [yn]xrrset で保護するものである。

レコードの上書きをしないようにする方法

# /usr/local/bin/nsupdate -v -k tsig.key
> local allow-updateで許可したダイナミックＤＮＳクライアントのＩＰアドレス
> server ダイナミックＤＮＳサーバーのＩＰアドレス
> prereq nxrrset test.example.jp. TXT
> update add test.example.jp. 5 TXT "THIS IS A TEST MESSAGE."
> send
> quit

運用上の要請から、既存レコードを上書きしたく無いケースで実施する場合のパターン。
prereq nxdomain で「レコードが存在しない」場合に「update add」を実行するというものである。

安全な削除方法

# /usr/local/bin/nsupdate -v -k tsig.key
> local allow-updateで許可したダイナミックＤＮＳクライアントのＩＰアドレス
> server ダイナミックＤＮＳサーバーのＩＰアドレス
> prereq nxrrset test.example.jp. TXT
> update delete test.example.jp. TXT
> send
> quit

存在しないレコードを削除しようとするとエラーになる実装に対して実施する。
prereq nxdomain で「レコードが存在しない」場合に「update delete」を実行するというものである。

参考文献

注釈

named のデフォルトファシリティは daemon であること、/etc/syslog.conf を変更してない場合、デフォルトのログファイルは /var/log/messages である。 (1)

bind9/ダイナミックＤＮＳサーバー (最終更新日時 2018-11-16 23:02:42 更新者 NorikatsuShigemura)