2026年6月14日

2026年6月14日

MaraDNS をインストールする手順|付属の Deadwood を社内向けのキャッシュDNSとして動かすまで

MaraDNS の配布物には、権威サーバーの maradns のほかに、キャッシュと再帰問い合わせを担当する Deadwood が含まれています。社内のパソコンやサーバーが使う名前解決用の DNS(キャッシュDNS)が欲しい場合は、MaraDNS をインストールして Deadwood だけを動かせば足ります。この記事では、Deadwood を社内向けのキャッシュDNSとして使う前提で、インストール、設定ファイル /etc/dwood3rc の最小構成、利用者の制限、systemd での起動、動作確認、クライアント側の設定までを説明します。

内容は MaraDNS 3.5 系に含まれる Deadwood 3 系を前提にしています(2026年10月現在)。設定項目の名前や既定値は版によって変わることがあるため、配布物に含まれる Deadwood のマニュアルと照らし合わせてください。

Deadwood を選ぶ前に知っておきたいこと

Deadwood は小さく、設定項目が少ないキャッシュDNSです。家庭や小さな事務所、検証環境のキャッシュDNSには扱いやすい一方で、次の点は事前に確認しておきます。

  • DNSSEC の検証を行いません。応答が改ざんされていないかを DNSSEC で検証したい場合は、Unbound や Knot Resolver などの検証に対応したリゾルバーを選びます。
  • 社内のゾーンを自分で持つ機能は限られます。社内向けの名前を細かく管理したい場合は、権威サーバー(maradns など)を別に動かし、Deadwood からそこへ問い合わせる構成にします。
  • インターネット全体に公開しないこと。だれでも使えるキャッシュDNS(オープンリゾルバー)は、DNS の増幅攻撃の踏み台に使われます。利用者は社内のネットワークに限ります。

インストールする

ディストリビューションによっては MaraDNS や Deadwood のパッケージが用意されていますが、版が古いことがあります。パッケージの版と、公式サイト(maradns.samiam.org)で配布されている最新版を比べ、古すぎる場合はソースからビルドします。

# ビルドに必要なもの(Debian / Ubuntu の例)
sudo apt install build-essential
# RHEL 系の例
sudo dnf install gcc make

ソースのファイル名の版番号は、その時点の最新版に置き換えてください。配布元で署名やハッシュ値が案内されている場合は、展開前に照合します。

tar xf maradns-3.5.XXXX.tar.xz
cd maradns-3.5.XXXX
./configure
make
sudo make install

# どこに入ったかを確認する(後の systemd の設定で使う)
command -v Deadwood maradns askmara

Deadwood のプログラム名は大文字の D で始まる Deadwood です。make install で入らない場合は、ソースツリーの中の Deadwood のディレクトリでビルドされたものを使います。すでに /etc/dwood3rc がある環境では、インストールで上書きされないか確認し、事前にコピーを取っておきます。

専用ユーザーと作業用ディレクトリを作る

Deadwood は root で起動して53番ポートを開いた後、設定したユーザー ID に権限を下げ、指定したディレクトリに閉じこもって(chroot して)動きます。ログインできない専用ユーザーと、キャッシュを保存するディレクトリを用意します。

sudo useradd --system --no-create-home --shell /usr/sbin/nologin deadwood
id -u deadwood
id -g deadwood
sudo mkdir -p /etc/deadwood
sudo chown deadwood:deadwood /etc/deadwood
sudo chmod 750 /etc/deadwood

キャッシュをファイルに保存する場合、このディレクトリに Deadwood が書き込める必要があるため、所有者を専用ユーザーにしています。

/etc/dwood3rc の最小構成

設定ファイルは Python に似た書き方です。次は、社内のネットワーク 192.168.1.0/24 に向けて、192.168.1.53 で待ち受ける例です。maradns_uid と maradns_gid には、先ほど id で調べた番号を入れます(以下の 991 は例です)。

# /etc/dwood3rc
bind_address = "192.168.1.53"
recursive_acl = "192.168.1.0/24, 127.0.0.1/32"

chroot_dir = "/etc/deadwood"
maradns_uid = 991
maradns_gid = 991

# 終了時にキャッシュを保存し、次の起動で読み込む(chroot_dir からの相対パス)
cache_file = "dw_cache_bin"
  • **bind_address**:待ち受けるアドレスです。0.0.0.0 にすると外向きのアドレスでも待ち受けてしまうため、社内向けのアドレスを書きます。
  • **recursive_acl**:問い合わせを受ける相手です。カンマ区切りで複数のネットワークを書けます。ここに含まれない相手からの問い合わせには答えません。
  • **cache_file**:キャッシュの保存先です。再起動の直後に名前解決が遅くなるのを和らげます。不要なら書かなくてかまいません。

問い合わせ先を決める

Deadwood が答えを探しに行く先は、ルートサーバーから順にたどる方法と、ほかのリゾルバーに任せる方法(フォワード)があります。フォワードする場合は upstream_servers を使います。

# 上位のリゾルバーにまとめて任せる例(アドレスは利用するリゾルバーに置き換え)
upstream_servers = {}
upstream_servers["."] = "192.0.2.1, 192.0.2.2"

ルートサーバーからたどる場合は root_servers を使います。版によってはルートサーバーの一覧が組み込まれていて、何も書かなくてもルートからたどるものがあります。配布物に含まれる dwood3rc の例と、マニュアルの root_servers の説明を確認し、手元の版の動きに合わせて書いてください。同じ名前に対して upstream_servers と root_servers の両方を指定すると、起動時にエラーになるとされています。

プライベートアドレスを返す名前がある場合

Deadwood には、外部の DNS から返ってきたプライベートアドレス(192.168.x.x など)の応答を捨てる設定(filter_rfc1918)があり、版によっては既定で有効です。これは、外部のドメインを使って社内のアドレスに誘導する攻撃(DNS リバインディング)を防ぐためのものです。社内の名前が上位の DNS からプライベートアドレスで返ってくる構成で、名前が引けない場合は、この設定を疑います。無効にすると防御も外れるため、社内の名前だけを社内の権威サーバーに問い合わせる構成にできないかを先に検討します。

systemd で起動する

パッケージや配布物にユニットファイルが用意されていればそちらを使います。無ければ次のように作ります。ExecStart のパスは、command -v Deadwood で確認した場所に合わせます。

# /etc/systemd/system/deadwood.service
[Unit]
Description=Deadwood caching DNS resolver
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/usr/local/sbin/Deadwood -f /etc/dwood3rc
Restart=on-failure

[Install]
WantedBy=multi-user.target
# 53番ポートを使っているものがないかを先に確認する
sudo ss -lunp 'sport = :53'

sudo systemctl daemon-reload
sudo systemctl enable --now deadwood
systemctl status deadwood
journalctl -u deadwood -n 50

起動に失敗する場合は、次の順に確認します。

  1. 53番ポートが使われている:同じアドレスで別の DNS ソフトウェアが待ち受けていないかを ss で確かめます。systemd-resolved は通常 127.0.0.53 で待ち受けるため、社内向けのアドレスとは衝突しませんが、設定を変えていると衝突することがあります。
  2. dwood3rc の書き間違い:引用符の閉じ忘れや、upstream_servers = {} の行の抜けがよくある原因です。ログにどの行で止まったかが出ます。
  3. ディレクトリの権限:cache_file を書き込めない場合は、chroot_dir の所有者と権限を確認します。

動作確認

まず Deadwood のサーバー自身から確認し、次に社内の別のパソコンから確認します。

dig @192.168.1.53 www.example.org A
# 2回目はキャッシュから答えるため、Query time が短くなる
dig @192.168.1.53 www.example.org A

status: NOERROR で答えが返り、2回目の Query time が短くなっていれば、キャッシュが効いています。続いて、recursive_acl に含まれない相手からの問い合わせが断られることを確認します。社外のネットワークから試せない場合は、許可していない社内のセグメントから試します。答えが返らず、タイムアウトになれば想定どおりです。

ファイアウォールでは、社内のネットワークからの UDP と TCP の53番ポートだけを許可します。Deadwood が TCP の問い合わせを受けるかどうかは版と設定によって変わるため、応答の大きい名前を引く利用者がいる場合は、マニュアルで TCP に関する設定を確認しておきます。

クライアント側の設定

社内のパソコンに Deadwood を使わせるには、DHCP サーバーで配る DNS サーバーのアドレスを 192.168.1.53 に変えるのが手間が少ない方法です。ルーターが DHCP を担当している場合は、ルーターの設定で DNS サーバーのアドレスを指定します。

1台だけ試す場合は、OS の設定で DNS サーバーを手動で指定します。systemd-resolved を使う Linux なら、resolvectl dns <インターフェイス名> 192.168.1.53 で一時的に切り替えられます。

切り替えた後に一部のサイトが開かなくなった場合は、そのクライアントから dig @192.168.1.53 名前 を実行し、Deadwood が答えを返しているかを確かめます。Deadwood が答えていてクライアントで引けない場合は、クライアント側のキャッシュ(OS やブラウザ)が残っていることが多いので、キャッシュを消してから試します。

Deadwood が止まると社内の名前解決がすべて止まるため、2台目を用意して DHCP で両方のアドレスを配るか、少なくとも systemd の Restart=on-failure と死活監視を組み合わせておきます。

まとめ

  • MaraDNS の配布物に含まれる Deadwood は、社内向けのキャッシュDNSとして単独で使えます。DNSSEC の検証はしないため、検証が必要なら別のリゾルバーを選びます。
  • /etc/dwood3rc では、社内向けのアドレスで待ち受け、recursive_acl で利用者を社内のネットワークに限ります。
  • 問い合わせ先はフォワード(upstream_servers)かルートからたどるかを決め、手元の版のマニュアルで既定の動きを確認します。
  • systemd で動かし、キャッシュの効きと、許可していない相手が断られることを確かめてから、DHCP で利用者に配ります。

お気軽にご相談ください

お見積りへ お問い合わせへ
▲