In a nutshell: my laptop and desktop cannot resolve my own sub-domain pointing back to my external IP via WiFi - but they can if they are connected via cable. WTH?
I am experiencing a strange DNS issue that appeared more or less over night (no issue before a vacation, issue after vacation). Maybe someone’s got an idea?
I run a Pihole for DNS and a Nextcloud server behind a DSL router/modem which updates my IP to a subdomain I use for my Nextcloud for internal and external access. In the internal network I am working with a desktop and a laptop. Both can access the web and internal net via WiFi or LAN. So far so good.
Since I returned from traveling (simply indicating that a change must have happened while I was away), the external domain, say nextcloud.foobar.com, can only be accessed by the laptop and the desktop when connected via cable to the DSL router/modem. Not, if they are connected via WiFi, to the same DSL router/modem.
Until now, I have found out that it’s not an issue related to the machine (same problem on both laptop and desktop) or operating system/install (same problem on both Windows and Linux on both machines). The interesting thing is that I am able to reach my own external IP and my server through that IP over WiFi, but not via the domain. So it should be a DNS problem, or, more specifically, a newly occurred difference in how the DSL router handles DNS on WiFi vs. on LAN. It might have something to do with that I have automatic updates on on the Pihole server and the DSL router.
I wondered if anyone here would have an idea on what to try next. Maybe this sounds familiar to someone.
Has the router updated itself, whilst you were away?
Has it taken to connecting your devices to the guest Wi-Fi and they don’t have access to the PiHole?
Has the router changed the DHCP configuration? Check the router’s DNS setting and the DHCP settings.
Are you getting the correct IP address (range), when you connect via Wi-Fi?
Is my understanding correct, on Ethernet, you can access nextcloud.foobar.com and 1.2.3.4 and on Wi-Fi, the nextcloud.foobar.com is not resolving, but you can access it through 1.2.3.4?
That certainly sounds like the Wi-Fi is either connecting to the guest network, or the router has changed the DHCP settings, or its DNS server has been reset to an external provider.
No. The guest network is not configured / turned off.
No. Its DHCP is turned off (handled by the PiHole). Itself is set to use the DNS of the telco provider (it should not need any, all other clients are handled through the PiHole DNS).
Yes. It’s the familiar range in the 192.168.2.x .
Yes, indeed. That’s what’s happening. In the terminal on Manjaro, I can happily ping google.com but I cannot ping foobar.com or nextcloud.foobar.com with it returning “ping: foobar.com: name or service unknown” However I can ping without problem my external IP.
Yeah, it sounds like it. But it’s not a), don’t think it’s b), and c) is still the same with the PiHole.
There is, however, something weird going on with the DynDNS updating. The FritzBox reports “301 - permanently moved” when updating. However - the updating process seems intact… I shall investigate with the domain provider on their updating API.
Hmm… It’s particularly weird that two machines have the same problem in both operating systems. This really brings me back to the router. Cause for the PiHole it should be all the same - no matter if the resolution request comes through WiFi or cable at the router - it is connected via cable.
Strange and wonderous…
Maybe I shall simply reboot the router once my wife is off her next call.
Sadly, yes - 192.168.2.2 in both cases. In the Linux machine, there is an IPv6 address added as a second DNS which I find hard to identify. I also have lines starting with “search” and “domain” which state my version of “foobar.com”. In the logs of PiHole, I have found that there are requests for “nextcloud.foobar.com.foobar.com” when I enter “nextcloud.foobar.com” which indicates there is an automatic appending happening somehow. Maybe that’s the culprit?
Restarting the router did not help. To the contrary: I believe, now the situation is equal on wired and wifi. At least, I cannot reach the domain anymore. Which is worse in terms of a situation but better in terms of making sense. So there is not really a difference between wifi and wired, just that wired hung on a little longer while in wifi, the problem materialised quicker.
However, there’s some additional development in terms of theory: I wonder if the Nextcloud box is correctly configured or whether it changed somehow. The give-away is that it cannot find itself via its domain name either. Go figure! I think it has forgotten its own name.
Current theory is that there’s been an update that fixed the previous behaviour of accepting another host name when called than the real machine name. The host name of the Nextcloud server is actually “nextcloud” but I am trying to access it by using the external “server.foobar.com”.
Reason for this belief is that I can ping nextcloud.foobar.com (which pings 127.0.0.1) but not server.foobar.com on that machine (name or service unknown). It’s like me calling myself Fred while knowing that my name is Mike. It wants to be called Mike.
Plus, I only need to ping nextcloud, not nextcloud.foobar.com - so automatic appending is happening.
Are you using a DynDNS service? Is it possible the router stopped updating somehow and the wired connection was still caching the old registration?
I had a thought about the internal domain being different on wired and Wi-Fi, but now the problem is on both connections, that is unlikely and that would only be for internal services anyway. E.g. you have have a comain of mydomain.local, so the DNS automatically adds mydomain.local to all local lookups (E.g. myserver becomes myserver.mydomain.local automatically). If, somehow, the Wi-Fi had received a different domain somehow, such as mywifi.local, searching for myserver would turn it into myserver.mywifi.local, thus not finding it, you would need to put in the long name, myserver.mydomain.local instead.
But, as I said, that seems to now be excluded, with the router restart.
->>> Just seen your reply. Yes, that looks like the answer. If it is using Apache or Nginx virtual hosts, they need to have the exact name of the server passed in the packet, as well as the IP address. If the name doesn’t match, Apache and Nginx will refuse the connection.
I think you can set up aliases in the hostname, to get it to work, but I’m not a Nextcloud user, so can’t help with the configuration there.
Thanks a bunch, @big_D , you’ve been a great help!
I really think I should read up on naming my machines correctly as well as how domains work. I’ve always simply used hostnames that came to mind when installing and then did not pay too much attention when associating the machine to an external domain. Thought it’s not that important since, in the end, much runs through IPs anyways. But I think that the Debian System that my Nextcloud runs must have updated itself to become more critical about precision here.
The problem is likely to be with the naming. I will dig into this and update with - hopefully - good news!
But, granted, I feel like I cheated. I browsed through the PieHole settings and found the custom local DNS records. Added nextcloud.foobar.com there and linked it to the IP of the server. It’s not elegantly magical that it works, but it works again. Yay! (Wonder how it worked before, but all is a learning process…)
At the same time, I shall review the naming of my servers and put them in order. So ein Durcheinander hier…
It’s possible your DynDNS record is not working (the error you mentioned) and by random chance your WiFi devices have expired the old record sooner than the non-WiFi devices…?
Hmm - possibly. But the response of the ping command seemed more decisively and immediately refuting than merely timing out as it would have likely been doing if I had pinged just someone else (my IP comes from the ISP’s IP pool so if the DynDNS does not work, I’m usually pinging someone else’s machine). Granted, that could have also been blocked. But my DNS ttl is only 15 minutes so… refreshing should happen frequently. Set it to 15 minutes to minimise the downtime after the daily reconnect. But hey - I am not sure.
What’s even more unusual is that my phone could connect to the server via app until I restarted the router. The phone was connected via WiFi as well. Which “should not have worked” when staying within the other symptoms.
I chalk it up to that I still have to learn much about even my little local DNS and domain set-up. Must have screwed it up somehow. Glad we found a solution.
Just want to say what a pleasure it is to follow two highly intelligent people work through a technical problem. Having spent the last week running a clean install on my iMac because it stopped communicating with the outside world then reinstalling all my apps and data and fixing bugs along the way, I deeply sympathize.
That sounds so familiar! It truly takes (took me) ages to get from “fresh reinstall” version of fixing a problem to trying to understand and repair stuff. Part of what is helping me was to lean more and more on my own systems which would be an ever-increasing pain to completely set up from scratch. Takes a lot of patience though - and helpful souls like big_D!
I have a 2014 27" Retina iMac. The new macOS version, Monterey, will not run on this machine. There may be a genuine reason but I suspect it’s just Apple’s way to maintain its revenue stream. Anyway, knowing that a new large screen iMac with Apple Silicon was most likely to come in 2022 I decided I would replace this ‘old’ machine. I have been having a number of weird problems since I installed Big Sur so realized that I would have to build the new machine from scratch and not migrate via Time Machine.
As a result, and after a long time figuring out how to configure the new machine with all the apps, settings, parameters, and data I use, I produced a very long set of step-by-step instructions. In the event I had to do the clean install on the current machine and the instructions were useful but far from perfect.
Two pieces of good news followed. First, all the weird Big Sur problems vanished and now when the new machine arrives I can use Time Machine for the migration which should be a simpler operation.
Even found out everything about hostnamectl’s icon names. This thing should come back to life soon…