What Mozilla is implementing here, I suspect, is RFC 6761 section 6.3 item 3, which says:
Name resolution APIs and libraries SHOULD recognize
localhost names as special and SHOULD always return
the IP loopback address for address queries and
negative responses for all other query types. Name
resolution APIs SHOULD NOT send queries for localhost
names to their configured caching DNS server(s).
A few notes:
1) The use of "the IP loopback address" is a bit weird in IPv4, of course.
2) It's hard to know which loopback address to return from an API without violating the "SHOULD NOT" part of this item.
There's really no way to win here. In theory Firefox could do the resolution as normal and then if it doesn't come back as loopback replace it with 127.0.0.1. That would be perfectly within the letter of the RFC, since none of the stuff above it MUST-level requirements, but probably not really within its spirit, since it would violate the "SHOULD NOT" bit.
Note that Firefox is not alone here; Chrome has the same behavior last I checked. https://bugzilla.mozilla.org/show_bug.cgi?id=1220810#c28 is a comment from one of the networking/security folks at Chrome about this precise issue, in case it's of interest.
> There's really no way to win here. In theory Firefox could do the resolution as normal and then if it doesn't come back as loopback replace it with 127.0.0.1. That would be perfectly within the letter of the RFC, since noneo f the stuff above it MUST-level requirements, but probably not really within its spirit, since it would violate the "SHOULD NOT" bit.
Could a check to see if the name is "localhost" or "*.localhost" suffice to satisfy the "SHOULD NOT" requirement?
From the bugzilla comment:
> It seems reasonable to extend that to support any /etc/hosts assertions that fall into 127.0.0.0/8, but that's not something we've heard a whole lot of interest in, though there have certainly been one-off requests.
That does seem reasonable to me, and it covers more than just "localhost" names.
I do understand that most uses probably do not require resolution of localhost names to other than 127.0.0.1. I may also be a little annoyed that I'll have to make some changes to something I've been doing for a long time.
> Could a check to see if the name is "localhost" or "*.localhost" suffice to satisfy the "SHOULD NOT" requirement?
To satisfy that requirement you have to check for those names and if that's what the name is _not_ ask the "configured caching DNS server". Which means you need to do what? Calling OS APIs will do that DNS server thing unless the name is in /etc/hosts. You could manually parse /etc/hosts and see whether it's there, I guess... That's basically Mike West's suggestion.
The parsing of /etc/hosts would presumably have to exactly match the parsing that the system DNS code does, including error recovery behavior, etc. Otherwise you might treat as localhost something that is not mapped to localhost in /etc/hosts or vice versa. This is all doable, but it's not something I'd want to do if I were tasked with this decision, absent strong indicators that this work and the extra maintenance burden and attack surface (every parser ever is attack surface) is really worth it.
If the OS API calls a DNS server, that's not really the higher-level API’s problem. If you've decided to override OS APIs and do your own ground up implementation, then you basically need to do everything an OS-level API would do if it was behaving correctly. So you either need to parse all the appropriate system files (hosts, nsswitch.conf, etc.) with the appropriate special handling of localhost domains, or have your own equivalent, app specific configuration.
The “what are you supposed to do?” complaint seems to be complaining that replacing the core OS-level name resolution facility to avoid the possibility that it doesn't comply with one spec recommendation while avoiding loss of other desirable features involves quite bit of complexity. Which, yeah, it does. The whole reason to have OS level services like that is to prevent every app that does networking from having to reimplement basic services.
Keep in mind also that in many cases (e.g. when using DNS over HTTPS), Firefox is in fact not using the OS API, and is directly hitting a DNS server instead. Of course in that case whatever is happening in /etc/hosts is either getting ignored anyway or Firefox is parsing it anyway...
Sure there is. Consulting the local hosts file isn't contacting the configured caching DNS server, so there is no SHOULD or SHOULD NOT violated by consulting hosts and then defaulting 127.0.0.1 if a more specific address in the loopback address range is not provided.
(Relying on a system-level name resolution API also isn't contacting the caching DNS server, and if that API behaves according to spec, including potentially relying on local resources loke hosts but not remote DNS servers for localhost domains, that would also work.)
> and if that API behaves according to spec, including potentially relying on local resources loke hosts but not remote DNS servers for localhost domains
Yes, but that's only relevant if Firefox were mapping from IP addresses to something. Here it's mapping to an IP address, so 127.0.0.1 is fine (even though, e.g., 127.0.0.42 would also have been fine).
https://www.iana.org/assignments/iana-ipv4-special-registry/...