☰

浏览器和 ISP 之间的 TLD 处理是不透明的，依赖于 127.0.0.1

tag-icon • tag-icon networking macos dns
浏览器和 ISP 之间的 TLD 处理是不透明的，依赖于 127.0.0.1

观察与 TLD 相关的操作系统之间的不同行为。
具体来说，是 MacOS 10.9.5 和 10.13.6。
两者都通过同一个 Wi-Fi 热点连接，在 Apple 的网络配置选项卡下具有相同的设置，包括相同的 DNS 服务器。

.dev使用不同的操作系统但相同的 ISP 连接对TLD进行 ping 或搜索将返回不同的结果：

  • 10.9.5 ping 返回 127.0.0.1。浏览器无法连接到具有该 TLD 的域。
  • 10.13.6 ping 返回该域的正确 IP 地址。浏览器连接到该域。
  • 使用 VPN，在 10.9.5 上，浏览器连接到域，但 ping遗迹指向 127.0.0.1

移至另一个 TLD .tv：

  • 10.9.5 ping 返回 127.0.0.1。浏览器无法连接到具有该 TLD 的域。
  • 10.13.6 ping 返回 127.0.0.1。浏览器无法连接到具有该 TLD 的域。
  • 使用 VPN，在 10.9.5 上，浏览器连接到域

鉴于 ISP 连接相同，我得出结论，这里有多个因素在起作用：
a）操作系统似乎有自然过时且缺少一些的 TLD 列表，因此查找不是受到影响并且浏览器无法连接。有人质疑这是否有意义……这些可以以某种方式更新吗 - 即使对于旧的操作系统？
b) VPN 的机制与 ISP 不同 - 为什么 ping 仍然返回 127.0.0.1 但 VPN 却忽略了这一点并仍然进行路由？

因此，第二个问题变成了，在考虑更新 TLD 列表之后，是否有另一种方法可以让 ISP ping/查找任何 TLD（可能忽略 TLD 列表）？

更新

考虑到要检查的项目可能很长，我按顺序检查了文件。然后倒着检查。

有趣的是，dscacheutil -q host -a name nbc.tv 指向德国的 AWS 服务器（我猜是 CDN）。但是，onhockey.tv和google.dev指向 127.0.0.1，ping 也是如此。/etc/resolver.conf 有一个条目nameserver 192.168.43.1，恰好是通过操作系统的网络 DNS 服务器接口定义的条目。

host nbc.tv 192.168.43.1

解析为 AWS 服务器3.64.163.50
，但是，按照dscacheutil命令，查询其他 tv 域和 dev 域的主机会返回

has address 127.0.0.1
Using domain server:
Name: 192.168.43.1
Address: 192.168.43.1#53
Aliases:

/etc/resolver确实有两个文件dev并test放在那里generated by Pow 用于本地提供项目

nameserver 127.0.0.1
port 20560

这些都不再需要了。虽然pow很久以前就卸载了，转而使用ngrok服务，但奇怪的是这些落后者仍然存在。一旦删除，就解决了域的问题.dev。但不是onhockey.tv域。

因此，这是一个多方面的问题。

dscl /Search -read /Computers/onhockey.tv
> DS Error: -14136 (eDSRecordNotFound)

因此/etc/hosts文件仍然是罪魁祸首。有些是故意放在那里的，有些则不是。删除后者仍然无法解析域onhockey.tv。

答案1

旧版本的 macOS 可以很好地解析新 TLD 中的地址；一定是其他原因导致了此问题。我考虑了一下可能导致此问题的原因，下面我将提供一些故障排除建议。

macOS 的解析器不会对不同的 TLD 做出不同处理（除了 .local，它是为 Bonjour/mDNS 本地名称保留的）；它只是将查询发送到 DNS 服务器并让其进行处理。以下是我碰巧正在运行的 10.5.8 系统中 ping .tv 和 .dev 域的示例：

Leopard-MacBook:~ gordon$ ping -c1 nbc.tv
PING nbc.tv (52.58.78.16): 56 data bytes
64 bytes from 52.58.78.16: icmp_seq=0 ttl=29 time=169.152 ms

--- nbc.tv ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 169.152/169.152/169.152/0.000 ms

Leopard-MacBook:~ gordon$ ping -c1 google.dev
PING google.dev (216.239.32.27): 56 data bytes
64 bytes from 216.239.32.27: icmp_seq=0 ttl=58 time=14.625 ms

--- google.dev ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 14.625/14.625/14.625/0.000 ms

另外，尝试使用无法查找的 TLD（因为它不存在）不会提供 127.0.0.1，而会导致查找失败：

Leopard-MacBook:~ gordon$ ping -c1 google.wibble
ping: cannot resolve google.wibble: Unknown host

因此，您收到的 127.0.0.1 必须来自某处；操作系统的解析器并不是凭空捏造出来的。问题是，它从何而来？

我首先要检查的是 /etc/hosts 文件。那里的条目会覆盖 DNS，因此可能需要删除那里的任何相关内容。也可以（但很少见）在本地“目录”域中创建条目；例如，使用 进行检查dscl /Search -read /Computers/whatever.tv。

接下来，检查您是否有 /etc/resolver 目录；其中的文件可以根据每个域（包括每个 TLD）覆盖常规 DNS 配置。

接下来，您是否配置了多个 DNS 服务器？macOS 的解析器使用奇怪的循环/DNS 服务器抽签系统在多个服务器之间进行选择，如果它们给出不同的答案，您将得到不一致的结果。使用 检查 /etc/resolv.conf 中列出的服务器host。如果您有任何 IPv6 服务器，也请检查它们：

Leopard-MacBook:~ gordon$ host nbc.tv 192.168.1.1
Using domain server:
Name: 192.168.1.1
Address: 192.168.1.1#53
Aliases: 

nbc.tv has address 52.58.78.16
nbc.tv has IPv6 address 2a05:d014:9da:8c10:306e:3e07:a16f:a552

Leopard-MacBook:~ gordon$ host nbc.tv 2001:558:feed::1
Using domain server:
Name: 2001:558:feed::1
Address: 2001:558:feed::1#53
Aliases: 

nbc.tv has address 52.58.78.16
nbc.tv has IPv6 address 2a05:d014:9da:8c10:306e:3e07:a16f:a552

将其与使用以下命令从系统解析器获得的结果进行比较dscacheutil：

Leopard-MacBook:~ gordon$ dscacheutil -q host -a name nbc.tv
name: nbc.tv
ipv6_address: 2a05:d014:9da:8c10:306e:3e07:a16f:a552

name: nbc.tv
ip_address: 52.58.78.16

dscacheutil在显示系统解析器所看到的内容方面比在几个方面做得更好ping：它显示 IPv6 地址以及 IPv4（尽管有一个ping6命令），如果有多个可用地址，ping则只会显示其中一个。

说到 IPv6，这是另一个可能造成不一致的原因：Apple 一直在切换操作系统的各个部分，使其更倾向于使用 IPv6 而不是 IPv4，因此，您的设置可能会使较新的操作系统正常运行，因为您的 IPv6 正常运行，而较新的操作系统会首先尝试 IPv6。因此，检查两个都（请注意，示例域 nbc.tv 和 google.dev 同时具有 IPv4 和 IPv6 地址，因此它们容易受到这种不一致的影响）。

哦，我还想到了另一个可能的不一致之处：VPN 配置是否包含 Web 代理？如果是，这或许可以解释为什么它能通过代理工作（如果浏览器可以访问代理，并且那可以解析并到达实际的Web服务器）。

相关内容