☰

无法再通过无 IP 主机名进行 ssh，使用 wan ip 时，nslookup 给出 nxdomain

tag-icon • tag-icon ssh ip hostname wan ddns
无法再通过无 IP 主机名进行 ssh，使用 wan ip 时，nslookup 给出 nxdomain

在对该论坛进行广泛搜索而无果后，我在此发布了我的问题。

我家里有一台运行 pop!OS 22.04 的小型机器，我用它托管几个带有 nginx 的页面。
为此，我有一个无 IP 域 (mydomain.ddns.net) 和一个带有路由器的 dyndns。
我的路由器上为 http、https 和我的 ssh 端口设置了端口转发。这些端口在机器上的 ufw 中打开。
一切工作正常，我可以使用 ssh 从外部连接到我的机器 ，但一周后 ssh 返回了 a （当然，nginx 也有同样的问题）。 为了排除故障，我做了以下操作：ssh [email protected] -p sshport
ssh: Could not resolve hostname mydomain.ddns.net: Name or service not known

  • 重启机器

  • 检查 noip.com 上的信息。一切似乎都很好，IP 是 portchecktool.com 返回的 IP，主机名仍然正确并标记为活动状态（参见：截屏）

  • 在 portchecktool.com 上检查端口是否打开。同样，一切正常，http、https 和 ssh 端口均已打开。

  • 尝试nslookup mydomain.ddns.net并返回以下内容：

Server:     127.0.0.53
Address:    127.0.0.53#53

** server can't find mydomain.ddns.net: NXDOMAIN

  • 如果我使用我的 WAN ip 地址（与 portchecktool.com 上看到的相同）通过以下行进行 ssh：ssh myname@wanip -p sshport一切正常，我可以像以前一样访问我的机器（我的网页也使用 ip 地址显示）。

  • 如果我在 nslookup.io 中输入我的主机名，我会看到我的 wan ip 被找到并返回

  • 该命令dig @8.8.8.8 mydoamin.ddns.net返回以下内容：

; <<>> DiG 9.10.6 <<>> @8.8.8.8 mydomain.ddns.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54910
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;mydomain.ddns.net.     IN  A

;; ANSWER SECTION:
mydomain.ddns.net.  60  IN  A   WAN.IP

;; Query time: 39 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Mar 03 16:54:53 CET 2023
;; MSG SIZE  rcvd: 61
  • 我尝试从 3 台不同的机器（另一台 pop!OS、一台 Mac 和一台 Android 手机）进行 ssh，结果相同。它适用于 wan ip，但无法解析主机名
  • 我在该机器上还有另一个运行 Ubuntu 22.04.1 的分区，我启动它以查看问题是否与我的配置有关，当我尝试 ssh 到它时，我遇到了完全相同的问题（适用于 wan IP 但无法解析主机名）

我觉得问题出在 DDNS 无法正确重定向的某个地方，但我找不到它突然停止工作的原因。唯一的修改是操作系统更新。
我能做些什么来进一步排除故障？任何帮助都将不胜感激。
谢谢

编辑：

感谢下面的精彩评论。添加 google DNS 解析器 (8.8.8.8) 解决了我的问题。

现在让我有点困扰的是，我的网站无法在具有“默认”配置的机器上使用。有没有办法让我的主机名回到自动提供的 DNS 中？（我想以前是这样的）

答案1

这看起来确实像是 DNS 解析问题。它可能来自两个地方：

  • 您的本地解析器（例如 systemd-resolved）
  • 您的提供商 DNS

在第一种情况下，您可以尝试重新启动服务并看看是否有帮助（有时 systemd-resolved 对非常低的 DNS TTL 不满意）：

sudo systemctl restart systemd-resolved.service

对于第二种情况，可以使用 dig 进行验证。如果您将 dig 设置为使用公共 DNS 解析器（例如 Google DNS 8.8.8.8）并且它返回答案（而不是您评论中的 NXDOMAIN），则可以假设您的提供商的 DNS 解析器存在问题。

例如，如果我想test.ddns.net使用公共 DNS 解析器进行检查8.8.8.8，我可以使用：

dig @8.8.8.8 test.ddns.net

; <<>> DiG 9.16.33-RH <<>> @8.8.8.8 test.ddns.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12144
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;test.ddns.net.         IN  A

;; ANSWER SECTION:
test.ddns.net.      60  IN  A   109.162.33.40

;; Query time: 20 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Mar 03 16:13:41 CET 2023
;; MSG SIZE  rcvd: 58

在这种情况下，需要注意的是：

  • 状态为：NOERROR
  • 我在与我查询的 A 记录相对应的“答案部分”中收到了答案

如果您的提供商的 DNS 有问题，那么您需要（至少暂时）将系统 DNS 更改为systemd-resolved公共 DNS。例如这可能有帮助。

相关内容