DNS problems after upgrade Fedora 33

After installing fedora 33, everything seemed perfect, until when I connected to my work VPN (cisco anyconnect) the sites that I consult about my work through the VPN I cannot see it, for example: git.mycompany.mx, the error I get in the chrome browser is:

DNS_PROBE_FINISHED_NXDOMAIN

I have already set 8.8.8.8 as DNS server and I turn off the firewall but I have not been successful, it only happens with the domains of my company for which I use the VPN, I rule out VPN problems because I have managed to connect to SSH servers without problems , also for all public domains I can access without problem, I hope someone can help me.

2 Likes

Please read this post here and follow the steps it recommends. I’d like to see, in particular, the output of resolvectl domain and resolvectl dns. To keep your issue separate from that issue, please reply here, NOT in that thread. Thanks.

How exactly did you set this? And why? 8.8.8.8 is obviously not going to be able to resolve your company’s internal domain names?

2 Likes

Modify your connection and re-establish it to apply changes:

sudo nmcli connection modify id VPN_CON \
    ipv4.dns COMPANY_DNS_IP ipv4.dns-search ~mycompany.mx

See also:

OK, your configuration is really strange. Let’s make sure you understand what this all means:

  • Send all DNS requests for localdomain or google.com to your global DNS servers, 10.67.76.11 or 10.67.76.12. This is very strange. Those look like your VPN’s DNS servers? Those should normally be configured for your VPN interface (cscotun0), not globally.
  • Send all other DNS requests to both the DNS servers for enp8s0 and for wlp9s0f0, which is your router OR to Google. It’s strange that you’ve configured Google only for your wi-fi interface but not for your ethernet interface – that’s probably a mistake – and it’s also strange that you’ve configured the wifi interface to use BOTH your router AND Google, since normally you would want one or the other. But this is probably harmless, and certainly not related to your bug.
  • Notably, your VPN interface cscotun0 has no DNS domain, meaning it has been configured to never receive DNS. That is, it is expected that you cannot resolve internal domain names, because your VPN interface has no DNS domains!

Finally, I notice that google.com is configured as a search domain rather than a routing domain. I think this means that you’re appending google.com to single-label queries. E.g. when you look up any single-label domain, like say mail, it should also search for mail.google.com. Try typing resolvectl query mail and see what happens. It’s not so unusual to do it for localdomain, but doing it for google.com is really weird. I don’t see why you would ever want that.

So when you try to look up git.mycompany.mx, systemd-resolved says “this is not localdomain or google.com, so I should use the catch-all domain ~., which is configured for enp8s0 and wlp9s0f0. So I should send the request to fe80::1%22034, 2001:4860:4860::8888, 192.168.100.1, or 8.8.8.8. I can pick any one of those, and if it doesn’t respond, I’ll try another. But if one does reply and say that git.mycompany.mx does not exist, then it really doesn’t exist and I should give up.” And all of those servers say it doesn’t exist, because those are public servers but the domain is internal. Guess: only 10.67.76.11 or 10.67.76.12 would be able to resolve it successfully. Please confirm that by running dig @10.67.76.11 git.mycompany.mx to see whether those are indeed the right DNS servers to use for your internal domains.

That might work, because cscotun0 has no configured DNS server, so I guess it will use the Global settings, and the Global settings appear to be the VPN’s DNS servers. So I agree that this might work.

But it’s really weird that the VPN’s DNS has been configured as global DNS. It would be better to configure it for cscotun0 instead, since that is the VPN interface. I wonder how this happened. pblmx, I wonder if you did anything special when you originally configured this VPN…?

Also, the google.com search domain, while not related to this bug, is very strange. Did you set that up intentionally? You can probably access Google Mail just by typing mail and nothing else into your address bar? Same for Google Maps if you type maps alone? That is wild…

1 Like

My guess is you configured 8.8.8.8 in System Settings, but left the Automatic DNS toggle button checked. Then you get both 8.8.8.8 and your normal DNS configured via DHCP. Usually, Automatic DNS would be disabled if adding 8.8.8.8 to ensure only Google is used, but it’s perfectly fine to leave it enabled – as you have done – if you just want it as a backup and don’t mind that your DNS could go to either place.

You probably want to add it to your wired connection too, since it uses the same DNS servers as your wifi connection, and it doesn’t make sense to have different settings for one but not the other.

Hello, I have the some problem! but
I was able to solve it, with command:

sudo ln -sfv /run/systemd/resolve/resolv.conf /etc/resolv.conf

you must make sure that in the first line contain the nameserver’s company and also the search line.

Example:

nameserver
nameserver 8.8.8.8
search mycompany.com

Reference:

I was wondering if the OP (pblmx) found a solution. I am also using Cisco Anyconnect for my companies VPN and once I connect to the VPN, I am unable to connect to any company servers.

The DNS part of systemd-resolved is working because the correct IP addresses are found I just unable to connect to any servers. I have been fighting this for two weeks since I updated to F33. Strange thing about this is I know it worked for one day (the first day using company VPN after upgrading to F33) and then it hasn’t worked since.

Including this post and the links in this thread, I have also read these:

https://blogs.gnome.org/mcatanzaro/2020/12/17/understanding-systemd-resolved-split-dns-and-vpn-configuration/

None of the suggestions in these links has helped. Since I am able to resolve the IP address from the hostname from my company, I believe that DNS is working. It’s the routing part of systemd-resolved that I don’t think is working (but I’m no expert when it comes to networking).

For initial debug here is some information when I’m connected to the VPN:
$ resolvectl domain
Global: (company domain)
Link 2 (enp4s0):
Link 3 (wlp3s0):
Link 5 (virbr0):
Link 6 (virbr0-nic):
Link 11 (cscotun0):

$ resolvectl dns
Global: 192.168.100.1 192.168.110.5
Link 2 (enp4s0): 192.168.0.1
Link 3 (wlp3s0):
Link 5 (virbr0):
Link 6 (virbr0-nic):
Link 11 (cscotun0):

$ resolvectl status

Global
Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: foreign
Current DNS Server: 192.168.100.1
DNS Servers: 192.168.100.1 192.168.110.5
DNS Domain: (company domain)

Link 2 (enp4s0)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.0.1
DNS Servers: 192.168.0.1

Link 3 (wlp3s0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 5 (virbr0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 6 (virbr0-nic)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 11 (cscotun0)
Current Scopes: LLMNR/IPv4
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

$ resolvectl query (company domain)
(company domain): (company IP address) – link: cscotun0

– Information acquired via protocol DNS in 19.9ms.
– Data is authenticated: no

$ resolvectl query (server in company domain)
(server in company domain): (company server IP address) – link: cscotun0

– Information acquired via protocol DNS in 1.2ms.
– Data is authenticated: no

Although this thread is a little old, I’m hoping that someone can help me. I don’t want to reinstall F32 because I’m going to have to find a solution at some point and it would just be kicking the can down the road.

Thanks,
Mike

Thinking about split vpn and DNS, makes me wonder.
Does your company have a setup where the same hostname is used on both the LAN and WAN with different IP’s/interfaces?. If so then that could be an issue where the wrong IP is being used for the connection you are trying to make (it is entering via the wrong path).

You could get at least a hint about that by using traceroute with one of the host names that is a problem and see which route is taken (out via the tunnel or out via the router)

There have been several discussions here recently about similar issues and maybe one of those threads will provide an answer.

1 Like

Hi Mike, systemd-resolved only does DNS resolution, it doesn’t do routing. If you’re able to successfully resolve the hostnames that you cannot connect to, then you are experiencing a different sort of problem, not an issue with DNS.

That said, your DNS configuration doesn’t make very much sense. It seems all your DNS queries are being sent to your company’s DNS and to your router. I don’t think that would ever be done intentionally. You should reconsider the use of resolv.conf mode: foreign as it doesn’t make much sense in combination with link-specific configuration. If you need further assistance with this, I recommend creating a new topic, since your issue seems to be unrelated to the original problem here.

2 Likes

To be clear, you’re making two separate DNS queries for each hostname to be resolved, one to 192.168.0.1 (which I presume is your router), and one to 192.168.100.1 (which I presume is your VPN). Whichever query completes first is the one that wins. Normally you only want one DNS query per hostname to be resolved.

I don’t recommend resolv.conf mode: foreign unless you really know what you’re doing and have some strong reason for not letting systemd-resolved manage /etc/resolv.conf.

1 Like

Thanks for the suggestions. I created a new topic here: