Closed Bug 1619303 Opened 5 years ago Closed 5 years ago

Mapping a fixed IP to a host with no need for repeated DNS requests

Categories

(Core :: Networking: DNS, enhancement)

74 Branch
enhancement
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: mtanalin, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0

Steps to reproduce:

Many sites have fixed IPs, so it’s enough to use DNS just once for such sites, and then use that IP forever without doing any further DNS requests over and over again — neither via regular DNS nor via DoH.

So it would be nice for Firefox to provide a way for user to enable such behavior for selected hosts.

For full flexibility, it would also be nice to have a way to manually map an IP for a host, with no even need for a single DNS request for such manually mapped hosts.

UI-wise, it could be a table with two columns — “Host” and “IP” — with an own “Edit” button for each item and a general “Add” button for adding a new item with ability to change host and IP. This table could be accessible via e.g. a item like “Host/IP mapping” of the “...” menu at the right of the URL bar.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Networking: DNS
Product: Firefox → Core

I've recently added a support for such a feature in the platform, but the use case in comment 0 doesn't seem very compelling.
Suppose a website has the same IP for a year, but they decide to change it - could lead to breakage.
Why do you think such a feature is needed?

Flags: needinfo?(mtanalin)
See Also: → 1618130

(In reply to Valentin Gosu [:valentin] (he/him) from comment #2)

Besides removing a redundant DNS-request delay (that happens on a regular basis even if DNS requests are cached for some time), I believe the feature could further improve user security by not leaking visited hosts to DNS servers (either regular or DoH) with no need.

For example, if the user has a personal site, the fact that the user visits the site on a regular basis may indirectly expose his identity to DNS server and therefore disclose other sites this specific user visits in relation to the user personality disclosed by the personal site.

In case of breakage due to a rare/unlikely IP change (I’m talking solely about fixed-single-IP sites, not about CDN-powered sites in any way), new IP could just be retrieved by an explicit user request — e.g. via a button in the table user interface I described above or/and on the internal service page of Firefox shown when a host is not available.

Fwiw, I would be OK with the feature available just for addons and not exposed in the main Firefox UI by default, though I believe many advanced users (such as those who like/use DoH) would like the ability for such explicit host-IP mapping with any DNS requests guaranteedly prevented for corresponding hosts.

Flags: needinfo?(mtanalin)

This threat model doesn't really apply to 99.999% of Firefox users.
Even really technical users as myself would rarely have a need for this to be implemented in Firefox.
For people who think this is useful, it could be implemented either as a proxy running on the user's machine, or as a local DoH server.
The problem is not the functionality itself, which already exists, but the trouble of maintaining the extra bits of UI.

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX

(In reply to Valentin Gosu [:valentin] (he/him) from comment #4)

This threat model doesn't really apply to 99.999% of Firefox users.
Even really technical users as myself would rarely have a need for this to be implemented in Firefox.

I guess this is just an assumption. Do you have some concrete data?

The problem is not the functionality itself, which already exists, but the trouble of maintaining the extra bits of UI.

As I said, I would be OK with an addon API, with no UI in Firefox itself. Thanks for your attention.

local DoH server

Looks like a viable way to go if there is no other way.

You need to log in before you can comment on or make changes to this bug.