app.localhost is still resolved by curl as 127.0.0.1 though overriden in /etc/hosts on Amazon Linux 2

huangapple go评论62阅读模式
英文:

app.localhost is still resolved by curl as 127.0.0.1 though overriden in /etc/hosts on Amazon Linux 2

问题

Amazon Linux 2 的名称解析器是否有配置选项可以更改,以便不忽略关于 localhost 子域的条目?

即目前的行为是:

docker run -it amazonlinux:2023 /bin/bash  -c "echo '172.4.0.2 app.localhost' >> /etc/hosts ; curl -v app.localhost "
*   Trying 127.0.0.1:80...

而 centos(或者 ubuntu)的行为是 "如预期":

docker run -it centos /bin/bash  -c "echo '172.4.0.2 app.localhost' >> /etc/hosts ; curl -v app.localhost "
*   Trying 172.4.0.2...

为什么我需要这个

在我们的本地开发环境中,我有两个 Docker 容器:

  1. 一个是我们的主应用程序,运行在 Amazon Linux 2 上(以尽可能接近生产环境)。
  2. 另一个包含另一个 HTTP 服务的模拟。

由于模拟需要由主应用程序从后端访问,同时也需要由前端访问,将模拟命名为 app.localhost 允许:

  1. 在前端使用我们无需创建额外的 /etc/hosts 条目的事实。
  2. 前端和后端都使用相同的名称/环境变量包含主机名,这在生产环境中也是如此。

我已经检查过的内容

  1. 两者都具有相同的 /etc/host.conf 配置。
  2. getent hosts app.localhost 对于两者都返回 172.4.0.2
  3. Amazon Linux 2 的 glibc 版本是 2.34,centos 是 2.28,ubuntu 是 2.35,因此至少在 glibc 中没有行为变化。
  4. 更改 /etc/nsswitch.conf 以匹配我的 ubuntu 的配置:
passwd:         files systemd
group:          files systemd
shadow:         files
gshadow:        files

hosts:          files mdns4_minimal [NOTFOUND=return] dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

是否还有其他可能影响本地主机名解析的地方?

英文:

Is there a config to change the behaviour of the name resolver of Amazon Linux 2 to not ignore entry about localhost subdomains ?

i.e currently it does :

docker run -it amazonlinux:2023 /bin/bash  -c "echo '172.4.0.2 app.localhost' >> /etc/hosts ; curl -v app.localhost "

*   Trying 127.0.0.1:80...

while centos (or ubuntu) works "as expected"

docker run -it centos /bin/bash  -c "echo '172.4.0.2 app.localhost' >> /etc/hosts ; curl -v app.localhost "
*   Trying 172.4.0.2...

Why do I need this

On our local development environment I have 2 docker

  1. one with our main application, running on a Amazon Linux 2 (to be as close as possible to production environment)
  2. one containing a mock of an other HTTP service

as the mock needs to be accessed both by the main application from the backend, but also by the frontend, having the mock being named app.localhost allows

  1. on the frontend to use the fact that we don't need to create extra /etc/hosts entry
  2. both frontend and backend use the same name/env variable containing the hostname, which is also the case in production

What I've checked

  1. both have the same `/etc/host.conf config
  2. getent hosts app.localhost for both returns 172.4.0.2
  3. the glic version of Amazon Linux 2 is 2.34 and centos 2.28, and ubuntu 2.35 , so at least it's not a behaviour change in glibc
  4. change the /etc/nsswitch.conf to match the one of my ubuntu
passwd:         files systemd
group:          files systemd
shadow:         files
gshadow:        files

hosts:          files mdns4_minimal [NOTFOUND=return] dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

Is there other places that may affect how localhost names are resolved ?

答案1

得分: 2

The difference comes from the version of curl:

查看 https://daniel.haxx.se/blog/2021/05/31/curl-localhost-as-a-local-host/,更具体地说是这个提交 https://github.com/curl/curl/commit/b5c0fe20e370ea2e5791fce4cedb34a71bc784e5#diff-e0b647f3e21a7fb58400dcec74f381d2fe16ca41e983240c15fc1243c574dbf9R733

即对于以 .localhost 结尾的域名,curl 直接返回 127.0.0.1 并绕过所有名称解析。

他们的理由是 RFC 6761 解释了:

名称解析的API和库应该将localhost名称识别为特殊名称,对于地址查询应该始终返回IP回环地址,并对所有其他查询类型的负响应。名称解析的API不应将localhost名称的查询发送到其配置的缓存DNS服务器。

英文:

The difference comes from the version of curl

see https://daniel.haxx.se/blog/2021/05/31/curl-localhost-as-a-local-host/ and more specifically this commit https://github.com/curl/curl/commit/b5c0fe20e370ea2e5791fce4cedb34a71bc784e5#diff-e0b647f3e21a7fb58400dcec74f381d2fe16ca41e983240c15fc1243c574dbf9R733

i.e for domain name ending with .localhost curl directly returns 127.0.0.1 and bypass all name resolving.

Their justification is that RFC 6761 explains

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

huangapple
  • 本文由 发表于 2023年6月8日 19:25:20
  • 转载请务必保留本文链接:https://go.coder-hub.com/76431362.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定