英文:
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 容器:
- 一个是我们的主应用程序,运行在 Amazon Linux 2 上(以尽可能接近生产环境)。
- 另一个包含另一个 HTTP 服务的模拟。
由于模拟需要由主应用程序从后端访问,同时也需要由前端访问,将模拟命名为 app.localhost 允许:
- 在前端使用我们无需创建额外的
/etc/hosts
条目的事实。 - 前端和后端都使用相同的名称/环境变量包含主机名,这在生产环境中也是如此。
我已经检查过的内容
- 两者都具有相同的
/etc/host.conf
配置。 getent hosts app.localhost
对于两者都返回172.4.0.2
。- Amazon Linux 2 的 glibc 版本是
2.34
,centos 是2.28
,ubuntu 是2.35
,因此至少在 glibc 中没有行为变化。 - 更改
/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
- one with our main application, running on a Amazon Linux 2 (to be as close as possible to production environment)
- 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
- on the frontend to use the fact that we don't need to create extra /etc/hosts entry
- both frontend and backend use the same name/env variable containing the hostname, which is also the case in production
What I've checked
- both have the same `/etc/host.conf config
getent hosts app.localhost
for both returns172.4.0.2
- 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 - 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)
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论