Hostnames resolution IPFire DNS

Networking DNS
1

Hi,

the hostname resolution via webbrowsers, just like firefox or edge, doesn’t work without putting the protocol type in front of the hostname.

Whenever I input only the hostname or even hostname.domainname, firefox or edge does not look for the local IP, but redirects to a search engine. Only if I put the protocol type in front of it, like https:\hostname, it works. I guess this must be because of the ipfire DNS.

Any idea why’s that and how to fix this?

Cheers

2

I do not think this has anything to do with IPFire. Don’t know about edge, but for Firefox this behavior was introduced with version 84, quote:

Firefox now ensures that localhost URLs — such as http://localhost/ and http://dev.localhost/ — refer to the local host’s loopback interface (e.g. http://127.0.0.1). As a result, resources loaded from localhost are now assumed to have been delivered securely (see Secure contexts), and also will not be treated as mixed content

as part of their effort to put https everywhere (http is classified mixed content).

To summarize, you either put http:// in front, or .localhost at the end, for it to do a domain resolution. As you noticed, .localdomain is ignored, don’t understand why. This guy did all the research that I am summarizing here.

3 Likes
3

Oh no not again.

.localhost doen’t work. Damn alway write stupid https:\ is really enoying.

4

yes, it does. I have tested it.

5

I’ve just tested it with several domain names. None worked.

6

If you put .localhost, it does not send it to the preferred search engines, but it try to resolve it. Unless you have a web server running on your 127.0.0.1 it gives you an error. Have a look at that blog post and you see this discussed in much deeper detail.

1 Like
7

With localhost I won’t be able to access other domains.

8

correct. Also, it is even longer than http://. My post intended to describe the issue you raised in an accurate way, not giving you a work around. Believe me, I share the frustration.

1 Like
9

Jep I will start to create lots of bookmarks. Thx for the enlightenment.

10

I also wonder if this influences the wpad DNS based resolution for automatic proxy detection. I could not find out this part of the story.

To clarify, Firefox would not auto-detect the wpad proxy configuration by DHCP, but it is supposed to look by DNS to wpad or wpad.localdomain, which it does not unless preceded by http://. Therefore, does it work, meaning does it try to look for a wpad proxy description in the localdomain? My tests so far are inconclusive, however I am leaning toward a no.

I am tempted to start using a fantasy domain name instead of .localdomain which I believe it is not a recommended behavior.

1 Like
11

No, changes nothing.

Even the FQDN don’t work. Strange.