Re: systemd-resolved and single-label DNS entries

[Daniel Gomez <da.gomez@kernel.org>]

On 26/08/2025 16.21, Jeff Layton wrote:
> On Tue, 2025-08-26 at 14:53 +0200, Daniel Gomez wrote:
>> On 26/08/2025 12.58, Jeff Layton wrote:
>>> I'm hitting a problem with NFS testing on kdevops guests. Recently when
>>> I bring up a guest, it's unable to resolve the name of the NFS server
>>> via DNS.
>>
>> FYI, nfstests works fine with Debian testing (forky). Both hosts and guests.
>>
>>
> 
> 
> Thanks. Some questions:
> 
> 1/ did your setup get the entries in /etc/hosts? That seems to be what

No. AFAIK, we don't set up anything in the /etc/hosts. At least, the task
below does not run during my bringup.

- name: Fix up hostname on Debian guestfs hosts


> has changed recently. That's not working for some reason.
> 
> 2/ Does forky use systemd-resolved? The problem is clearly there with
> Fedora 42. The DNS server on the virtual bridge works fine:

It does not use systemd-resolved. At least, my system has been updated from
trixie to forky and did not get that installed.

> 
> ----------------8<-----------------
> $ dig @192.168.122.1 kdevops-nfsd.
> 
> ; <<>> DiG 9.18.33 <<>> @192.168.122.1 kdevops-nfsd.
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24955
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ;; QUESTION SECTION:
> ;kdevops-nfsd.                  IN      A
> 
> ;; ANSWER SECTION:
> kdevops-nfsd.           0       IN      A       192.168.122.85
> 
> ;; Query time: 0 msec
> ;; SERVER: 192.168.122.1#53(192.168.122.1) (UDP)
> ;; WHEN: Tue Aug 26 10:18:47 EDT 2025
> ;; MSG SIZE  rcvd: 57


sudo virsh list --all | grep "dio\|interop\|posix\|iscsi\|nfsd"
 13   debian13-interop                    running
 14   debian13-nfsd                       running
 15   debian13-dio                        running
 16   debian13-posix                      running
 17   debian13-iscsi                      running

dig @192.168.122.1 debian13-nfsd

; <<>> DiG 9.20.11-4-Debian <<>> @192.168.122.1 debian13-nfsd
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4579
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;debian13-nfsd.                 IN      A

;; ANSWER SECTION:
debian13-nfsd.          0       IN      A       192.168.122.193

;; Query time: 0 msec
;; SERVER: 192.168.122.1#53(192.168.122.1) (UDP)
;; WHEN: Tue Aug 26 11:03:33 PDT 2025
;; MSG SIZE  rcvd: 58

> 
> $ resolvectl query kdevops-nfsd.
> kdevops-nfsd.: 'kdevops-nfsd.' not found
> ----------------8<-----------------

dig debian13-nfsd

; <<>> DiG 9.20.11-4-Debian <<>> debian13-nfsd
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60809
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;debian13-nfsd.                 IN      A

;; Query time: 3 msec
;; SERVER: 192.168.64.5#53(192.168.64.5) (UDP)
;; WHEN: Tue Aug 26 11:09:44 PDT 2025
;; MSG SIZE  rcvd: 42

nslookup debian13-nfsd
;; Got SERVFAIL reply from 192.168.64.5, trying next server
;; Got SERVFAIL reply from 192.168.64.6
Server:         192.168.64.6
Address:        192.168.64.6#53

** server can't find debian13-nfsd: SERVFAIL

nslookup debian13-nfsd 192.168.122.1
Server:         192.168.122.1
Address:        192.168.122.1#53

Name:   debian13-nfsd
Address: 192.168.122.193
;; communications error to 192.168.122.1#53: timed out
;; communications error to 192.168.122.1#53: timed out
;; communications error to 192.168.122.1#53: timed out
;; no servers could be reached


> 
> It seems like we're doing something "unseemly" by putting bare names in
> DNS like this, given that systemd-resolved won't pass them along.
> 
> Since systemd-resolved will only resolve bare names without a domain
> using LLMNR, we should either take steps to make that work, or fix it
> so that systemd-resolved will forward the requests (by setting up a
> proper domain name and setting up the search path in the resolver).
>