I'm testing update my servers from F32 to F33. Situation is: Fedora Server running several Fedora VMs. VMs and host are using libvirt default network via virbr0 for internal private data exchange. A second public bridge provides external connectivity. On virbr0 the DNS service is activated so host and VMs can find each other via name instead IPs.
In F32 I used NetworkManagers dnsmasq plugin to forward internal request (names ending .lan) to libvirt dnsmasq on virbr0 / 192.169.122.1 and everything else to our public DNS.
With F33 I'm to use systemd-resolved which is dns-split capable. The F33 VMs, which have 2 fixed interfaces eht0 (public) and eth1 (private), everything works out of the box without a hitch.
On the F33 Server I had to add two entries to /etc/systemd/resolved.conf: DNS=192.168.122.1%virbr0#example.lan ## (.lan = private domain) Domains=example.lan ## search domain, appended to names w/o a dot
After a reboot it only works after I restart systemd-resolved. Otherwise it fails to resolve internal names / addresses.
My "trusted search engine" showed some discussion but no solution (at least I couldn't identify one).
Any help much appreciated.
Peter
What I did:
[...]# reboot
[...]# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 .... 2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 ... //external interface 3: vbr3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 ... // external routin bridge (brouter) 4: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8000 qdisc noqueue state UP group default qlen 1000 ... // internal bridge 5: virbr0-nic: <BROADCAST,MULTICAST> mtu 8000 qdisc fq_codel master virbr0 state DOWN group default qlen 1000 ... // virtual interface host to virbr0, no IP addres of its own 6: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master vbr3s0 state UNKNOWN group default qlen 1000 ... // virtual public interface VM 7: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8000 qdisc fq_codel master virbr0 state UNKNOWN group default qlen 1000 ... // virtual private interface VM
[...]# resolvectl domain Global: example.lan Link 2 (enp3s0): example.com ~. Link 3 (vbr3s0): Link 4 (virbr0): Link 5 (virbr0-nic): Link 6 (vnet0): Link 7 (vnet1):
[...]# resolvectl dns Global: Link 2 (enp3s0): 213.133.98.98 213.133.99.99 2a01:4f8:0:1::add:1010 2a01:4f8:0:1::add:9999. ## our external name server Link 3 (vbr3s0): Link 4 (virbr0): ## no sign of libvirt dnsmasq server Link 5 (virbr0-nic): Link 6 (vnet0): Link 7 (vnet1):
[...]# resolvectl query vm vm: aaa.bbb.ccc.dd -- link: enp3s0 ## /external name, instead internal 2a01:aaa:bbb:ccc::4 -- link: enp3s0 (vm.example.com)
[...]# resolvectl query vm.example.lan vm.example.lan: resolve call failed: 'vm.example.lan' not found
When I restart systemd-resolved:
[...]# systemctl restart systemd-resolved [...]# resolvectl domain Global: example.lan Link 2 (enp3s0): example.com ~. Link 3 (vbr3s0): Link 4 (virbr0): Link 5 (virbr0-nic): Link 6 (vnet0): Link 7 (vnet1): ## everything as before, nothing changed
[...]# resolvectl dns Global: Link 2 (enp3s0): 213.133.98.98 213.133.99.99 2a01:4f8:0:1::add:1010 2a01:4f8:0:1::add:9999. ## our external name server Link 3 (vbr3s0): Link 4 (virbr0): Link 5 (virbr0-nic): Link 6 (vnet0): Link 7 (vnet1): ## everthing as before, nothing changed here, too
[...]# resolvectl query vm vm: 192.168.122.87 -- link: virbr0 (vm.example.lan) ## different, internal address as expected
[...]# resolvectl query vm.example.lan vm.example.lan: 192.168.122.87 -- link: virbr0. ## internal address, as expected.
On Sun, 2021-02-21 at 23:03 +0100, Peter Boy wrote:
I'm testing update my servers from F32 to F33. Situation is: Fedora Server running several Fedora VMs. VMs and host are using libvirt default network via virbr0 for internal private data exchange. A second public bridge provides external connectivity. On virbr0 the DNS service is activated so host and VMs can find each other via name instead IPs.
In F32 I used NetworkManagers dnsmasq plugin to forward internal request (names ending .lan) to libvirt dnsmasq on virbr0 / 192.169.122.1 and everything else to our public DNS.
With F33 I'm to use systemd-resolved which is dns-split capable. The F33 VMs, which have 2 fixed interfaces eht0 (public) and eth1 (private), everything works out of the box without a hitch.
On the F33 Server I had to add two entries to /etc/systemd/resolved.conf: DNS=192.168.122.1%virbr0#example.lan ## (.lan = private domain) Domains=example.lan ## search domain, appended to names w/o a dot
After a reboot it only works after I restart systemd-resolved. Otherwise it fails to resolve internal names / addresses.
My "trusted search engine" showed some discussion but no solution (at least I couldn't identify one).
Can it be, in any rate, connected with https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... ?
This bug (I don't know if it's fixed yet) hit me on my local dns server, too, but I didn't split dns resolvers for multiple interfaces.
If not, I would guess that systemd-resolved is starting up before network interfaces. Is systemd-resolved unit configured with "Wants=*", or "Require=*"?
Am 22.02.2021 um 12:14 schrieb Łukasz Posadowski mail@lukaszposadowski.pl:
If not, I would guess that systemd-resolved is starting up before network interfaces. Is systemd-resolved unit configured with "Wants=*", or "Require=*"?
Indeed: L. Poettering wrote „… Moreover the interface names are resolved the moment resolved parses the configuration file, i.e. likely before the network iface actually showed up, thus be parsing will fail in the typical case.
So far we have no mechanism to declare a DNS server in our configuration ahead of time. the usual workflow is that either resolved picks the DNS configuration automatically up from networkd, or that "resolvectl dns" is invoked by some external tool (e.g. NetworkManager) that tells systemd about the DNS servers to use the moment the ifaces appear.“
From nmcli output I guess, libvirt doesn’t use NetworkManager to create virbr0:
[...]# nmcli dev DEVICE TYPE STATE CONNECTION br2s0 bridge verbunden BR2s0 virbr0 bridge connected (externally) virbr0 enp2s0 ethernet verbunden System enp2s0 vnet0 tun connected (externally) vnet0. vnet…
Anyway, systemd-resolved does not work smoothly with libvirt. But libvirt is Federa Server's recommended virtualisation tool.
What does this imply for the switch to systemd-resolved for Fedora Server? Does it really make sense?
server@lists.fedoraproject.org