Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resolve foo.localhost as localhost #477

Closed
mcollina opened this issue Jul 22, 2022 · 6 comments
Closed

Resolve foo.localhost as localhost #477

mcollina opened this issue Jul 22, 2022 · 6 comments

Comments

@mcollina
Copy link

From nodejs/undici#1571:

Bug Description

In my local development env I got Hasura running and responding on hasura.localhost. This works fine in Chrome, I can open the web UI and do stuff from there. However this does not seem to work when trying to query the api using undici (see reproducible by below).

This seems to break RFC-6761:

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

So it seems that Chrome resolves hasura.localhost as the localhost loopback, while Node.js and in in turn c-ares do not.

From a quick look at it,

/* RFC6761 section 6.3 #3 states that "Name resolution APIs and libraries
* SHOULD recognize localhost names as special and SHOULD always return the
* IP loopback address for address queries".
* We will also ignore ALL errors when trying to resolve localhost, such
* as permissions errors reading /etc/hosts or a malformed /etc/hosts */
if (status != ARES_SUCCESS && strcmp(hquery->name, "localhost") == 0)
{
return ares__addrinfo_localhost(hquery->name, hquery->port,
&hquery->hints, hquery->ai);
}
does not handle this case.

@bradh352
Copy link
Member

The part of the RFC you are referencing is talking about just "localhost". I've seen no standard stating there is such a thing as a subdomain of localhost or how to treat those.

If you drop to a command line and run ping hasura.localhost what happens?

On my own system:

$ ping hasura.localhost
ping: cannot resolve hasura.localhost: Unknown host

If I edit /etc/hosts and add it as an alias, it works.

So either my system resolver (which is not c-ares, this happens to be MacOS at this time) is also broken, or Chrome is doing something special.

@bradh352
Copy link
Member

Upon further research, you may actually be encountering non-standard extensions introduced by systemd: https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html#Synthetic%20Records

@dimbleby
Copy link
Contributor

The part of the RFC you are referencing is talking about just "localhost".

but what it says is

The domain "localhost." and any names falling within ".localhost." ...

?

@bradh352
Copy link
Member

Interesting, missed the falling within ".localhost.", wonder why this isn't universally supported then.

@mcollina
Copy link
Author

I was extremely surprised when reading that RFC, which seems pretty clear and points at Chrome implementing the correct behavior.

@mcollina
Copy link
Author

Upon further research, you may actually be encountering non-standard extensions introduced by systemd: https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html#Synthetic%20Records

Chrome implements this on Mac too, it's not Systemd specific.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants