First DNS resolve takes 20s when going through a dummy interface's nameserver

[dreua]

systemd version the issue has been seen with

systemd-250.7-1.fc36.x86_64

Used distribution

Fedora 36

Linux kernel version used

5.18.9-200.fc36.x86_64

CPU architectures issue was seen on

x86_64

Component

systemd-resolved

Expected behaviour you didn't see

All DNS requests should be served in fractions of a second under normal conditions.

Note, that using the same technique of setting DNS server and search domains on an actual VPN connection works like a charm, I see this problem only with a dummy interface.

Unexpected behaviour you saw

The first request to the dummy's DNS server stalls for about 20s before it returns the correct result. Subsequent calls perform as expected untill the service is restarted or the cooldown time is reached (some hours, not sure).

Steps to reproduce the problem

We'll use fedoraproject.org for reproducing. (This example is of course pointless in practice, I came up with this configuration to resolve private hostnames of a third party through site to site VPN.)

1. Create a dummy interface with DNS and search-domain:
   nmcli connection add type dummy ifname dns-fproject ipv4.method manual ipv4.address 192.168.15.1/24 ipv6.address fd2b:83eb:99df:f071::42/64 ipv4.dns "1.1.1.1" ipv4.dns-search "~fedoraproject.org"
2. Any DNS query which gets resolved through that dummy-interface, e.g.:
   date && time resolvectl query src.fedoraproject.org && date
3. Repeat step 2: Response times will be normal, even if you query other subdomains like bodhi.fedoraproject.org
4. Restart the service in case you want to experience the bug again: sudo systemctl restart systemd-resolved.service
5. Clean up when you are done: nmcli connection delete dummy-dns-fproject

Additional program output to the terminal or log subsystem illustrating the issue

$ date && time resolvectl query src.fedoraproject.org && date
Mi 13. Jul 17:11:21 CEST 2022
src.fedoraproject.org: 38.145.60.20            -- link: dns-fproject
                       38.145.60.21            -- link: dns-fproject

-- Information acquired via protocol DNS in 15.8112s.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network

real	0m15.818s
user	0m0.003s
sys	0m0.004s
Mi 13. Jul 17:11:36 CEST 2022

----------------------------------------------------

Journal:
Jul 13 17:11:26 cdf systemd-resolved[50774]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 1.1.1.1.
Jul 13 17:11:26 cdf systemd-resolved[50774]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 1.1.1.1.
Jul 13 17:11:32 cdf systemd-resolved[50774]: Using degraded feature set TCP instead of UDP for DNS server 1.1.1.1.
Jul 13 17:11:32 cdf systemd-resolved[50774]: Using degraded feature set TCP instead of UDP for DNS server 1.1.1.1.

[dreua]

It usually takes 20 seconds, not sure why the run in my bug report took only 15s:

$ date && time resolvectl query src.fedoraproject.org && date
Mi 13. Jul 17:14:58 CEST 2022
src.fedoraproject.org: 38.145.60.20            -- link: dns-fproject
                       38.145.60.21            -- link: dns-fproject

-- Information acquired via protocol DNS in 21.0305s.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network

real	0m21.038s
user	0m0.003s
sys	0m0.004s
Mi 13. Jul 17:15:20 CEST 2022

Jul 13 17:15:09 cdf systemd-resolved[51849]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 1.1.1.1.
Jul 13 17:15:09 cdf systemd-resolved[51849]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 1.1.1.1.
Jul 13 17:15:19 cdf systemd-resolved[51849]: Using degraded feature set TCP instead of UDP for DNS server 1.1.1.1.
Jul 13 17:15:19 cdf systemd-resolved[51849]: Using degraded feature set TCP instead of UDP for DNS server 1.1.1.1.

[dreua]

Debug log as requested by @yuwata :
https://gist.github.com/dreua/e398b7f9ea05259c40e67796bbabe6ee

Let me know if there is anything else I can do. Thanks!

[poettering]

Pretty sure this is fixed by 51d0568

[dreua]

Thanks for the update. I'm not using that setup any more though