2026年6月9日

MaraDNS でセカンダリ構成する手順｜zoneserver でのゾーン転送と fetchzone での取り込み

DNS・名前解決

MaraDNS でプライマリ・セカンダリの2台構成を作る方法は、MaraDNS がどちらの役になるかで変わります。MaraDNS がプライマリなら、付属の zoneserver でゾーン転送（AXFR）を許可し、BIND や NSD などのセカンダリに取りに来てもらいます。MaraDNS をセカンダリにしたい場合、maradns 本体にはゾーン転送を自動で受け取る機能がないため、付属の fetchzone を定期実行してゾーンファイルを取り込み、MaraDNS を再起動する形で組みます。この記事では、3つの構成の選び方と、それぞれの設定・確認方法を説明します。

設定項目の名前やツールの使い方は版によって異なることがあるため、手元の版のマニュアル（man mararc、man fetchzone など）と照らし合わせてください。以下は執筆時点の情報です（2026年10月現在）。作業前には mararc とゾーンファイルをバックアップしておきます。

どの構成にするかを決める

構成1：MaraDNS がプライマリ、ほかのソフトがセカンダリ。zoneserver を動かし、セカンダリからの AXFR を許可します。セカンダリ側はゾーン転送の機能を標準で持つ BIND・NSD・Knot DNS などを使えるので、もっとも一般的な形です。
構成2：ほかのソフトがプライマリ、MaraDNS がセカンダリ。fetchzone でゾーンを取得し、csv2 ファイルとして保存して MaraDNS を再起動します。
構成3：2台とも MaraDNS で、ファイルを同期する。ゾーン転送を使わず、プライマリのゾーンファイルを rsync などでもう1台に配り、両方を再起動します。厳密には「2台のプライマリ」ですが、仕組みが単純で、MaraDNS どうしならいちばん扱いやすい方法です。

どの構成でも、2台のネームサーバーは別のネットワーク（できれば別の事業者やデータセンター）に置き、片方の障害でもう片方が巻き込まれないようにします。

構成1：zoneserver でセカンダリにゾーンを渡す

MaraDNS 本体（maradns）は UDP の問い合わせだけを扱い、TCP の問い合わせとゾーン転送は zoneserver という別のプログラムが担当します。zoneserver は mararc を読んで動くので、転送を許可する相手を mararc に書きます。

# /etc/mararc（プライマリ側）
ipv4_bind_addresses = "192.0.2.1"
chroot_dir = "/etc/maradns"
csv2 = {}
csv2["example.com."] = "db.example.com"

# ゾーン転送を許可するセカンダリのアドレス
zone_transfer_acl = "198.51.100.2/32"

zoneserver を起動（または再起動）し、ファイアウォールで TCP の 53 番をセカンダリから受けられるようにします。設定できたら、セカンダリのサーバー上でゾーン転送を試します。

# セカンダリ（198.51.100.2）で実行
dig @192.0.2.1 example.com AXFR

ゾーンの全レコードが表示されれば成功です。Transfer failed などと出る場合は、zone_transfer_acl のアドレス、zoneserver が動いているか、TCP の 53 番が通るかの順に確認します。

セカンダリ側の設定は、たとえば BIND なら次のようになります。

zone "example.com" {
    type secondary;
    primaries { 192.0.2.1; };
    file "/var/cache/bind/db.example.com";
};

古い BIND では type slave; と masters という書き方になります。

変更が伝わるタイミングに注意する

BIND どうしの構成では、プライマリが変更を NOTIFY で知らせ、セカンダリがすぐに取りに来ます。MaraDNS はこの通知を送らない前提で考えておくのが安全で、その場合セカンダリは SOA の refresh の間隔ごとにシリアルを確かめ、上がっていれば取り直します。

レコードを変えたら、SOA のシリアルを上げてから MaraDNS（と zoneserver）を再起動します。シリアルが同じだと、セカンダリは変更に気づきません。
変更を早く伝えたい場合は、SOA の refresh を短めにするか、セカンダリ側で手動の取り直し（BIND なら rndc refresh example.com）を実行します。
SOA の expire は、プライマリと連絡が取れなくなってからセカンダリが答えるのをやめるまでの時間です。短すぎると、プライマリの短い停止でセカンダリまで答えなくなります。

MaraDNS のゾーン転送は IP アドレスによる制限が中心です。TSIG のような署名による認証を前提にできないため、zone_transfer_acl は必要なアドレスだけに絞り、ファイアウォールでも同じ制限をかけます。

構成2：fetchzone で MaraDNS をセカンダリにする

fetchzone は、指定したサーバーからゾーン転送でゾーンを取得し、csv2 形式で標準出力に書き出すツールです。プライマリ側では、MaraDNS のサーバーからの AXFR を許可しておきます。

fetchzone example.com 192.0.2.1 > /tmp/db.example.com.test

取得したファイルの中身を確認できたら、定期実行のスクリプトにします。ポイントは、取得に失敗したときに既存のファイルを上書きしないこと、内容が変わったときだけ再起動することです。

#!/bin/sh
# /usr/local/sbin/maradns-fetch.sh（cron で定期実行する例）
set -eu
ZONE=example.com
PRIMARY=192.0.2.1
DIR=/etc/maradns
TMP=$(mktemp "$DIR/.db.$ZONE.XXXXXX")

if fetchzone "$ZONE" "$PRIMARY" > "$TMP" && grep -q 'SOA' "$TMP"; then
  if cmp -s "$TMP" "$DIR/db.$ZONE"; then
    rm -f "$TMP"
  else
    chmod 644 "$TMP"
    mv "$TMP" "$DIR/db.$ZONE"
    systemctl restart maradns
  fi
else
  rm -f "$TMP"
  logger -t maradns-fetch "fetch failed: $ZONE from $PRIMARY"
  exit 1
fi

この形には、本物のセカンダリと違う点が2つあります。

変更の反映は定期実行の間隔しだい：NOTIFY を受けて即座に取り直す仕組みではないため、cron の間隔（例：15分ごと）が反映までの遅れになります。
プライマリが止まっても古い内容で答え続ける：SOA の expire で自動的に答えるのをやめる仕組みはありません。取得の失敗を logger の出力や監視で拾い、長く続いたら人が判断します。

取得のたびに出力の細部が変わり、内容が同じでも再起動が繰り返される場合は、cmp の代わりに SOA のシリアルだけを比べる形に変えます。サービスのユニット名（maradns の部分）は導入方法によって異なるので、手元の環境に合わせてください。

構成3：MaraDNS どうしでファイルを同期する

2台とも MaraDNS なら、ゾーン転送を使わずにファイルを配る方法が単純です。プライマリでゾーンファイルを編集し、SSH 経由の rsync でもう1台に送り、両方の MaraDNS を再起動します。

# プライマリで実行する例（鍵認証の SSH を用意しておく）
rsync -av /etc/maradns/ ns2.example.com:/etc/maradns/
ssh ns2.example.com 'systemctl restart maradns'
systemctl restart maradns

mararc も同じ内容にそろえておけば、どちらのサーバーも同じゾーンに答えます。手作業で配ると片方だけ古くなりやすいので、スクリプトや構成管理ツールにまとめ、配布前に検証用サーバーで起動を確かめる手順を挟みます。

2台が同じ内容で答えているかを確認する

どの構成でも、最後に両方のサーバーの SOA シリアルを比べます。

for s in 192.0.2.1 198.51.100.2; do
  printf '%s ' "$s"; dig +short +norec @"$s" example.com SOA
done

シリアルがそろっていれば、同じ版のゾーンで答えています。あわせて、ゾーン内の NS レコードと、登録事業者に登録したネームサーバーの両方に2台が含まれているかも確認します。片方にしか書いていないと、問い合わせが1台に偏ったり、セカンダリが使われなかったりします。

まとめ

MaraDNS がプライマリなら、zoneserver と zone_transfer_acl でセカンダリからのゾーン転送を許可します。通知に頼らず、シリアルを上げて SOA の refresh で取りに来てもらう前提で考えます。
MaraDNS をセカンダリにするなら、fetchzone を定期実行し、取得に失敗したら上書きしない、変わったときだけ再起動するスクリプトで組みます。
2台とも MaraDNS なら、ファイルを同期して両方を再起動する方法がもっとも単純です。
最後に2台の SOA シリアルと、ゾーン内・登録事業者の NS の登録を確認します。