MaraDNS の応答を速くしたいときは、まず権威サーバーの maradns と、再帰問い合わせを担う Deadwood のどちらが遅いのかを切り分けます。MaraDNS は小さく単純な作りのソフトで、調整できる項目はそれほど多くありません。効果が出やすいのは、役割ごとにプロセスとアドレスを分けること、Deadwood のキャッシュ件数を増やして再起動後もキャッシュを引き継ぐこと、ログを減らすこと、そして1台で足りなければ台数を増やすことです。この記事では、計測の方法と、それぞれの調整の考え方を説明します。
設定項目の名前や既定値は版によって異なることがあるため、手元の版のマニュアル（man mararc、man Deadwood、配布物の doc ディレクトリ）と照らし合わせてください。以下は MaraDNS 3.x 系を前提にした、執筆時点の情報です（2026年10月現在）。設定を変える前には mararc・dwood3rc・ゾーンファイルをバックアップし、検証環境で確かめてから本番に入れます。
MaraDNS の構成を確認する
MaraDNS 2.0 以降は、役割ごとに別のプログラムに分かれています。
- maradns：権威サーバーです。mararc の
csv2で指定したゾーンに UDP で答えます。 - zoneserver：TCP の問い合わせとゾーン転送を担当します。
- Deadwood：再帰問い合わせとキャッシュを担当するリゾルバです。設定ファイルは dwood3rc です。
どれが遅いかによって、見る場所が変わります。自分のゾーンへの問い合わせが遅いなら maradns、外部ドメインの名前解決が遅いなら Deadwood、大きな応答や TCP の問い合わせだけが遅いなら zoneserver です。まずはこの切り分けから始めます。
計測する
応答時間を見る
dig の出力にある Query time で、1件ごとの応答時間を確認できます。
# 権威サーバー（maradns）に自分のゾーンを問い合わせる
dig @192.0.2.1 www.example.com A +norec
# Deadwood に外部ドメインを2回問い合わせる（2回目はキャッシュから）
dig @127.0.0.1 www.example.org A
dig @127.0.0.1 www.example.org ADeadwood で2回目が速くなっていれば、キャッシュは働いています。1回目だけが遅いのは、上流や権威サーバーへの問い合わせの時間なので、Deadwood の設定より回線や上流の応答の影響が大きい部分です。
負荷をかけて比べる
設定の効果を比べるには、DNS-OARC の dnsperf などで同じ条件の負荷をかけます。
dnsperf -s 192.0.2.1 -d queries.txt -l 30あわせて top や pidstat で、maradns・Deadwood の CPU 使用率を見ます。1つのプロセスが CPU 1コアを使い切っている状態なら、そのプロセスが上限に達しています。本番サーバーへの負荷試験はサービスに影響するため、検証用のサーバーで行います。
役割ごとにアドレスを分ける
権威サーバーとリゾルバを同じアドレスで兼ねることはできないため、maradns と Deadwood は別のアドレス（またはループバックと外向きのアドレス）で待ち受けます。性能の面でも、2つを分けておくと、外部ドメインの名前解決が増えたときに自分のゾーンの応答まで遅くなる、という影響を避けられます。
# /etc/mararc（権威サーバー：外向きのアドレス）
ipv4_bind_addresses = "192.0.2.1"
chroot_dir = "/etc/maradns"
csv2 = {}
csv2["example.com."] = "db.example.com"# /etc/dwood3rc（リゾルバ：内部向け）
bind_address = "127.0.0.1"
recursive_acl = "127.0.0.1/8"
chroot_dir = "/etc/deadwood"負荷が大きく、両方を同じサーバーに置くと CPU を取り合う場合は、リゾルバを別のサーバーに移すことも考えます。
Deadwood のキャッシュを調整する
Deadwood はキャッシュに入った応答を返すことで速くなります。キャッシュに保存できる件数は maximum_cache_elements で決まり、既定値は小規模な用途向けの控えめな値です。利用者や問い合わせの種類が多い環境では、この値を引き上げるとヒット率が上がります。
# /etc/dwood3rc（抜粋・値は例）
maximum_cache_elements = 60000
cache_file = "dw_cache_bin"件数を増やすとそのぶんメモリを使うので、値を上げたあとは Deadwood のメモリ使用量（ps の RSS など）を確認し、サーバーのメモリに余裕があるかを見ます。
cache_file を設定すると、Deadwood はキャッシュをファイルに保存し、次の起動時に読み込みます。再起動のたびにキャッシュが空になり、しばらく応答が遅くなる、という状態を和らげられます。ファイルの置き場所は chroot_dir からの相対パスになる点と、Deadwood の実行ユーザーが書き込めるかどうかに注意します。
上流のリゾルバに問い合わせを回す構成（upstream_servers を使う構成）では、上流の応答速度がそのまま1回目の問い合わせの時間になります。遅い場合は、上流をネットワーク的に近いものに変えるか、ルートから自分で再帰する構成（root_servers）と比べてみます。
maradns（権威サーバー）を調整する
maradns はゾーンを起動時にメモリに読み込んで答えるため、問い合わせの処理そのものは軽く、調整の余地はあまり大きくありません。気をつけたいのは次の点です。
- ゾーンが大きいと起動に時間がかかる：レコード数の多いゾーンは、読み込みに時間がかかります。ゾーンの変更を反映するには再起動が必要なので、頻繁に再起動するとそのたびに応答が止まる時間が生まれます。変更はまとめて行い、2台以上で順番に再起動します。
- 大きな応答は TCP に回る：UDP に収まらない応答は切り詰められ、クライアントは TCP で問い合わせ直します。TCP は zoneserver が受けるため、TXT レコードが多いゾーンなどでは zoneserver も動かしておき、ファイアウォールで TCP 53 番を通しておきます。
ログの量を減らす
mararc と dwood3rc のどちらにも、ログの詳しさを決める verbose_level があります。調査のために値を上げたまま運用すると、問い合わせのたびにログを書くことになり、負荷とディスク使用量が増えます。
verbose_level = 1普段は低い値にしておき、トラブルの調査中だけ一時的に上げて、終わったら戻します。ログを systemd の journal や syslog に送っている場合は、そちらの保存量の設定もあわせて確認します。
1台で足りないときは台数を増やす
MaraDNS は1つのプロセスで処理する作りなので、CPU のコア数を増やしても1プロセスの処理能力はあまり伸びません。負荷が上限に達したら、台数を増やして分散させるのが現実的です。
- 権威サーバーは、同じゾーンファイルを複数台に配り、NS レコードに並べて分散させます。ファイルの配布は rsync や構成管理ツールで自動化しておきます。
- リゾルバ（Deadwood）は、クライアントに複数のアドレスを配ります。
MaraDNS は現在も作者による更新が続いていますが、開発の規模は小さく、更新の頻度も高くありません。大規模な権威サーバーやリゾルバとして性能を求める場合は、NSD・Knot DNS（権威）や Unbound（リゾルバ）への移行を比べる価値もあります。
まとめ
- まず maradns・zoneserver・Deadwood のどれが遅いのかを、
digの応答時間と CPU 使用率で切り分けます。 - 権威サーバーとリゾルバは別のアドレス（必要なら別のサーバー）に分け、互いの負荷の影響を避けます。
- Deadwood は
maximum_cache_elementsでキャッシュ件数を増やし、cache_fileで再起動後もキャッシュを引き継ぎます。 verbose_levelは普段は低くし、1台で足りなければ台数を増やして分散させます。