0

old MacBook screen is dying, so switched to a new Ubuntu 22 laptop

immediately DNS problems, hitherto not experienced, ensued

I'm working with a staging box (AWS), xsubdomain.xdomain.com. Web browsers happily resolve the url, proving that I've set up AWS security groups correctly, and that DNS record is properly updated (web DNS lookup tools agree). But all the CLI tools, which work on the mac box, fail on Linux (curl and ssh is enough of a case). The symptom was revealed when I tried to ping the box - I've noticed a wrong IP address is showing.

nslookup/dig agreed with ping, resolving the url to the same wrong IP.

browsers (Chrome and Brave) are using a different DNS data than the commands in the terminal, that much is certain. The current hypothesis is that, somehow, my DNS cache got sour. I've tried (naively) to edit /etc/systemd/resolved.conf (DNS=8.8.8.8) and restarting resolved, but to no avail.

what else have I tried:

resolvectl flush-caches (reportedly what I need to clean the cache)

sudo systemctl restart systemd-resolved

resolvectl statistics (confirmed cache is clean)

but nslookup/dig still shows the weird IP...

What Am I Doing Wrong? Thank you for your time

7
  • 1
    What do you get with dig @8.8.8.8 xsubdomain.xdomain.com ? Also what do you get with ping -c 4 xsubdomain.xdomain.com ? Call the weird IP something like 1.2.3.4 and the correct address something like 4.3.2.1 if you wish to keep them private. Jun 24 at 5:40
  • 1
    What is the resolvectl status output?
    – K-att-
    Jun 24 at 8:28
  • @QuartzCristal dig shows the 1.2.3.4 , and ping does the same Jun 24 at 12:56
  • @K-att- it does show 8.8.8.8 Jun 24 at 13:01
  • 1
    Then, the world (well, at least google) has the wrong IP address for the domain. @alexakarpov Jun 24 at 18:20

1 Answer 1

0

Modern web browsers may use DNS-over-SSL or DNS-over-HTTPS services and bypass the regular DNS services configured in the operating system, as those are claimed to be more secure than regular DNS. In your case, this might be producing the expected, correct URL resolution.

If you have the nscd or unscd package installed in Ubuntu, it is a Name Server Cache Daemon - in that case, you might want to run sudo nscd -i hosts to flush its cache.

DNS diagnostics tools like nslookup and bind usually bypass the nscd cache and talk directly to the nameservers configured in /etc/resolv.conf. However, if your system is using systemd-resolved (as indicated by having nameserver 127.0.0.53 in /etc/resolv.conf and resolvectl status displaying the actual DNS settings instead of an error message) they might still be affected by the local cache. But resolvectl flush-caches should have already dealt with that cache.

As mentioned in the comments by QuartzCristal, dig @8.8.8.8 xsubdomain.xdomain.com tells the dig command to directly contact Google's 8.8.8.8 public DNS service, skipping any DNS services configured to the operating system. If that results in the correct IP address being displayed, then the problem is either within your local system or in the nameservers configured for it; if that also results in the wrong IP address, then something (possibly some malware) might be manipulating any unencrypted DNS traffic between you and the internet.

If the nameserver lines in your /etc/resolv.conf and/or the DNS server settings in resolvectl status output point to your router, it might be a good idea to reset your router: turn it off for 30 seconds or so, then turn it back on. You might want to see if there are security updates available for your router: there are some pieces of malware in the wild that attack routers with known vulnerabilities, and some versions of them might try redirecting the users' traffic, possibly for snooping or for injecting extra advertising. Your router might have been vulnerable to one of those.

As far as I know, most such malware infections in routers can be cleared by resetting the router, but if the vulnerable firmware version is still present in the router, it might get re-infected pretty quickly.

If your resolvectl status or /etc/resolv.conf file points to your Internet Service Provider's DNS servers, or if they point to your router and resetting the router and getting its firmware up to date did not help, then it's possible your ISP's DNS servers have a problem of some sort. In that case, you probably should contact your ISP and report the problem. While waiting for your ISP to fix things at their end, you might want to configure your Ubuntu and/or your router to use Google's 8.8.8.8 or other public DNS service instead of your ISP's nameservers, as a workaround.

1
  • Thank you very much. The problem indeed was local - between the keyboard and the chair. But thanks to all, I have learned a few things Jun 24 at 13:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.