On 9/10/21 4:57 PM, Peter Boy wrote: > Hi all, > > I’m working on an update of the Fedora Server virtlib documentation (https://docs.fedoraproject.org/en-US/fedora-server/virtualization-install/), specifically the part about the DNS configration. > > I would like to include and integrate the solutions presented in this thread by Daniel Berrange and by Juan Alcaine. But unfortunately none of the solutions worked in my test installations. I would be grateful if I could get some hints on what I might have missed. > > The main challenge is to enable the host to resolve the internal name of the VMs. For this purpose, the DNS server provided by libvirt must be included in the search path (default virbr0 192.168.122.1). The server itself works fine. If you use dig or nsloookup to assign the servers, the names of the VMs are resolved correctly. No, it does not have to be included in search path. It is just required to forward any subset of names to dns server listening on libvirt's interface. > > > > (a) === Installing libvirt-nss. (Daniel Berrange) === > > I did the following > > 1. dnf install libvirt-nss > > 2. Modified following the libvirt documentation and the docs included with the files /etc/authselect/user-nsswitch.conf and edited the hosts item to "hosts: files myhostname libvirt resolve [!UNAVAIL=return] dns“ > > 3. executed: authselect apply-changes > > 4. reboot > > Neither using standard DNS without systems-resolved activated nor using systemd-resolved could resolve the internal names of the VM nss modules affects just getaddrinfo() calls from programs, if it uses only glibc to resolve names. Could be tested by "getent hosts <name>" command. Any program using DNS directly, like host or dig, would not be affected by it. Setting up dns forwarding is more work, but would help all programs, no matter how they resolve names to IP addresses. > (b) === using libvirt hook dir to modify systemd-resolved configuration === > > I followed Juan Alcaine's instructions and after booting I got: > > (for my homelab domain, served as public here) > Link 2 (enp1s0) > Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 > Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported > Current DNS Server: 192.168.158.1 > DNS Servers: 192.168.158.1 fd00::3681:c4ff:fe14:21b4 > DNS Domain: fritz.box > > (for my internal domain via libvirt ipv4 only) > Link 5 (virbr0) > Current Scopes: DNS LLMNR/IPv4 > Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported > Current DNS Server: 192.168.122.1 > DNS Servers: 192.168.122.1 > DNS Domain: fritz.lan > > The internal names could be resolved, but with such a long delay that the solution is practically unusable. The „host“ utility provided the internal IPv4 name immediately, but continued searching for several seconds and finally the process was terminated with 2 times of the message ";; connection timed out; no servers could be reached“. Host without -t parameter given sends -t A, -t AAAA and -t MX queries for given name. Because of the way dnsmasq behaves, you are waiting for -t AAAA and -t MX queries. Because they are looping from systemd-resolved to dnsmasq and back, until one of them drops them. > > In the systemd-resolved log I found a lot of entries like > > Firing regular transaction 50808 for <zbox.fritz.lan IN AAAA> scope dns on virbr0/* (validate=yes). > > But virbr0 is ipv4 only. This happens because dnsmasq serving names for libvirt network sends AAAA queries to whatever resolver it got from the system. Meaning usually back to whatever forwarded the name to it. In my configuration, I used domain statement in virsh net-edit default to prevent sending X.vm names back to the system resolver. It becames then (sort of) authoritative for that name. You would just replace vm with fritz.lan (or vm.home.arpa.). localOnly=yes is imporant part. It tells dnsmasq to consider all names under fritz.lan its own and if it does not know them, they do not exist. If dns cache on hosts forwards some domain to it, it is required to break loops. <network> ... <domain name='fritz.lan' localOnly='yes'/> ... </network> It would be nice if it could be done automagically, but I doubt used domain can be specified on just single place. Together with libvirt hook, the above should work. > Any advice greatly appreciated. > > > Peter > > > > > >> Am 08.10.2020 um 09:33 schrieb Juan Orti Alcaine <j.orti.alcaine@xxxxxxxxx>: >> >> >> >> El mié., 7 oct. 2020 a las 10:35, Petr Menšík (<pemensik@xxxxxxxxxx>) escribió: >> >> >> On 10/7/20 6:44 AM, Pavel Zhukov wrote: >>> I don't think it's a good idea. >>> dnsmasq is not dns resolver but acts as DHCP and DNS server. It provides >>> VMs with IP >>> address/lease and create corresponding dns record for it. In case of >>> resolved ip addresses and dns records must be managed either manually >>> or... with dnsmasq. >> That is not true. Any query sent to @192.168.122.1 would get reply. I >> use for example unbound on localhost and all my machines use .vm. domain >> suffix. rhel7.vm. is machine with rhel7. Dnsmasq manages automatically >> lease names of all its dhcp clients, it works as dynamic DNS connected >> with DHCP just out of the box. >> >> I've created a libvirt hook to do the integration I was looking for. This works for me: >> >> /etc/libvirt/hooks/network.d/laptop-lab.sh >> >> #!/bin/bash >> set -o nounset >> >> object="$1" >> operation="$2" >> suboperation="$3" >> extra="$4" >> >> if [ "$object" == "laptop-lab" ]; then >> if [ "$operation" == "started" ] && [ "$suboperation" == "begin" ]; then >> /usr/bin/resolvectl dns laptop-lab 192.168.100.1 >> /usr/bin/resolvectl domain laptop-lab laptop.lab >> /usr/bin/resolvectl dnssec laptop-lab no >> fi >> fi >> -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemensik@xxxxxxxxxx PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
