> Am 15.09.2021 um 19:22 schrieb Petr Menšík <pemensik@xxxxxxxxxx>: Many thanks for your information. They were very helpful. I got (almost) everything working with your (and Daniel's) information. > On 9/10/21 4:57 PM, Peter Boy wrote: >> Hi all, >> >> ... >> 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. That’s one of the issues I currently struggle with. Due to the installation the external interface comes first in the list, before the internal interface. So the external inferfaces name server is queried first (as I could confirm in the log). 'resolvectl query' always came up with the internal FQN and IP address for a single named host, as intended. 'host' and 'nslookup' mostly used the internal, but sometimes the external FQN name (after reboots). No regularity recognizable. 'dig‘ reports having found something, but does not show any IP address. 'ping‘ and 'wget‘ (as proxy for a more or less typical application program) are not consistent either. For applications, I was able to solve this at least partially by including libvirt-nss. The other option would be to replace the link of /etc/resolve.conf with a file and define the search option accordingly (the currently automatic generated file lists the external domain name first). I'm hesitant to have that in the server documentation but stick as much as possible with upstream and default settings. Do you have another idea from your experiences? >> 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. I added <domain name='fritz.lan' localOnly='yes‘/> And that solves the long delay. Thanks. You can see in the log that 'host' and 'nslookup' still send AAAA requests by default. That produces the output Name: vm1.fritz.lan Address: 192.168.122.129 ** server can't find vm1.fritz.lan: REFUSED The combination of IP address and REFUSED for the same name is misleading and possibly troubling to an admin if you don't know the background. The only possible solution to this that I can think of would be to introduce local IPv6 addresses. Do you have another solution from your experience? Again, thanks for your advice. It makes the Server docs much better. Peter _______________________________________________ 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
