今までは LMDE をインストールした直後には DNS キャッシュのために systemd-resolved を追加でインストールしていたのですが、これを Unbound に変更してみました。
Debian はなぜか初期状態では DNS キャッシュが効くアプリがインストールされないようになっています。Firefox は自分で DNS 情報をキャッシュするのでそんなに影響はないのですが、LMDE のアップデートマネージャーとかが最悪です。apt update とか apt インストールとかが激遅なんです。
というわけで、DNS キャッシュのために追加でアプリをインストールするわけですが、メジャーなところだと systemd-resolved、dnsmasq、Unbound 辺りから選択することになります。
ワタシは Ubuntu ベースの Linux Mint 時代に慣れ親しんでいた systemd-resolved を何の迷いもなく選択していたのですが、LMDE ユーザーは dnsmasq や Unbound を使う人もいるようなことを発見し、どういう違いがあるのか調べてみたところ、dnsmasq や Unbound にはロギング機能やアクセス拒否する機能が備わっていることに気づきました。
これは試してみるしかあるまい、ということでどっちにしようか迷ったのですが、dnsmasq はなんかお手軽すぎる感じがしたのでちょっとハードルが高そうな Unbound に挑戦してみることにしました。
まずは systemd-resolved の停止です。
systemctl stop systemd-resolved systemctl disable systemd-resolved mv /etc/resolv.conf /etc/resolv.conf.bk
この時点で DNS 問い合わせが失敗するようになりますので注意が必要です。
NetworkManager を再起動すると /etc/resolv.conf を NetworkManager が勝手に再作成するはずです。
systemctl restart NetworkManager
おや？resolv.conf が再作成されないですね。仕方がないので自分で書き直しました。
namaeserver 1.0.0.1
とりあえずこれでインターネットというか Firefox でウェブサイトにアクセスできるようになりました。
続いて Unbound をインストールします。
apt install unbound
これでインストールは完了です。
本格的に使用する前にログを出力させたいので Unbound の設定変更に移ります。
/etc/unbound/unboud.conf.d 配下にカスタマイズ用の conf ファイルを配置して使用するのが一般的なようです。
sudo cp /usr/share/doc/unbound/examples/unbound.conf /etc/unbound/unbound.conf.d/my-unbound.conf
ひな型を /usr/share からコピーしてきて、それを編集するのがよさそうです。編集した部分はこんな感じです。
logfile: "/var/log/unbound/unbound.log" use-syslog: no log-queries: yes
その後に logfile パラメーターで指定したディレクトリを用意してあげます。
cd /var/log mkdir unbound chown unbound:unbound /var/log/unbound/
ユーザー：unbound に権限付与を忘れがちだそうですので忘れずに。
さあ、準備ができたので Unbound を再起動してみます。その前に、resolv.conf を修正して Unbound を使うようにしないといけませんでしたね。
$ cat /etc/resolv.conf nameserver ::1 nameserver 127.0.0.1
はい、いよいよ Unbound の再起動です。
error: Could not open logfile /var/log/unbound/unbound.log: Permission denied
何やらエラーメッセージが出力されています。DNS キャッシュ自体は働いているようですが、期待していたログが出力できていないようです。ていうか、システムログに出力されていますね。
ここでまたまた Gemini くんの登場です。
ふんふん、AppArmor がログ出力をブロックしている可能性があるとな？
kernel: audit: type=1400 audit(1769166020.223:125): apparmor="DENIED" operation="mknod" class="file" profile="unbound" name="/var/log/unbound/unbound.log" pid=4943 comm="unbound" requested_mask="c" denied_mask="c" fsuid=116 ouid=116 kernel: audit: type=1400 audit(1769168973.200:126): apparmor="DENIED" operation="open" class="file" profile="unbound" name="/var/log/unbound/unbound.log" pid=4943 comm="unbound" requested_mask="ac" denied_mask="ac" fsuid=116 ouid=116
確かに AppArmor にブロックされていました。
/etc/apparmor.d/usr.sbin.unbound というファイルがいつの間にか作成されていましたが、設定変更のために編集するのは /etc/apparmor.d/local/usr.sbin.unbound の方になります。
こちらは空の状態で存在していました。
/var/log/unbound/ r, /var/log/unbound/** rw,
こんな風に編集しました。このファイルは上位ファイルの一部ということなので、全行の行末には継続を示すカンマが必要とのことです。うっかり外さないように気をつけましょう。
一行目の設定が必要なのかはちょっと不明ですが、Gemini くんを信じて定義してみました。
そして AppArmor に反映させます。
apparmor_parser -r /etc/apparmor.d/usr.sbin.unbound
編集したファイルではなく、上位ディレクトリのファイル名を指定するところがポイントです。ちなみにこのファイルはテキスト形式ではなくバイナリー形式のようです。
準備ができたので Unbound を再起動してみます。
systemctl restart unbound
さあ、指定したログファイルにクエリーログが出力されているでしょうか？
$ tail /var/log/unbound/unbound.log unbound[32406:0] info: ::1 gae2-spclient.spotify.com. A IN unbound[32406:0] info: ::1 gae2-spclient.spotify.com. AAAA IN unbound[32406:0] info: ::1 pixel.gliacloud.com. A IN unbound[32406:0] info: ::1 pixel.gliacloud.com. AAAA IN unbound[32406:0] info: ::1 gnetwork.gliastudios.com. A IN unbound[32406:0] info: ::1 gnetwork.gliastudios.com. AAAA IN unbound[32406:0] info: ::1 www.blogger.com. A IN unbound[32406:0] info: ::1 www.blogger.com. AAAA IN unbound[32406:0] info: ::1 ssl.gstatic.com. A IN unbound[32406:0] info: ::1 ssl.gstatic.com. AAAA IN
大成功です！！ （一部を省略してます）
ちなみに、以下のコマンドで DNS キャッシュのヒット率を確認することができます。
unbound-control stats_noreset
あとはログのローテーションとアクセスブロックの設定組み込みですね。