まとめ 
Ubuntu 18.04.2 LTS で dnsmasq を使う場合、以下の 3 点を押さえておくと良い。
- nic 毎の dns をとりまとめるのは /etc/resolv.conf を /run/systemd/resolve/stub-resolv.conf への symbolic link にすることで systemd-resolved の DNSStubListener (127.0.0.53:53) に任せる(systemdctl enable しておく)と良い。
- ただし、このままだと dnsmasq の待ち受けと(0.0.0.0:53 及び :::53 と)競合するので、/etc/dnsmasq.conf の bind-interface をアンコメントしておくことで、待ち受け port は直接 nic に割り当てるようにしておくと良い。
- resolvconf は設定すべき箇所が良く分からないので、設定前に一旦 purge しておいて最後に入れ直すのが良さそう。
状況
Ubuntu 18.04 LTS では network interface card (nic) の設定が、従来の /etc/network/interfaces や NetworkManager から netplan に変更されたらしいという話は以前書いた。
netplan generate や apply を行うと /etc/netplan/ 以下の YAML ファイルから systemd 用に各 nic 設定ファイルが以下の箇所に自動生成される。
この時、ルーターのように nic が複数枚ある場合、それぞれの nic だかサブネットだかに個別に DNS が設定されているような場合が有り得る。
これは systemd-resolved を使うと DNSStubListener なるローカルの DNS を 127.0.0.53:53 に立ち上げてくれて DNS のとりまとめをしてくれる。
ところが、systemd-resolved で DNSStubListener が有効になっていると、dnsmasq が以下のようなエラーを出して起動出来ない。
「systemd dnsmasq systemd-resolved」でググってみると、この競合を解決するには /etc/systemd/resolved.conf で DNSStubListener=no とするか、systemd-resolved 自体を disable にすればよいというアドバイスが多く見つかった。
しかし、上位の DNS を参照させるためには、dnsmasq.conf に resolv-file を設定したり、server に上位 DNS を与えたりという方法が必要であり、これでは折角 netplan に設定した DNS が拾えないし、DHCP 等で拾ってきた DNS を反映させることも難しい。
そこで、listen-address に以下のような設定を行うことで待ち受けアドレスを絞ることを狙ってみたが、これは効果がなかった。
いろいろと調べて回った結果、以下でコメントされている /etc/dnsmasq.conf で bind-interfaces をアンコメントしておく方法が正解のようだ。
この設定を行うと、/etc/dnsmasq.conf で interface に設定された nic に対してのみ liten するようになるため 127.0.0.53:53 と競合しなくなる。
他にも DNS 関連の systemd サービスとしては systemd-resolved 以外にも resolveconf なんかが入ってたりする。
これは /etc/resolv.conf を /etc/resolvconf/ と /run/resolvconf/ 以下に構築し直して、見た目上 /etc/resolv.conf が適切な DNS (例えば dnsmasq) を向くようにしてくれるようだ。
ひょっとすると /etc/resolv.conf を見るソフトには効果があるのかもしれないのだが、これは purge しても、nslookup や dig 等は問題なく動いているように見える。
しかし困ったことに、これが入っていると、/etc/resolv.conf を /run/systemd/resolve/stub-resolv.conf への symbolic link にすることで、DNS のとりまとめを systemd-resolved の DNSStubListener に任せようとする設定をどこにしていいのかが、よく分からなかった。
どうも、/etc/resolvconf/ と /run/resolvconf/ 以下への再構築は install 時に行われるようで、systemctl restart resolvconf 等を行っても symbolic link の張り直しや resolv.conf の再構築が行われている気配が見られない。
という事で、resolvconf については念のため入れておくにしても、とりあえず一旦 purge した上で設定を行い、最後に入れ直すのが良いのではないかと思う。
以上、Ubuntu の公式ドキュメントに詳しい説明があって良さそうなものなのだが、見当たらないのが不思議だ。
探し方が悪いのだろうか？
netplan generate や apply を行うと /etc/netplan/ 以下の YAML ファイルから systemd 用に各 nic 設定ファイルが以下の箇所に自動生成される。
- /run/systemd/network/10-netplan-<NIC_DEV_NAME>.network
この時、ルーターのように nic が複数枚ある場合、それぞれの nic だかサブネットだかに個別に DNS が設定されているような場合が有り得る。
これは systemd-resolved を使うと DNSStubListener なるローカルの DNS を 127.0.0.53:53 に立ち上げてくれて DNS のとりまとめをしてくれる。
ところが、systemd-resolved で DNSStubListener が有効になっていると、dnsmasq が以下のようなエラーを出して起動出来ない。
$ sudo systemctl restart dnsmasq Job for dnsmasq.service failed because the control process exited with error code. See "systemctl status dnsmasq.service" and "journalctl -xe" for details.
$ journalctl -xe ... -- Unit dnsmasq.service has begun starting up. Oct 28 17:27:43 router dnsmasq[1356]: dnsmasq: syntax check OK. Oct 28 17:27:43 router dnsmasq[1357]: dnsmasq: failed to create listening socket Oct 28 17:27:43 router systemd[1]: dnsmasq.service: Control process exited, code Oct 28 17:27:43 router dnsmasq[1357]: failed to create listening socket for port Oct 28 17:27:43 router systemd[1]: dnsmasq.service: Failed with result 'exit-cod Oct 28 17:27:43 router dnsmasq[1357]: FAILED to start up Oct 28 17:27:43 router systemd[1]: Failed to start dnsmasq - A lightweight DHCP -- Subject: Unit dnsmasq.service has failed -- Defined-By: systemd -- Support: http://www.ubuntu.com/support -- -- Unit dnsmasq.service has failed. ...これは、標準では dnsmasq が以下のように 0.0.0.0:53 や :::53 で待ち受けてネットワーク全体から listen しようとするせいらしい。
$ netstat -na | grep ":53 " tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN tcp6 0 0 :::53 :::* LISTEN udp 20736 0 0.0.0.0:53 0.0.0.0:* udp6 0 0 :::53 :::*
「systemd dnsmasq systemd-resolved」でググってみると、この競合を解決するには /etc/systemd/resolved.conf で DNSStubListener=no とするか、systemd-resolved 自体を disable にすればよいというアドバイスが多く見つかった。
しかし、上位の DNS を参照させるためには、dnsmasq.conf に resolv-file を設定したり、server に上位 DNS を与えたりという方法が必要であり、これでは折角 netplan に設定した DNS が拾えないし、DHCP 等で拾ってきた DNS を反映させることも難しい。
そこで、listen-address に以下のような設定を行うことで待ち受けアドレスを絞ることを狙ってみたが、これは効果がなかった。
listen-address=::1,127.0.0.1,192.168.1.1
いろいろと調べて回った結果、以下でコメントされている /etc/dnsmasq.conf で bind-interfaces をアンコメントしておく方法が正解のようだ。
- StackExchange / Unix & Linux / 2016-08-17: How to avoid conflicts between dnsmasq and systemd-resolved? # 2016-10-28: tomtom 氏のコメント
この設定を行うと、/etc/dnsmasq.conf で interface に設定された nic に対してのみ liten するようになるため 127.0.0.53:53 と競合しなくなる。
$ netstat -na | grep ":53 " tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN tcp 0 0 192.168.1.1:53 0.0.0.0:* LISTEN tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN tcp6 0 0 ::1:53 :::* LISTEN tcp6 0 0 fe80::xxxx:xx:xxxx:xx:53 :::* LISTEN udp 0 0 127.0.0.1:53 0.0.0.0:* udp 0 0 192.168.1.1:53 0.0.0.0:* udp 0 0 127.0.0.53:53 0.0.0.0:* udp6 0 0 ::1:53 :::* udp6 0 0 fe80::xxxx:xx:xxxx:xx:53 :::*
他にも DNS 関連の systemd サービスとしては systemd-resolved 以外にも resolveconf なんかが入ってたりする。
$ systemctl list-unit-files|grep -Ei 'resolv|dns'|grep service dnsmasq.service enabled resolvconf-pull-resolved.service static resolvconf.service enabled systemd-resolved.service disabled
これは /etc/resolv.conf を /etc/resolvconf/ と /run/resolvconf/ 以下に構築し直して、見た目上 /etc/resolv.conf が適切な DNS (例えば dnsmasq) を向くようにしてくれるようだ。
ひょっとすると /etc/resolv.conf を見るソフトには効果があるのかもしれないのだが、これは purge しても、nslookup や dig 等は問題なく動いているように見える。
しかし困ったことに、これが入っていると、/etc/resolv.conf を /run/systemd/resolve/stub-resolv.conf への symbolic link にすることで、DNS のとりまとめを systemd-resolved の DNSStubListener に任せようとする設定をどこにしていいのかが、よく分からなかった。
どうも、/etc/resolvconf/ と /run/resolvconf/ 以下への再構築は install 時に行われるようで、systemctl restart resolvconf 等を行っても symbolic link の張り直しや resolv.conf の再構築が行われている気配が見られない。
という事で、resolvconf については念のため入れておくにしても、とりあえず一旦 purge した上で設定を行い、最後に入れ直すのが良いのではないかと思う。
以上、Ubuntu の公式ドキュメントに詳しい説明があって良さそうなものなのだが、見当たらないのが不思議だ。
探し方が悪いのだろうか？
関連
- 20190513: 仮想化 router の構築
- 20190511: Ubuntu - netplan
- 20191028: netplan - debug
- resolvconf?
- systemd-resolved?
- dnsmasq?
- netplan?
タグ
コメントをかく