![主要问题](https://linux22.com/image/1607683/%E4%B8%BB%E8%A6%81%E9%97%AE%E9%A2%98.png)
主要问题
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
记录,没有其他。