Score:0

Windows 10 / Chrome: HTTP browser request to IP address differs from same request to hostname

ru flag

Agaoin, this is on Windows 10. I'm bringing in a new Ubuntu test web server (hpmicro1.lovelady.com) to our internal network, which is all in the lovelady.com domain. There's a DNS server on another machine that handles all DNS lookups.

PC configuration for DNS is:

DNS configuration

When I ping the web server by name, I get 192.168.1.5:

DNS resolution

I have rebooted within the last five minutes.

Now, at a Chrome or Firefox or even Edge (which I usually avoid like the plague) web browser, when I access the server by name, I get a failure:

Failed when using hostname

But when I access via IP address, I have success:

Success via IP address

So it looks to me like the DNS lookup either isn't happening at ANY of the web browsers, or they're getting results different from the commandline ping. How can I diagnose this, and - more to the point - how can it be fixed?

Michael Hampton avatar
cz flag
You appear to be accessing two completely different machines.
in flag
Could also be a wrong VirtualHost configuration on the server.
ru flag
Yes, that is the point, @MichaelHampton. How can that be? How can I find what Chrome (or Firefox or Edge) is using for an IP address here, and how can I cause the right values to be used?
ru flag
Not sure what you're saying @GeraldSchneider. Since this is apparently two different servers (one mine, and one somewhere out there in etherland...), what are you suggesting I have a look at to resolve? The one that belongs to me (definitely, on the 192.168 net) seems to work fine....
in flag
Check the http headers in the developer tools of your browser. Usually the remote address is listed there
Michael Hampton avatar
cz flag
The rest of the world thinks the IP address is 206.188.192.244 because that's what it is in the global DNS. What's going on here?
in flag
Are your browsers configured to use DoH?
ru flag
@MichaelHampton the rest of the world sees the catchall for lovelady.com. Internally, there is a DNS server (I think I mentioned) that also supplies addresses for other servers that the rest of the world does not see. Among them: hpmicro1, at 192.168.1.5.
ru flag
Hi, Gerald. I have never touched the configuration of Edge or Firefox. And limited configuration of Chrome. I have never configured DNS over HTTP(s) on any of them. Thanks.
ru flag
Oh, and I neglected to mention in case anyone was curious… all this lovelady.com stuff is indeed mine.
ru flag
OK, thanks for the help @GeraldSchneider regarding developer tools. Had to turn on some stuff to see, but this is addressing the 206.188... address mentioned above. Since this same system, in the "DOS BOX" shows the correct resolution of this host to 192.168.... I'm left to wonder why _all three_ browsers seem to be addressing the wrong location. (This is not to mention the fact that if I address www.lovelady.com [same address] it all works fine....) But I want to focus on why the wrong address from Windows
Score:1
cv flag

Apparently under some circumstances, the Windows client would try to get the address of HPMICRO1.... from 8.8.8.8

This isn't a Windows bug, this is by design. You configured the Windows DNS client with a primary and a secondary DNS server. The primary server failed to respond so the Windows DNS client queried the secondary server. That's the perfectly desired behavior. Would you rather it fail on querying the primary and not query the secondary? Are you implying that other DNS clients don't behave the same? That they'll only query a single DNS server? You seem to be trying to make this a "Windows is at fault" screed when in fact, the Windows DNS client is behaving exactly as it was designed to. If the primary server doesn't respond, then try the secondary, then the tertiary, etc. This isn't a client issue, it's a server issue. Check your DNS server, that's where the problem lies.

I'm not sure what caused Windows to do that.

I've given you a link to the article that explains the behavior. It isn't a mystery. It's working as it was designed to, the same way every other DNS client resolver is designed for the same behavior. Query the primary, no response, query the secondary, and so on, and so on.

ru flag
There is no evidence that the DNS failed to respond.. only that windows had two results concurrently. Shouldn’t be, and wouldn’t on other platforms. Not like others as far as caching results is concerned, but I’m done with this. The solution was to eliminate the second DNS. Why that results in a need to defend Windows is a mystery I won’t further ponder.
joeqwerty avatar
cv flag
"There is no evidence that the DNS failed to respond". Likewise, you haven't presented evidence that it did respond. I'm merely telling you what the Windows DNS client is designed to do and cited Microsoft's documentation. Take it as you will. The Windows DNS client is not at fault here.
Score:0
ru flag

Apparently that DNS configuration I showed in the question was a poor idea. Removing the secondary DNS server resolved the issue. Apparently under some circumstances, the Windows client would try to get the address of HPMICRO1.... from 8.8.8.8, and of course that returned the catchall. I'm not sure what caused Windows to do that (I doubt anyone knows why Windows does anything ;| ) but after consideration, that secondary DNS was never going to do what I wanted.

This problem has been resolved by removal of the external (secondary) DNS from the configuration.

joeqwerty avatar
cv flag
This isn't a Windows DNS client issue. This is a DNS server issue in that the DNS server configured as the primary DNS server for the DNS client isn't responding to the query. That's where I'd look for the problem. - https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/dns-client-resolution-timeouts
ru flag
Agreed. Probably not a Windows issue in this case. But nobody can prove (at this point, nor will I put more time into it) that Windows did what it was supposed to do. Anyway, as I implied, I consider it a client configuration issue. @joeqwerty
ru flag
@joeqwerty I will say that most OS will use one source, with some sort of cache, for DNS resolutions. Windows returning one address for PING and a different address for HTTP requests demonstrates that that’s not happening. And I doubt that is supportable as a feature, which puts it on the other side of that feature/bug line IMO.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.