如何在递归中间解决DNS问题？

13

我的DNS真的很奇怪。我的域名（strugee.net）在某些网络中无法解析，而在其他网络中则无法解析。

例如，在我的家庭网络（服务器所在的同一网络）上：

% dig strugee.net

; <<>> DiG 9.10.3-P4 <<>> strugee.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10086
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;strugee.net.           IN  A

;; ANSWER SECTION:
strugee.net.        1800    IN  A   216.160.72.225

;; Query time: 186 msec
;; SERVER: 205.171.3.65#53(205.171.3.65)
;; WHEN: Sat Apr 16 15:42:36 PDT 2016
;; MSG SIZE  rcvd: 56

但是，如果我登录到Digital Ocean上的服务器，则该域无法解析：

% dig strugee.net      

; <<>> DiG 9.9.5-9+deb8u3-Debian <<>> strugee.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58551
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

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

;; Query time: 110 msec
;; SERVER: 2001:4860:4860::8844#53(2001:4860:4860::8844)
;; WHEN: Sat Apr 16 18:44:25 EDT 2016
;; MSG SIZE  rcvd: 40

但是，直接转到权威名称服务器就可以了：

% dig @dns1.registrar-servers.com strugee.net   

; <<>> DiG 9.9.5-9+deb8u3-Debian <<>> @dns1.registrar-servers.com strugee.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30856
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;strugee.net.           IN  A

;; ANSWER SECTION:
strugee.net.        1800    IN  A   216.160.72.225

;; AUTHORITY SECTION:
strugee.net.        1800    IN  NS  dns3.registrar-servers.com.
strugee.net.        1800    IN  NS  dns4.registrar-servers.com.
strugee.net.        1800    IN  NS  dns2.registrar-servers.com.
strugee.net.        1800    IN  NS  dns1.registrar-servers.com.
strugee.net.        1800    IN  NS  dns5.registrar-servers.com.

;; Query time: 3 msec
;; SERVER: 216.87.155.33#53(216.87.155.33)
;; WHEN: Sat Apr 16 18:46:36 EDT 2016
;; MSG SIZE  rcvd: 172

很明显，某个大型网络存在无法解决我的域的问题，但我似乎无法弄清楚哪里。我浏览了手册dig页中可能有用的选项，但没有发现特别有用的选项。

我在Namecheap上既是域名注册商，又是DNS托管人。我打开了DNSSEC选项。我最近没有对DNS设置进行任何更改。

如何调试此问题并查找有问题的名称服务器？

domain-name-system  recursive 
— 奋斗
source
7
感谢您提供域名。没有这些信息，我们很难在Serverfault上解决此类问题。
— Andrew B
@AndrewB哦，我知道。
— 不用
2
@AndrewB的答案很合理，对我来说似乎是正确的。不过，在我阅读之前，我注意到您失败的查询使用了IPV6域名服务器，而成功的查询使用了IPV4。通常（在这种情况下不是这样）通常暗示IPV6配置错误，并且明确使用名称服务器的数字IPV [4/6]地址而不是别名可能会有所帮助。
— Guntram Blohm
@Guntram只要记住，我们会从名称服务器得到答复，这意味着我们至少可以连接到 DNS服务器。只是要确保人们不会以错误的印象离开它... SERVFAIL可能表示上游问题，但仍然表示答复数据包。
— 安德鲁B
@GuntramBlohm您正在尝试一些事情。strugee.net有五个NS记录，但是没有AAAA粘合记录只有A粘合记录。更糟糕的是，这五个A粘合记录仅指向两个不同的IP地址。这似乎是一个非常脆弱的设置。即使这不是造成问题的根本原因，也应提防这一问题。
— kasperd '16

Answers:

24

如何调试此问题并查找有问题的名称服务器？

daxd5提供了一些很好的入门建议，但是这里唯一的真实答案是您需要知道如何像递归DNS服务器那样思考。由于权威层存在许多错误配置，可能会导致不一致SERVFAIL，因此您需要DNS专业人员或在线验证工具。

无论如何，我们的目标并不是要尽全力帮助您，但我想确保您了解该问题没有最终答案。

在您的特定情况下，我注意到这strugee.net似乎是使用DNSSEC签名的区域。从DS和RRSIG记录在推荐链中可以明显看出这一点：

# dig +trace +additional strugee.net
<snip>
strugee.net.            172800  IN      NS      dns2.registrar-servers.com.
strugee.net.            172800  IN      NS      dns1.registrar-servers.com.
strugee.net.            172800  IN      NS      dns3.registrar-servers.com.
strugee.net.            172800  IN      NS      dns4.registrar-servers.com.
strugee.net.            172800  IN      NS      dns5.registrar-servers.com.
strugee.net.            86400   IN      DS      16517 8 1 B08CDBF73B89CCEB2FD3280087D880F062A454C2
strugee.net.            86400   IN      RRSIG   DS 8 2 86400 20160423051619 20160416040619 50762 net. w76PbsjxgmKAIzJmklqKN2rofq1e+TfzorN+LBQVO4+1Qs9Gadu1OrPf XXgt/AmelameSMkEOQTVqzriGSB21azTjY/lLXBa553C7fSgNNaEXVaZ xyQ1W/K5OALXzkDLmjcljyEt4GLfcA+M3VsQyuWI4tJOng184rGuVvJO RuI=
dns2.registrar-servers.com. 172800 IN   A       216.87.152.33
dns1.registrar-servers.com. 172800 IN   A       216.87.155.33
dns3.registrar-servers.com. 172800 IN   A       216.87.155.33
dns4.registrar-servers.com. 172800 IN   A       216.87.152.33
dns5.registrar-servers.com. 172800 IN   A       216.87.155.33
;; Received 435 bytes from 192.41.162.30#53(l.gtld-servers.net) in 30 ms

在继续之前，我们需要检查签名是否有效。DNSViz是经常用于此目的的工具，它可以确认确实存在问题。图片中愤怒的红色表示您有问题，但我们不必将鼠标悬停在所有内容上，只需展开左侧边栏上的“ 通知 ”即可：

RRSIG strugee.net/A alg 8, id 10636: The Signature Expiration field of the RRSIG RR (2016-04-14 00:00:00+00:00) is 2 days in the past.
RRSIG strugee.net/DNSKEY alg 8, id 16517: The Signature Expiration field of the RRSIG RR (2016-04-14 00:00:00+00:00) is 2 days in the past.
RRSIG strugee.net/DNSKEY alg 8, id 16517: The Signature Expiration field of the RRSIG RR (2016-04-14 00:00:00+00:00) is 2 days in the past.
RRSIG strugee.net/MX alg 8, id 10636: The Signature Expiration field of the RRSIG RR (2016-04-14 00:00:00+00:00) is 2 days in the past.
RRSIG strugee.net/NS alg 8, id 10636: The Signature Expiration field of the RRSIG RR (2016-04-14 00:00:00+00:00) is 2 days in the past.
RRSIG strugee.net/SOA alg 8, id 10636: The Signature Expiration field of the RRSIG RR (2016-04-14 00:00:00+00:00) is 2 days in the past.
RRSIG strugee.net/TXT alg 8, id 10636: The Signature Expiration field of the RRSIG RR (2016-04-14 00:00:00+00:00) is 2 days in the past.
net to strugee.net: No valid RRSIGs made by a key corresponding to a DS RR were found covering the DNSKEY RRset, resulting in no secure entry point (SEP) into the zone. (216.87.152.33, 216.87.155.33, UDP_0_EDNS0_32768_4096)

问题很明显：您区域上的签名已过期，并且密钥需要刷新。之所以看到不一致的结果，是因为并非所有递归服务器都启用了DNSSEC验证。可以通过验证的域将删除您的域，对于不通过验证的域，则将照常进行。

编辑：众所周知，Comcast的DNS基础结构实现了DNSSEC验证，作为他们的客户之一，我可以确认自己也看到了SERVFAIL。

$ dig @75.75.75.75 strugee.net | grep status
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2011
— 安德鲁·B
source
糟糕，我stugee.net在挖掘输出中遇到的错误显然是错别字。此分析的DNSSEC部分是针对正确的名称完成的。
— 安德鲁B
5

当确实看到权威名称服务器正确响应时，您需要跟踪DNS解析的整个链。也就是说，从根服务器开始遍历整个DNS层次结构。

$ dig net NS
;; ANSWER SECTION:
net.            172800  IN  NS  c.gtld-servers.net.
net.            172800  IN  NS  f.gtld-servers.net.
net.            172800  IN  NS  k.gtld-servers.net.
;; snipped extra servers given
$ dig @c.gtld-servers.net strugee.net NS
;; AUTHORITY SECTION:
strugee.net.        172800  IN  NS  dns2.registrar-servers.com.
strugee.net.        172800  IN  NS  dns1.registrar-servers.com.
;; snipped extra servers again

基本上，这将检查公用DNS服务器是否正常运行，并且您正在执行DNS解析器应做的同一件事。因此，除非他们的DNS解析器有问题，否则您应该在Digital Ocean服务器中获得与上述相同的答案：

$ dig net NS
$ dig strugee.net NS
$ dig strugee.net

如果前两个查询失败，则是Digital Ocean方面的DNS失败。检查您的/etc/resolv.conf并尝试查询辅助DNS服务器。如果第二台可以使用，则只需切换解析器的顺序，然后重试。

— daxd5
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.