☰

主要问题

tag-icon • tag-icon linux networking dns
主要问题

主要问题

picard.tn.tinloaf.de我正在尝试使用家用路由器的 DNS 解析器来解析域名。它应该解析A为指向10.17.1.10（我的 VPN 网络中的主机）的记录。路由器位于192.168.0.1，是我的 ISP 提供的便宜货。如果发现它的解析器坏了，我一点也不惊讶。

如果我使用dig查询ANY，我会得到以下结果：

tinloaf@janeway ~ $ dig -t ANY picard.tn.tinloaf.de @192.168.0.1

; <<>> DiG 9.14.4 <<>> -t ANY picard.tn.tinloaf.de @192.168.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52368
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: db6540198fc3d64c316539ba5db350d5ea576f0f0c9323e9 (good)
;; QUESTION SECTION:
;picard.tn.tinloaf.de.      IN  ANY

;; ANSWER SECTION:
picard.tn.tinloaf.de.   180 IN  A   10.17.1.10

;; Query time: 131 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Fri Oct 25 21:47:34 CEST 2019
;; MSG SIZE  rcvd: 93

很好。不确定TTL该响应中的 （请参阅下文了解更多恶作剧），但A记录就在那里。让我们使用 进行查询-t A：

tinloaf@janeway ~ $ dig -t A picard.tn.tinloaf.de @192.168.0.1

; <<>> DiG 9.14.4 <<>> -t A picard.tn.tinloaf.de @192.168.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25118
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: e3d7c44265c696ae29b2bd405db35122345a154db36bffcc (good)
;; QUESTION SECTION:
;picard.tn.tinloaf.de.      IN  A

;; Query time: 143 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Fri Oct 25 21:48:50 CEST 2019
;; MSG SIZE  rcvd: 77

怎么会这样？是不是我这边配置有误（我自己管理 DNS 区域），导致A查询 时出现记录ANY，查询 时却消失A？mxtoolbox.com 上的 DNS 查找工具未显示该域的任何错误。

TTL 似乎也是假的

如果我-t ANY快速连续运行多个查询，将发生以下情况：

tinloaf@janeway ~ $ dig -t ANY picard.tn.tinloaf.de @192.168.0.1              

; <<>> DiG 9.14.4 <<>> -t ANY picard.tn.tinloaf.de @192.168.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22050
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: ea0a9ccb1c56115a19c257145db352208dbc41f9e58cf134 (good)
;; QUESTION SECTION:
;picard.tn.tinloaf.de.      IN  ANY

;; ANSWER SECTION:
picard.tn.tinloaf.de.   507 IN  A   10.17.1.10

;; Query time: 277 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Fri Oct 25 21:53:05 CEST 2019
;; MSG SIZE  rcvd: 93

tinloaf@janeway ~ $ dig -t ANY picard.tn.tinloaf.de @192.168.0.1              

; <<>> DiG 9.14.4 <<>> -t ANY picard.tn.tinloaf.de @192.168.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56509
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: c642b601eed33f15938e59585db3522167f6c0ab9733d818 (good)
;; QUESTION SECTION:
;picard.tn.tinloaf.de.      IN  ANY

;; ANSWER SECTION:
picard.tn.tinloaf.de.   494 IN  A   10.17.1.10

;; Query time: 159 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Fri Oct 25 21:53:06 CEST 2019
;; MSG SIZE  rcvd: 93

tinloaf@janeway ~ $ dig -t ANY picard.tn.tinloaf.de @192.168.0.1              

; <<>> DiG 9.14.4 <<>> -t ANY picard.tn.tinloaf.de @192.168.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14446
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: bb9a410f8db063f22d3bb66d5db35223580d725b203cbdfa (good)
;; QUESTION SECTION:
;picard.tn.tinloaf.de.      IN  ANY

;; ANSWER SECTION:
picard.tn.tinloaf.de.   504 IN  A   10.17.1.10

;; Query time: 303 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Fri Oct 25 21:53:07 CEST 2019
;; MSG SIZE  rcvd: 93

tinloaf@janeway ~ $ dig -t ANY picard.tn.tinloaf.de @192.168.0.1              

; <<>> DiG 9.14.4 <<>> -t ANY picard.tn.tinloaf.de @192.168.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39213
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: eceda0ed18efd5d15e90b7de5db3522584f3b33cf5bbabf8 (good)
;; QUESTION SECTION:
;picard.tn.tinloaf.de.      IN  ANY

;; ANSWER SECTION:
picard.tn.tinloaf.de.   496 IN  A   10.17.1.10

;; Query time: 277 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Fri Oct 25 21:53:09 CEST 2019
;; MSG SIZE  rcvd: 93

请注意，这些查询之间只有几秒钟的间隔，但是该TTL字段似乎在不规则地跳动。这是正常的吗？我可以想象廉价的路由器盒实际上并没有运行缓存（存根）解析器，而只是将请求转发到我 ISP 的解析器，并且那里有一个循环负载平衡器，所以我每次都会从不同的服务器收到回复。这是一个现实的情况吗？

答案1

为了防止某些特定攻击（见https://en.wikipedia.org/wiki/DNS_rebinding)，一些递归名称服务器正在使用私有空间中的 IP 地址过滤记录。

但除此之外，已知的主要公共递归 DNS 服务都可以很好地解决该问题：

$ dig picard.tn.tinloaf.de +short @8.8.8.8
10.17.1.10
$ dig picard.tn.tinloaf.de +short @1.1.1.1
10.17.1.10
$ dig picard.tn.tinloaf.de +short @9.9.9.9
10.17.1.10

如果您使用在线检查工具，它们会显示名称为解析：

  • https://dnsviz.net/d/picard.tn.tinloaf.de/dnssec/（遗憾的是目前没有历史记录，因此此链接将在您点击时重新运行检查）
  • （不幸的是，无论出于什么原因，Zonemaster 似乎对这个域名完全感到困惑）

你可以通过以下方式自己检查整个解决方案dig picard.tn.tinloaf.de +trace @1.1.1.1

简而言之，我们找到最后的权威名称服务器和lukas-barth.net.，ns1.n621.de.并且它们都为您的记录提供了正确的回复。

因此，所有这些的总结是，域的全局配置似乎很好，以及该记录的解析，因此您可能看到的问题可能与本地配置中的具体内容更相关。

不要使用查询类型 ANY。这绝不意味着“ALL”，这与人们的看法相反，现在有一个标准（请参阅https://www.rfc-editor.org/rfc/rfc8482) 如何处理它，并且可能名称服务器将不再回复它。简而言之，它不是一个很好的故障排除工具。如果您需要检查记录A，请查询该类型，无需其他操作。

至于回复的变化，这可能是因为您使用具有特定语义的 ANY，而且正如您自己描述的那样，事实上，您的解析器可以将查询转发到其他解析器，这些解析器可以位于负载平衡器或任播设置后面，以便您访问不同的服务器。

但再说一次，真正的检查是通过检查A记录，没有其他。

相关内容