第7回　Dynamic DNSの基礎とnsupdateコマンド

 鶴長 鎮一
2003/7/8

ACLによるDynamic DNSの実現とnsupdate

　では、Dynamic DNSを使用できるようにしましょう。以下の説明では、図3のようなスレーブ・ゾーンサーバを含む構成を前提にしますが、update要求を直接マスター・ゾーンサーバに行う場合も想定します。

図3　想定環境

　ここでは、前述のupdate許可とforward許可にACL（アクセスコントロールリスト）を用います。マスター・ゾーンサーバにはupdate許可を、スレーブ・ゾーンサーバにはforward許可を設定します。ゾーン転送に必要な設定については、第5回も参照ください。

###ACL「example-net」の定義（注）###
acl example-net {
        192.168.20.21;  #クライアントのIP（ホストのIPを指定した例）
        192.168.10.2;   #スレーブ・サーバのIP（ホストのIPを指定した例）
        192.168.0/24;   #クライアントを含むネットワークアドレス（ネットワーク単位で指定した例）
        192.168.20.0/27;#クラスC未満のネットワーク指定も可能
};

zone "example.jp" {
        type master;
        file "example.zone";

        ### update許可###
        ###クライアントとスレーブ・サーバの双方にupdate許可を設定###
        allow-update{

                ###クライアントに対する設定###
                example-net;    #定義されたACLを用いた場合
                192.168.20.21;  #直接要求元のIPを指定した場合（ネットワークアドレスによる指定も可能）

                ###スレーブ・サーバに対する設定###
                example-net;    #定義されたACLを用いた場合
                192.168.10/24;  #スレーブ・サーバのIPをネットワークアドレスで指定した場合

        };

        ###ゾーン転送設定###
        allow-transfer{
        #ゾーン転送の設定については第5回参照
}
マスター・ゾーンサーバのnamed.conf例
注：none/any/localhost/localnetsを既定のACLとして利用することが可能です。

###ACLの定義###
acl example-net {
        （省略）
};

zone "example.jp" {
        type slave;
        file "example.zone.bak";
        masters {
                マスター・サーバのIPアドレス;
        };
        ### forward許可###
        ### どのホストに対してもupdate許可を設定しない ###
        allow-update-forwarding{
                example-net;    定義されたACLを用いた場合
                192.168.20.21;  直接要求元のIPを指定した場合
                192.168.20.0/24;    ネットワーク単位で指定した場合
        };
};
スレーブ・サーバのnamed.conf例

　ACLの指定には、「ホスト直接指定」「ネットワークアドレス指定」「ACLの利用」と、さまざまなスタイルがあることを理解していただくために設定を重複させていますが、実際にはどれか1つを設定すれば動作可能です。

　named.confの変更を有効にするために、第5回で紹介したrndcを用いてreloadを実施するか、namedプロセスの再起動を行います。

■nsupdateによる更新

　BIND 9に含まれるnsupdateコマンドを使用してみましょう。コマンドパスは、ソースからインストールした場合は/usr/local/bin/nsupdate、rpmなどのパッケージ管理ツールでインストールした場合は/usr/bin/nsupdateになります。

$ nsupdate -d　←「-d」でデバッグモード指定
> server 192.168.10.2　←省略可能（要求の送信先を指定）
> prereq yxdomain clientC.example.jp　←省略可能（clientC.example.jpが事前に登録されていることが前提）

> update add clientC.example.jp. 3600 IN A 192.168.20.11（TTLを3600、clientC.example.jpを192.168.20.11として登録）

> show　←省略可能（実際の実行の前に確認）

Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:      0
;; flags: ; ZONE: 0, PREREQ: 0, UPDATE: 0, 
ADDITIONAL: 0
;; PREREQUISITE SECTION:
clientC.example.jp.   0       ANY     ANY

;; UPDATE SECTION:
clientC.example.jp.   3600    IN      A       192.168.20.11

> send　←単に改行だけでも可能（update要求の送信）

Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id:  49917
;; flags: qr aa rd ra ; QUESTION: 1, ANSWER: 0, AUTHORITY: 1,
 ADDITIONAL: 0
;; QUESTION SECTION:
;clientC.example.jp.          IN      SOA

;; AUTHORITY SECTION:
example.jp.           0       IN      SOA     dns.example.jp. 
root.example.jp. 2003062701 3600 900 3600 3600


Found zone name: example.jp
The master is: dns.example.jp

Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:   9903
;; flags: qr ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
（エラーの場合はエラーコードが表示される）

###事前にclientC.example.jp.が登録されていない場合###
Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NXDOMAIN, id:  17023
;; flags: qr ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0

>^D　←quitまたは［Ctrl］＋［D］で終了

　上の例では、clientC.example.jpの正引きに対して192.168.20.11を登録しています。実行は一般ユーザーでも可能です。nsupdateの使用に慣れるまでは、「-d」を付けてデバッグ情報を表示するとよいでしょう。

　nsupdateの対話モードでは、プロンプトが「>」に変わります。例では、まずserverの指定を行っていますが、これは省略可能です。省略時は、前述したように通常のDNS検索でudpate対象となるゾーンサーバを検索します。serverで指定されたゾーンサーバに意図したゾーン情報がない場合も、同じようにDNS検索でゾーンサーバを探します。すでにゾーンサーバが分かっている場合にserver指定を行います。

　続いてupdateに必要な条件を指定します。ここでは、updateの前提条件に「yxdomain」を指定し、clientC.example.jpがすでに登録されていることを条件にしていますが、ほかにも次のような指定が可能です。また、これを省略することで前提条件をなしにできます。
  • prereq yxdomain FQDNホスト名
    指定したFQDNホスト名が少なくとも1つは登録されていることを条件とする。何も登録されていなければupdateはエラーになる。

  • prereq nxdomain FQDNホスト名
    指定したFQDNホスト名の登録が一切ないことを条件とする。すでに登録されている場合はupdateはエラーになる。

  • prereq yxrrset FQDNホスト名 (class) type data
    指定したFQDNホスト名とレコードが登録されていることを条件とする。
    例：prereq yxrrset host.example.jp IN A 192.168.20.20
    host.example.jpに対する正引きが192.168.20.20で事前に登録されていればupdate可能。
    「prereq yxrrset host.example.jp IN A」とした場合は、どのようなIPアドレスでも登録されていればupdate可能。

  • prereq nxrrset FQDNホスト名 (class) type
    指定したFQDNホスト名とレコードが登録されていないことを条件とする。yxrrsetのようにdataまで指定しても、無視される。
    例：prereq nxrrset host.example.jp IN A
    host.example.jpに対する正引きが事前に登録されていればupdateはエラー。Aレコード以外の登録（CNAMEなど）の場合はupdate可能。
    「prereq nxrrset host.example.jp IN A」とした場合は、どのようなIPアドレスでも登録されているとupdateはエラーになる。
注：ここで指定している「yxdomain」や「yxrrset」などのオペコードは、
RFC 2136：http://rfc-jp.nic.ad.jp/cgi-bin/direct.cgi?keyword=2136&language=eng&x=10&y=16
日本語訳：http://www5d.biglobe.ne.jp/~stssk/rfc2136j.html
で見ることができます。

　prereqで前提条件を設定した後に、updateの内容を記述します。この例では、次のようなレコードが登録されることを意図しています。

clientC.example.jp.   3600    IN      A       192.168.20.11

　TTLの指定は単位を秒にしたもので、省略できません。「1h」や「1d」などの省略表記は使用できません。Aレコード以外にも、MXやCNAMEなど、ゾーンファイルに使用されるほとんどのレコードタイプの指定が可能です。例ではaddを実行していますが、deleteを実行することも可能です。

> update delete FQDNホスト名 (class) (type) (data)

　deleteの場合は、FQDNホスト名だけの指定でも可能です。その際は、FQDNホスト名に対するあらゆるレコード（CNAMEやMX）も削除されます。条件を細かく設定するには、class、type、dataを指定します。

update delete clientC.example.jp. IN A 192.168.20.11
実行例　clientC.example.jp.に対する正引きで192.168.20.11のレコードを削除

update delete clientC.example.jp. IN A
実行例　clientC.example.jp.に対するすべてのAレコードを削除

　update……の末尾で［Enter］キーをタイプしても、その時点でupdate要求が送信されることはありません。続けてほかのレコードのupdateを行うことを想定し、「send」または単に改行だけの行がタイプされるまで、要求を蓄えます。このように、細切れにupdateを行わず、まとめて実施することでDNS Updateを効率よく処理するというわけです。

　updateが複雑な場合は、「show」コマンドが役に立ちます。これからどのようなupdateクエリを送信するかを事前に確認できます。確認内容に間違いがなければ、「send」を実行します。

　クエリの結果は「Reply from update query」中の「status」で確認できます。エラーの状況によって、refused、yxdomain、nxdomainなどの応答コードが表示されます。まとめて登録する場合は、上記のような対話方式ではなく、以下のようなファイルを使った一括登録が可能です。

$ nsupdate temp.txt

update add client1.example.jp. 3600 IN A 192.168.20.21
update add client2.example.jp. 3600 IN A 192.168.20.22
update add client3.example.jp. 3600 IN A 192.168.20.23
update add client4.example.jp. 3600 IN A 192.168.20.24
update add client5.example.jp. 3600 IN A 192.168.20.25
...
update add client30.example.jp. 3600 IN A 192.168.20.30
　←最後に必ず改行だけの行を追加すること
temp.txt

2/3

Index
実用 BIND 9で作るDNSサーバ
　第7回 Dynamic DNSとnsupdateコマンド
　 Page 1
Dynamic DNSの仕組み
　Dynamic DNSの基本的な動作
　マスター／スレーブで構成されたDynamic DNS
　 Page 2
ACLによるDynamic DNSの実現とnsupdate
　nsupdateによる更新
　 Page 3
Dynamic DNSの動作確認とセキュリティ対策
　/var/log/messagesの確認
　TSIG（Transaction Signature）の利用
　update-policyの利用
　jnlファイルとトラブルの対処法

連載 実用 BIND 9で作るDNSサーバ

　Linux Squareフォーラム サーバ構築・運用関連記事
連載：Heartbeatでかんたんクラスタリング（連載中）
オープンソースソフトウェアの「Heartbeat」を使ってHAクラスタを実現し、サービスを「落とさない」仕組みを実現します
特集：Apache 2.2でWebサイトをパフォーマンスアップ！
最新安定版Apache 2.2は、何が変わったのか？ 最新のApacheを新機能の使い方とともに解説する
連載：実用 Apache 2.0運用・管理術（全8回）
本連載では、Apache 2.0の運用や管理方法を解説する。まず必須設定と基本的なセキュリティ対策を行い今後の運用に備える
連載：実用 BIND 9で作るDNSサーバ（全15回）
本連載では、BIND 9の構築／運用方法を解説していく。実際に役立つことを目的に、セキュリティや大規模運用などのテーマを取り上げていく
連載：実用qmailサーバ運用・管理術（全14回）
本連載を通して、qmailによるメールサーバの高度な構築・運用・管理術を紹介。SPAM対策やML管理からサーバでのウイルスチェックなどまで
特集：Samba 3.0の全貌 改訂版
Samba 3.0リリースから8カ月。ここであらためて、Samba 3.0系列の新機能、インストール方法、国際化の現状を解説する

MONOist組み込み開発フォーラムの中から、Linux関連記事を紹介します

TechTargetジャパン

Linux Square フォーラム 新着記事

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

RSSフィード

＠IT 新着記事

キャリアアップ



- PR -
＠IT Sepcial
→ ＠IT Special ヘ

イベントカレンダー

PickUpイベント

- PR -
もっと見る
- PR -

お勧め求人情報

ホワイトペーパー（TechTargetジャパン）

＠IT Sepcial
→ ＠IT Special ヘ
ソリューションFLASH