How to make Ubuntu resolve a subdomain that inherits its nameserver

I'm using Ubuntu 22.04 and since upgrading have not been able to resolve certain subdomains.

The domain above the subdomain works fine. It seems to be something unusual in the DNS configuration, but it worked fine up until Ubuntu 22.04.

Actual results:

$ ping ch.protonvpn.comping: ch.protonvpn.com: No address associated with hostname$ curl ch.protonvpn.comcurl: (6) Could not resolve host: ch.protonvpn.com$ nslookup  ch.protonvpn.comServer:         127.0.0.53Address:        127.0.0.53#53Non-authoritative answer:*** Can't find ch.protonvpn.com: No answer$ getent hosts ch.protonvpn.com

Also actual results, but more like expected (this is the domain, not the subdomain):

$ ping protonvpn.comPING protonvpn.com (185.159.159.140) 56(84) bytes of data.64 bytes from 185.159.159.140 (185.159.159.140): icmp_seq=1 ttl=47 time=44.4 ms$ curl protonvpn.com$ nslookup protonvpn.comServer:         127.0.0.53Address:        127.0.0.53#53Non-authoritative answer:Name:   protonvpn.comAddress: 185.159.159.140$ getent hosts protonvpn.com185.159.159.140 protonvpn.com

With dig:

$ dig ch.protonvpn.com; <<>> DiG 9.18.1-1ubuntu1.1-Ubuntu <<>> ch.protonvpn.com;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54721;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 65494;; QUESTION SECTION:;ch.protonvpn.com.              IN      A;; Query time: 4 msec;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP);; WHEN: Fri Jul 29 11:51:02 IST 2022;; MSG SIZE  rcvd: 45$ dig protonvpn.com; <<>> DiG 9.18.1-1ubuntu1.1-Ubuntu <<>> protonvpn.com;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60428;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 65494;; QUESTION SECTION:;protonvpn.com.                 IN      A;; ANSWER SECTION:protonvpn.com.          145     IN      A       185.159.159.140;; Query time: 0 msec;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP);; WHEN: Fri Jul 29 11:51:09 IST 2022;; MSG SIZE  rcvd: 58

I'm going to make a guess that someone will say that my system is working as it should be, and that I am not set up to deal with whatever Cloudflare (the DNS provider) is doing with the records.

The behaviour before Ubuntu 22.04, though, is what I want.In my simple understanding, my system would go find the DNS record and, if it didn't get the IP address to resolve to, it would follow the records until it did get it.

Specifically, this subdomain is for a vpn, and openvpn worked with it happily until the Ubuntu 22.04 upgrade.

I guess it is something to do with the result I get when I visit https://www.nslookup.io/domains/ch.protonvpn.com/dns-records/

NS records

No NS records found.

The name servers for this domain are inherited from one of its ancestor domains. Try its parent domain: protonvpn.com

What can I do to make DNS resolution 'just work' where the subdomains inherit their parent domains' nameservers?

Possibly related: https://superuser.com/questions/1682572/openvpn-connection-cannot-find-route-to-direct-domains-but-to-subdomains

I have checked out a few answers which did not resolve things, so for completeness:

$ cat /etc/netplan/*.yaml# Let NetworkManager manage all devices on this systemnetwork:  version: 2  renderer: NetworkManager

$ ll /etc/resolv.conflrwxrwxrwx 1 root root 39 Jul  8 16:20 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf$ cat /etc/resolv.conf# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).# Do not edit.## This file might be symlinked as /etc/resolv.conf. If you're looking at# /etc/resolv.conf and seeing this text, you have followed the symlink.## This is a dynamic resolv.conf file for connecting local clients to the# internal DNS stub resolver of systemd-resolved. This file lists all# configured search domains.## Run "resolvectl status" to see details about the uplink DNS servers# currently in use.## Third party programs should typically not access this file directly, but only# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a# different way, replace this symlink by a static file or a different symlink.## See man:systemd-resolved.service(8) for details about the supported modes of# operation for /etc/resolv.conf.nameserver 127.0.0.53options edns0 trust-adsearch .

[main]plugins=ifupdown,keyfile[ifupdown]managed=false[device]wifi.scan-rand-mac-address=no