Open jgarbora opened 4 years ago
I'm having similar issues on Mint 19.3. update-systemd-resolved seems like it's updating dns, but then when I go to ping anything on that lan, ping isn't able to resolve it (but it can ping the machine by ip)
nslookup
goes directly to /etc/resolv.conf
to find out DNS servers to use and (as can be seen in the output) it uses the first one there (10.104.1.130) which is the DNS server available through VPN link thus it works.
ping
on the other hand uses libc resolver thus honours /etc/nsswitch.conf
configuration which probably directs the query in some moment to systemd-resolved (either directly by means of systemd-specific resolve
directive or indirectly through a systemd-resolved stub-resolver by means of the standard dns
directive).
As there is ~.
routing domain specified on wlp2s0 interface systemd-resolved routes all queries to the DNS server for this link (192.168.5.1) which is a different DNS server that in the case of nslookup
which might explain different result in domain lookup result.
The root of the problem is lack of VPN provided DNS server (10.104.1.130) on the list of DNS servers of VPN link (tun0) which is strange.
However one thing is not clear to me; as kibana-teahupoo.aws.xxx.com seems to be a public domain I would expect it to be resolved by the DNS server on wlp2s0 link (192.168.5.1) just fine. Is this DNS server somehow restricted? Do you expect kibana-teahupoo.aws.xxx.com to be resolved specifically by the DNS server of VPN link?
If you want to know more on split DNS (different DNS servers for different domains) I would recommend recent article https://fedoramagazine.org/systemd-resolved-introduction-to-split-dns/
@jgarbora @Hordeking -- does this remain an issue?
@tomeon I will have to take a look and see. I will post something when I try it again.
@jgarbora -- couple of things:
dhcp-option
s? I don't see anything in your $ openvpn xxxVPN.ovpn
snippet to suggest that the server is specifying any DNS servers, DNS search or routing domains, etc. Note that, if the server doesn't push appropriate settings, you can always add, say, dhcp-option DNS <VPN-DNS-resolver-IP>
to your client configuration. See here for available options.kibana-teahupoo.aws.xxx.com
the actual domain you are resolving, or is xxx
a placeholder for something else? It sure seems like it's the latter:$ dig lolol.wat.xxx.com
; <<>> DiG 9.18.16 <<>> lolol.wat.xxx.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57195
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;lolol.wat.xxx.com. IN A
;; ANSWER SECTION:
lolol.wat.xxx.com. 1800 IN CNAME www.xxx.com.
www.xxx.com. 1749 IN A 141.0.173.173
;; Query time: 311 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Fri Sep 08 09:28:03 EDT 2023
;; MSG SIZE rcvd: 80
package's version: openvpn-systemd-resolved: 1.3.0-3 openvpn: 2.4.7-1ubuntu2
config file
starting
resolv.conf after connecting
then some how DNS is resolved
but not for ping
or browser
systemd-resolve --status
Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
any clue ? same config is running fine on a debian 10 this is a Ubuntu 19.10