2026年6月12日

djbdns から CoreDNS へ移行する手順｜tinydns のデータ変換から切り替えまで

DNS・名前解決

djbdns から CoreDNS への移行は、tinydns の data ファイルを標準のゾーンファイル（RFC 1035 形式）に変換し、CoreDNS の file または auto プラグインで同じ応答を返せることを確かめてから、ネームサーバーを切り替える流れで進めます。この記事では、移行対象の整理、data ファイルの変換、Corefile の書き方、応答の突き合わせ、切り替えと撤収の手順を説明します。

djbdns は長く更新が止まっているソフトウェアで、IPv6 や DNSSEC への対応は本体ではなく非公式のパッチに頼ってきました。CoreDNS は現在も開発が続いており（2026年10月現在）、設定が1つのファイル（Corefile）にまとまる点が移行先として選ばれる理由です。ただし、CoreDNS は djbdns の各機能をそのまま置き換えるものではないので、最初に役割を分けて考えます。

手順1：どの役割を移すのかを整理する

djbdns は複数のプログラムの集まりです。移行前に、今どれが動いているかを確認します。

tinydns：権威DNS。自分のゾーンに答えます。CoreDNS の file・auto プラグインで置き換えます。
axfrdns：tinydns のデータをゾーン転送（AXFR）で配る役です。CoreDNS では transfer プラグインが相当します。
dnscache：キャッシュサーバー（リゾルバー）。CoreDNS は forward と cache で外部の DNS へ転送できますが、ルートサーバーから自分で辿る再帰解決の機能は標準では持っていません。dnscache が自力で再帰解決している環境なら、Unbound などのリゾルバーへ移すほうが素直です。

/service/ や /etc/service/ 以下にどのサービスがあるか、svstat で何が動いているかを見れば、構成を把握できます。この記事では主に tinydns（と axfrdns）の移行を扱います。

手順2：tinydns の data ファイルを読む

tinydns のレコードは /service/tinydns/root/data に1行1レコードで書かれ、make（内部で tinydns-data）によって data.cdb に変換されて使われます。行頭の1文字が種類を表します。

# 例
.example.com:192.0.2.1:a:259200
=www.example.com:192.0.2.10:3600
+app.example.com:192.0.2.11:3600
@example.com:192.0.2.20:mx:10:3600
Cblog.example.com:www.example.com:3600
'example.com:v=spf1 mx -all:3600

主な対応関係は次のとおりです。

.：SOA と NS、ネームサーバーの A をまとめて作ります。3つ目の欄にドットを含まない名前を書くと、a.ns.example.com のような名前が自動で作られる点に注意します。
&：NS（サブドメインの委任）
=：A と、対応する逆引き PTR を同時に作ります
+：A のみ
@：MX（ドットを含まない名前は mx.example.com のように展開されます）
C：CNAME、'：TXT、^：PTR、Z：SOA を個別に指定
:：任意の型を数値と生データで書く汎用形式。AAAA を本体の djbdns で扱う場合はこの形式で書かれていることが多いです
%：送信元の IP アドレスによって答えを変える「ロケーション」の定義

TXT や汎用形式では、特殊な文字が \052 のような8進数で表記されています。変換時にはこれを元の文字やバイトに戻す必要があります。

手順3：ゾーンファイルに変換する

変換の方法はおもに2つあります。

方法A：axfrdns から AXFR で取り出す

axfrdns が動いている、または一時的に動かせるなら、ゾーン転送で RFC 1035 形式の出力を得るのが手堅い方法です。tinydns-data の展開規則（自動で作られる名前や PTR）を tinydns 自身が解釈した結果が得られるため、自前の変換で読み違えるおそれが減ります。

# axfrdns の tcp ルールで、作業用ホストからの AXFR を許可しておく（作業後に戻す）
dig @192.0.2.1 example.com AXFR +nocmd +nostats > example.com.zone.raw

取り出した結果には先頭と末尾に同じ SOA が2回現れるので、末尾の1件を削除してからゾーンファイルとして使います。axfrdns の許可は作業用ホストだけに絞り、作業が終わったら元に戻してください。

方法B：data ファイルを変換するスクリプトを使う

axfrdns を使えない場合は、data の各行をゾーンファイルの書式に書き換えます。公開されている変換スクリプトもありますが、対応している行の種類や8進数表記の扱いはまちまちです。どちらの方法でも、次の点は手で確認します。

シリアル番号：tinydns-data は、シリアルを省略すると data ファイルの更新時刻から自動で作ります。CoreDNS の file はシリアルが変わったときにゾーンを読み直すため、移行後はゾーンを編集するたびにシリアルを上げる運用に変わります。日付と連番の形式（例：2026101801）に揃えておくと管理が楽です。
**ロケーション（% 行）**：AXFR や単純な変換では、送信元ごとに答えを変える情報は表現できません。手順4で別途設定します。
TTL と時刻指定：tinydns の行には、指定時刻以降に有効になる、または失効するレコードを書く欄があります。CoreDNS に同じ仕組みはないため、該当する行があれば運用で置き換えます。

変換したファイルは、CoreDNS とは別に BIND の named-checkzone や ldns-read-zone などで文法を確認しておくと、読み込みエラーの原因を早く特定できます。

手順4：Corefile を書く

ゾーンが少ない場合は file で1つずつ書きます。

example.com {
    file /etc/coredns/zones/example.com.zone
    errors
    log . {
        class denial error
    }
}

ゾーンが多い場合は、ファイル名の規則で読み込む auto が便利です。

. {
    auto {
        directory /etc/coredns/zones db\.(.*) {1}
    }
    errors
}

tinydns のロケーション機能で社内と社外に別の答えを返していた場合は、view プラグインで送信元によってサーバーブロックを選び分けます。

example.com {
    view internal {
        expr incidr(client_ip(), '10.0.0.0/8')
    }
    file /etc/coredns/zones/internal/example.com.zone
}

example.com {
    file /etc/coredns/zones/example.com.zone
}

view は比較的新しいプラグインなので、手元の版に含まれているかを coredns -plugins で確認してください。axfrdns でセカンダリへ配っていた場合は、ゾーンのブロックに transfer { to 198.51.100.2 } のように配信先を書きます。

dnscache の役割も CoreDNS に寄せる場合は、問い合わせ元を acl プラグインで自組織のネットワークに限ります。誰からの問い合わせにも答えるオープンリゾルバーは、増幅攻撃の踏み台になります。

手順5：応答を突き合わせる

切り替える前に、新旧のサーバーが同じ答えを返すかを機械的に比べます。data ファイルにある名前と型の一覧を作り、両方に問い合わせて差分を取ります。

# names.txt には「名前 型」を1行ずつ書く
while read -r name type; do
  a=$(dig +short @192.0.2.1 "$name" "$type" | sort)
  b=$(dig +short @192.0.2.53 "$name" "$type" | sort)
  [ "$a" = "$b" ] || echo "DIFF: $name $type"
done < names.txt

SOA のシリアルは変わるので、差分から除外して考えます。ほかに差が出やすいのは、自動で作られていた PTR や NS の名前、TXT の文字の扱い、ワイルドカードの挙動です。差分がなくなるまで、ゾーンファイルを修正します。

手順6：切り替えと撤収

TTL を下げておく：切り替えの数日前に、NS や主要なレコードの TTL を短くします。tinydns 側で TTL を変え、元の TTL の時間が過ぎるのを待ちます。
切り替える：新しいサーバーを同じ IP アドレスで引き継ぐか、登録事業者（親ゾーン）の NS とグルーレコードを新しいサーバーに向けます。IP を変える場合は、ゾーン内の NS と A も合わせて更新します。
並行稼働：親ゾーンの NS の TTL が切れるまでは旧サーバーにも問い合わせが届くため、tinydns は止めずに、同じ内容で動かし続けます。この期間はレコードを変更しないのが安全です。
撤収：旧サーバーへの問い合わせが途絶えたことをログで確認してから、djbdns のサービスを止めます。data ファイルと data.cdb は、しばらく保管しておきます。

移行後の運用で変わること

ゾーンを編集したら、シリアルを上げます。上げ忘れると CoreDNS は変更を読み込みません。
reload プラグインを入れると Corefile の変更が自動で読み込まれますが、文法の誤りがあると反映されないため、errors の出力を確認します。
DNSSEC を導入する場合は、署名の方式と親ゾーンへの DS 登録の順序を事前に決めておきます。

まとめ

djbdns の tinydns・axfrdns・dnscache のうち、何を移すかを最初に分けます。再帰解決が必要なら CoreDNS 以外のリゾルバーも検討します。
data ファイルは axfrdns の AXFR か変換スクリプトでゾーンファイルにし、シリアル・ロケーション・時刻指定は手で補います。
Corefile では file か auto でゾーンを読み込み、ロケーションは view で再現します。
切り替え前に新旧の応答を一覧で突き合わせ、TTL を下げてから NS を切り替え、旧サーバーはしばらく並行稼働させます。