3 ms·

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

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

dragonwriter 6y ago
> 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.
- bzbarsky 6y ago
  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...

dragonwriter 6y ago

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

bzbarsky 6y ago
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...