DHCPとDynamic DNSの連携システム：実用 BIND 9で作るDNSサーバ（8）（2/2 ページ）

» 2003年08月05日 00時00分公開

TSIG認証によるセキュリティ

　nsupdate同様、ソースIPアドレスによる制限だけでは心もとないため、TSIG認証（注）を導入します。手順は第7回同様に行い、DHCP側での鍵の指定はdhcpd.conf中で行います。

注：dnssec-keygenやTSIGについては、第5回も参照。

マスター・ゾーンサーバ側の設定

　まず、マスター・ゾーンサーバで共有鍵の生成を行います。

# /usr/sbin/dnssec-keygen -a HMAC-MD5 -b 512 -n HOST example.jp



Kexample.jp.+157+01798.key

Kexample.jp.+157+01798.private



$ more Kexample.jp.+157+01798.key

example.jp. IN KEY 512 3 157 1GPx/sFNPz40U/NuspDqo……（省略）

　生成されたファイルから共有鍵を抜き出し、named.confに埋め込みます。

key "example.jp" {

      algorithm hmac-md5;

      secret "1GPx/sFNPz40U/NuspDqo……（省略）";

};



zone "example.jp" {

        type master;

        file "example.zone";

        allow-update{

                key example.jp;

        };

};

zone "1.168.192.in-addr.arpa" {

        type master;

        file "example.rev";

        allow-update{

                key example.jp;

        };



};

/etc/named.conf

DHCPサーバ側の設定

key "example.jp" {

      algorithm hmac-md5;

      secret "1GPx/sFNPz40U/NuspDqo……（省略）";

};



zone example.jp. {

        primary 10.0.0.10;

        key example.jp;

}



zone 1.168.192.in-addr.arpa. {

        primary 10.0.0.10;

        key example.jp;

}

/etc/dhcpd.conf追加分

　以上で設定は終了です。named、dhcpdともに再起動し、動作を確認しましょう。

登録されるホスト名とFQDN

　DNSに登録されるホスト名は、クライアントから渡されるものを使用すると前述しました。それでは、同じホスト名が設定されたクライアントが複数存在する場合はどうなるでしょう。または、1台のマスター・ゾーンサーバに対して複数のDHCPサーバからupdate要求が行われるとどうなるでしょう。

　これらの場合、クライアントAのためのゾーン情報が、クライアントBによって上書きされたり削除されることが懸念されます。そこで、DHCPサーバはクライアントの情報を基にHASH値を生成し、TXTレコードとして埋め込みます。以降の更新にはこのHASH値の確認が必要になり、その過程は/var/log/messagesでうかがうことができます。また、サーバ側でホスト名を指定することもできます。

host bbb { hardware ethernet XX:XX:XX:XX:XX:XX; ddns-hostname "クライアントのホスト名"; }

#特定のクライアントのMACアドレスにホスト名を指定した場合



ddns-hostname = binary-to-ascii (16, 8, "-", substring (hardware, 1, 6));

#MACアドレスを基に機械的にホスト名を指定する場合（例：0-80-98-b0-XX-XX.example.jp）

/etc/dhcpd.conf追加分

　クライアントから、ホスト名でなくFQDNが渡される場合もあります。FQDNにDHCPサーバが想定していないドメインが付随していることも考えられます。DHCPサーバ側では、以下の2つのモードでFQDNを処理可能です。

ignore client-updates;

#FQDNの最左からホスト名を取り出し、ドメイン部はDHCPサーバで指定しているものを使用



allow client-updates;

#FQDNから更新すべきドメインを拾い出し、そのドメインに対するマスター・ゾーンサーバを見つけてupdateを行う（注）

/etc/dhcpd.conf追加分
注：この設定を有効にした場合、クライアントがホスト名しか送ってこない場合は正引きのAレコードは登録されず、逆引きのPTRだけ登録されます。

DHCPサーバに依存しないDynamic DNSの実現

　DHCPサーバが自由にできる環境であればこれまでに紹介した方法が利用できますが、多くの場合DHCPサーバはプロバイダのものであったり、そもそもDHCPではなくPPPoEやPPPを利用しているケースもあることでしょう。

　こうした環境にDynamic DNSが付加できれば、動的に与えられたIPアドレスをいちいち直打ちする必要はなくなります。その手順を自動化できれば、不意なプロバイダとの切断で新しいアドレスが割り当てられた場合に、即座にDNS Updateを実施できます。以下では、簡単なPerlスクリプトを使った自動化の手順を紹介します。

図3　ホームサーバをゾーン情報に登録

クライアント／サーバプログラムの作成

サーバ側
　server.pl（漢字コードEUC）
　hosts.key
クライアント側
　client.pl（漢字コードEUC）

　ここでは図4のようなネットワークを想定しています。プロバイダから付与されたただ1つのIPアドレスを静的IPマスカレード（注）を用いて、特定のポートに来たIPパケットを指定されたプライベートネットワーク内のサーバに転送しています。

注：多くのブロードバンドルータでは「仮想サーバ」の名称で呼ばれています。Apacheなどで利用されるバーチャルドメインサーバとは本質的に異なるものです。

　このサーバに、外部からhome.example.jpで接続できるようにDynamic DNSを利用します。しかし、ローカルサーバにグローバルアドレスが直接振られる場合は割り当てられたグローバルアドレスを簡単に取得できますが、静的IPマスカレードを使用している状況では、ルータに振られたグローバルアドレスを何らかの手段で知る必要があります。そこで次のような仕組みを考えます。

図4　クライアント／サーバプログラムの導入

　この例では、クライアント／サーバ方式を採用しています。nsupdateはnamedが起動しているサーバ内で実行させることにし、そのための要求待ち受けプログラムと、外部からnsupdateを実行させるクライアントスクリプトの2つを用意します。

　クライアント／サーバ方式を使用することで、クライアントのソースIP、それもルータに付与されたIPアドレスをサーバ側で検出できます。NAT内から送信されたIPパケットは、ルータ内でソースアドレスをグローバルIPに書き換えるため、サーバ側は容易に必要なIPアドレスを知ることができます。

クライアント／サーバプログラムの内容

　クライアント側はわざわざスクリプトを作成するまでもなく、telnetコマンドで直接サーバと対話することも可能ですが、crontabなどで定期的に実行させることも考えてスクリプト化しました。

client.pl

$ ./client.pl $host $password $server ($port)

　$host：登録したいFQDNホスト名
　$password：サーバに登録されているキー（平文）
　$server：送信先
　$port：サーバ側の待ち受けポート番号（省略時は5103）

・平文パスワードとランダムに生成した2文字（$salt）からCRYPT暗号キー（$crypt）を生成
・socketを使用し、サーバに下記の文字列を送信

DDNS $host $crypt $salt\r\n

QUIT\r\n

↓

DDNS $host $crypt $salt\r\n

QUIT\r\n

↓

（TCP $portで待ち受け）

client.pl

$./server.pl ($port)

　$port：サーバ側の待ち受けポート番号（省略時は5103））

・受け取った文字列がDDNSで始まっているかを確認。QUITであればclose
・文字列から$host、$crypt、$saltを抽出し、$saltとhost.key中の平文キーでCRYPT暗号キーを作成し、$cryptと一致しているか確認
・送信文字列からソースIP（$client_ip）を検出
・$host、$update_serverの結果と$client_ipを比べて、2重登録にならないことを確認
・/tmpに作業ファイルADDFILEを作成し、下記のようなnsupdate流し込みファイルを作成

　 server $update_serve update delete $host update add $host $ttl IN A $client_ip \n

・$nsupdate ADDFILEを実行

図5　クライアント／サーバプログラムの内容

　クライアント側に用意するファイルはclient.plのみです。必要な情報はプログラムへの引数で指定します。サーバ側にはserver.plとhost.keyファイルを用意します。

　host.keyファイルには、あらかじめ登録が予想されるホスト名と一意なキーを空白文字で区切って記述します。ここで指定したキーは、クライアントとサーバ間での認証に使用されます。認証にはCRYPT暗号を利用し、平文キーを垂れ流さないようにささやかな配慮を実施しています。

　サーバは要求が正当なものであることを確認した後、同じゾーン情報を複数回登録しないように、update前に同じレコードが登録されていないか否かを確認します。登録されていなければnsupdateを実行します。この際に、同じレコードがなくても、古い情報（以前に割り当てられていたIP）で登録されていることを考慮し、事前にレコードの削除を行います。ホスト名に対しては、Aレコードを1つに限定しています。

　プログラムの詳細については、ファイル中のコメント行を参照してください。

クライアント／サーバプログラムの実行例

　サーバスクリプトは、マスター・ゾーンサーバに置きます。DNSサーバにとってはlocalhostからnsupdateが実行されることになるため、named.confの指定は次のようになります。

zone "example.jp" {

        type master;

        file "example.zone";



        ### update 許可###

        allow-update{

                localhost;  #BIND既定義のACL「localhost」を使用

        };

}

named.conf追加分

　named.confの設定を有効にした後、server.plとhost.keyを任意のディレクトリに展開します。2つのファイルは同じディレクトリに置きますが、何らかの理由でhost.keyファイルを移動せざるを得ない場合は、server.plの10行目にある$key_fileを修正します。次に、host.keyファイルにDNSへの登録が予想されるホスト名のFQDNと、それに対するキーを記述します。

FQDNホスト名認証キー

host.keyファイル。FQDNホスト名と認証キーの間は空白文字で区切る

　では、サーバ側スクリプトを実行します。server.plに適切な実行権を設定するか、次のように実行します。

$ perl ./server.pl

　次にクライアント側でスクリプトを実行します。特に準備は必要ありません。先ほどサーバ側で設定したホスト名とキーを使用し、client.plを次のように実行します。

$ perl ./client.pl ホスト名キーサーバ (port)

　登録がうまくいっているかどうか、digやhostコマンドで確認しましょう。

　実際に使用する場合は、BIND側のupdate-policyを厳しくしたりPREREQ指定を行ってDNS Updateの手続きを複雑にするなど、安全性を考慮した修正を適宜加えてください。

フリーのDynamic DNSサービス

　独自ドメインを所有し、DNSサーバを運用されている方も多いと思いますが、中にはDynamic DNSをキーワードにして検索し、このページを見つけた方もいるでしょう。

　Dynamic DNSの利用にDHCPサーバは必須ではありませんが、DNS Updateに対応したDNSサーバが必要になります。ホームサーバを利用するために、わざわざドメインを取ってDNSサーバを立ち上げるのも面倒です。そこで、有料／無料で提供されているDynamic DNSサイトを利用します。サイトによっては、持ち込んだドメインでサービスを利用したり、メールサーバはサイトのものが利用できるなどの特典があります。

　こうしたサービスではnsupdateなど標準のBINDツールではなく、独自のクライアントソフトやWebインターフェイスが提供されており、登録するレコードのTTL設定値や個数に制限があるため、サービス選択の際は十分に吟味しましょう。

　以上、2回にわたりDynamic DNSについて紹介しました。

　IPアドレスの割り当てがDHCPなど動的な方法が主流になるにつれ、Dynamic DNSの用途は今後も増していくことが予想されます。BINDでは比較的簡単な作業でDynamic DNSが利用できることがお分かりいただけたと思います。

　とはいえ、いきなり運用環境に実装するのではなく、テスト環境を用意して各クライアントやサーバの挙動を確認することをお勧めします。数台のPCで箱庭環境を作ってしまえば、Dynamic DNSのテストに限らず、さまざまな利用方法があるはずです。

「次回」へ

「実用 BIND 9で作るDNSサーバ」バックナンバー