Comment by rascul | Hacker News Reader

Comment by rascul | Hacker News Reader

Parent Full thread

> 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.

Thank you for your research and your replies.

> 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.

> Calling OS APIs will do that DNS server thing

Calling the OS APIs isn't calling a DNS server.

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...

Reply on news.ycombinator.com