この記事を書いてるタイミングで、Twitterの方ではUbuntu 18.04にアップデートしたときの作業を呟いていたのですが、その中でネットワーク周りの設定をNetworkManagerからnetplanに変更していることをお伝えしていました。
色々と設定していくと、localhostで53/tcp,53/udpが開いていることに気が付きました
調べていくのですが一番最初に気にしたのは、何かとよく出てくるdnsmasqなんですが、これは起動していないことを確認。
18.04からresolve周りは、標準だと/etc/resolv.confに「127.0.0.53」が叩き込まれ、そしてそこからsystemd-resolveのGlobalに設定したDNS Serversに指定されたDNSサーバに名前解決をする流れになったようです。
しかし、これも上記にあるように「127.0.0.53」に対してforwardする流れなので、127.0.0.1:53が起動している理由にはならないはず・・・
さらに調べてみたところ、やはりちゃんとmanには記述がありました。
Ubuntu Manpage: resolved.conf, resolved.conf.d – Network Name Resolution configuration files
DNSStubListener=
Takes a boolean argument or one of “udp” and “tcp”. If “udp” (the
default), a DNS stub resolver will listen for UDP requests on
address 127.0.0.53 port 53. If “tcp”, the stub will listen for TCP
requests on the same address and port. If “yes”, the stub listens
for both UDP and TCP requests. If “no”, the stub listener is
disabled.
127.0.0.53:53をstub resolverに設定しているようです。
今回設定しているサーバはlocalhostでUnboundが起動するため、邪魔になってしまうためnoに設定しました。
これでsystemd-resolveを再起動すると、127.0.0.53は無効化されていることを確認しました。
しかし、このresolved.conf、systemdになってから色々と機能分離されているんですね。
DNSキャッシュはもとよりDNSSECの設定などもできるようになっていることに驚きました。
このあたりも少し勉強が必要のようです。
resolved.conf(5) — Arch manual pages
ネームサーバーを変更する – Qiita
追記：2018年4月30日
本来であれば、先に53番ポートを使用しているプロセスがあれば、そちらが優先になるのですが、現在テストしている環境だと、sytemd-resolvedのあとに、本来使用したいプロセスが起動するため、私の意図通りにならなかったようです。
Apr 30 10:45:41 dns02 systemd-resolved[11167]: Another process is already listening on UDP socket 127.0.0.53:53.
