djbdns でゾーンを設定するには、権威サーバーの tinydns に「ゾーンの起点（NS）とレコード」を登録して make で data.cdb を作り、社内向けのゾーンなら、キャッシュサーバーの dnscache にそのゾーンを tinydns に問い合わせるよう教える、という2か所の作業が必要です。この記事では、tinydns-conf が用意する add スクリプトを使ったゾーンの作り方、逆引きゾーンの扱い、dnscache の servers ディレクトリでの内部ゾーンの設定、反映と確認の方法を説明します。data ファイルの記号を1つずつ手で書く方法は扱わず、djbdns 付属の道具で安全に組み立てる流れに絞ります。
djbdns でゾーンが関わる2つの場所
djbdns は役割ごとに別のプログラムに分かれています。ゾーンの設定で関わるのは次の2つです。
- tinydns：自分が管理するゾーンについて答える権威サーバーです。設定は
root/dataというテキストファイルに書き、tinydns-dataでdata.cdbに変換してから読み込まれます。 - dnscache：端末からの問い合わせを受けて、ルートから順にたどって答えを探すキャッシュサーバーです。通常はゾーンの設定を持ちませんが、インターネットから見えない社内向けのゾーンを引かせたい場合は、そのゾーンの問い合わせ先を教える必要があります。
公開するドメインだけを扱うなら tinydns 側の作業で足ります。社内向けのゾーン（例：example.internal）を社内の端末から引けるようにしたい場合は、dnscache 側の作業も必要です。
この記事では、tinydns-conf でサービスを作成済みで、tinydns の作業ディレクトリが /etc/tinydns/root にある前提で進めます。インストールがまだの場合は、先にサービスを作成してください。
作業の前に
- djbdns 本体は長く新しい版が出ておらず、ディストリビューションによってはパッケージの収録状況やファイルの配置が異なります（2026年10月現在）。パスやコマンドは手元の環境に合わせて読み替えてください。
root/dataは作業前にコピーしておきます（例：cp data data.bak.$(date +%Y%m%d)）。makeで data.cdb を作り直すまで tinydns の応答は変わらないため、変更前の data があれば元に戻せます。- data ファイルを Git などで管理しておくと、いつ誰が何を変えたかを追えます。
- tinydns と dnscache は、同じ IP アドレスの 53番ポートを同時に使えません。両方を1台で動かす場合は、別々のアドレスで待ち受けさせます。この記事の例では、tinydns を 10.0.0.10、dnscache を 10.0.0.53 としています。
add スクリプトでゾーンを作る
tinydns-conf でサービスを作ると、root/ に data・Makefile のほか、add-ns・add-childns・add-host・add-alias・add-mx というスクリプトが作られます。これらは tinydns-edit を呼び出して data に行を追加するもので、書式の誤りを防げるのが利点です。
cd /etc/tinydns/root
# 1. ゾーンの起点を作る（SOA と NS。ネームサーバー名は a.ns.example.internal になる）
./add-ns example.internal 10.0.0.10
# 2. 逆引きゾーンの起点も作る（10.0.0.0/24 の逆引き）
./add-ns 0.0.10.in-addr.arpa 10.0.0.10
# 3. ホストを登録する（A と、逆引きの PTR が同時に作られる）
./add-host www.example.internal 10.0.0.20
./add-host db.example.internal 10.0.0.21
# 4. 同じアドレスに別名を付ける（A だけが作られ、PTR は作られない）
./add-alias intranet.example.internal 10.0.0.20
# 5. メールサーバーを登録する（MX と、a.mx.example.internal の A が作られる）
./add-mx example.internal 10.0.0.25
# 6. data.cdb を作り直す（ここで初めて応答に反映される）
makeadd-ns は、同じゾーンに2回目を実行すると、2台目のネームサーバーとして b.ns. の名前で追加します。セカンダリの tinydns を用意する場合は、そのアドレスで2回目を実行します。
add-host は、1つのアドレスに対して PTR が1つだけになるよう、同じアドレスでの2回目の登録を受け付けないことがあります。1つのアドレスに複数の名前を付けたいときは、代表の名前を add-host、残りを add-alias で登録するのが正しい使い分けです。
逆引きゾーンを先に作る理由
add-host で作られる PTR レコードは、tinydns がその逆引きゾーン（上の例では 0.0.10.in-addr.arpa）を担当していなければ、権威を持った答えとして返せません。手順2の add-ns を省くと、正引きは引けても逆引きが引けない状態になります。逆引きのゾーンを誰が管理しているか（自社か、回線事業者やクラウド事業者か）を確認し、自社の管理下にある範囲だけを登録してください。
add スクリプトで作れないレコード
add スクリプトと tinydns-edit が扱うのは、NS・A（と PTR）・MX が中心です。CNAME や TXT、SRV、AAAA などは data ファイルを直接編集して書きます。直接編集する場合も、変更前に data をコピーし、make の出力にエラーがないかを確かめる流れは同じです。
シリアル番号と TTL の考え方
add-ns で作るゾーンの起点の行には、SOA のシリアル番号を書きません。この場合、tinydns-data は data ファイルの更新日時をもとにシリアル番号を決めます。data を編集して make すれば番号が自動で増えるため、通常は意識する必要がありません。
注意が必要なのは、BIND などの別のサーバーをセカンダリにして、シリアル番号で更新を判断させている場合です。data を別のマシンからコピーして更新日時が古いまま残ると、シリアル番号が増えず、セカンダリが更新を取りに行かないことがあります。コピーには更新日時を変える方法を使うか、touch data してから make してください。
TTL は add スクリプトが既定の値で書き込みます。移行やアドレス変更を控えている場合は、data の該当行の TTL を短くしてから反映し、古い TTL の期間が過ぎてから実際の変更を行うと、切り替えが早く伝わります。
dnscache から内部ゾーンを引けるようにする
社内向けの example.internal は、インターネット上のどこにも委任されていません。そのため、dnscache がルートから順にたどっても見つからず、NXDOMAIN になります。dnscache に「このゾーンはこのサーバーに聞く」と教えるには、root/servers/ にゾーン名のファイルを作り、tinydns のアドレスを1行に1つずつ書きます。
cd /etc/dnscache/root/servers
# 正引きの内部ゾーン
echo 10.0.0.10 > example.internal
# 逆引きの内部ゾーン（社内のアドレスを逆引きさせる場合）
echo 10.0.0.10 > 0.0.10.in-addr.arpa
# dnscache は servers/ を起動時にだけ読むため、再起動して反映する
svc -t /service/dnscachednscache はこのファイルに書かれたサーバーを、そのゾーンの権威サーバーとして扱い、再帰を求めない問い合わせを送ります。tinydns はまさにそうした問い合わせに答えるサーバーなので、この組み合わせで動きます。ここに上流のキャッシュサーバー（再帰サーバー）のアドレスを書くと、意図どおりに動かないことがあるため、書くのは tinydns のアドレスにしてください。
既存の @ ファイル（ルートサーバーの一覧）は消したり書き換えたりしないでください。内部ゾーンのファイルを追加するだけで、ほかの名前の解決はこれまでどおりルートからたどります。
反映と確認
確認は、tinydns 単体、dnscache 経由の順に行うと、どちらに問題があるかを切り分けられます。
# 1. data.cdb の中身を直接引く（/etc/tinydns/root で実行。ネットワークを通さない）
tinydns-get a www.example.internal
# 2. tinydns に再帰なしで問い合わせる（権威を持った答えが返るか）
dnsq a www.example.internal 10.0.0.10
dnsq ptr 20.0.0.10.in-addr.arpa 10.0.0.10
# 3. dnscache 経由で引く（社内の端末が実際に使う経路）
dig @10.0.0.53 www.example.internal
dig @10.0.0.53 -x 10.0.0.201が答えない場合は data の内容か make に、1は答えて2が答えない場合は tinydns のサービスや待ち受けアドレスに、2は答えて3が答えない場合は dnscache の servers ファイルや再起動漏れに原因があります。3で答えが古いままなら、dnscache のキャッシュが残っている可能性があるため、TTL の経過を待つか dnscache を再起動します。
よくあるつまずき
- make でエラーが出る：tinydns-data は data に誤りがあると data.cdb を更新しません。その場合は以前の data.cdb のまま応答が続くので、エラーの行を直してから
makeし直します。 - ゾーン外の名前を登録した：
add-hostで、起点を作っていないゾーンの名前を登録しても、tinydns はそのゾーンについて答えません。先にadd-nsで起点を作ります。 - dnscache が NXDOMAIN を返す：servers のファイル名がゾーン名と一致しているか（末尾のドットは付けない）、dnscache を再起動したかを確認します。
- 社内の端末から dnscache に届かない：dnscache が問い合わせを受け付ける送信元は
root/ip/の設定で決まります。社内の範囲が登録されているかを確認します。
まとめ
- djbdns のゾーン設定は、tinydns への登録と、内部ゾーンなら dnscache への問い合わせ先の登録の2か所で行います。
- tinydns では add スクリプトでゾーンの起点とレコードを登録し、
makeで反映します。逆引きゾーンの起点も忘れずに作ります。 - CNAME や TXT などは data を直接編集します。いずれも作業前に data をコピーしておきます。
- dnscache には
root/servers/ゾーン名に tinydns のアドレスを書き、再起動して反映します。 - 確認は tinydns-get、dnsq、dnscache 経由の dig の順に行うと、原因の場所を絞り込めます。