Question

我有一个非常简单的用Python编写的名称服务器，仅使用socket和dnslib，主要用于让我们加密DNS-01挑战响应，以及一些用于实验目的的A记录

我的问题是，当查询到达服务器但名称服务器不包含服务器想要响应的相关数据时，域名服务器应该如何响应？

它应该忽略它吗？

我之所以问是因为我一直在收到ANY leth.cc的查询，这些查询显然用于DNS放大攻击。在注意到这一点之前，我正在用空白答案部分来回答查询，现在我没有将任何内容发回给提供的地址。

我从

data, addr = sock_dns.recvfrom(1024)
q = dnslib.DNSRecord.parse(data)
a = q.reply()
# add an answer if query is relevant
# a.add_answer(*dnslib.RR.fromZone(qname + " 30 IN TXT " + verification_code))
sock_dns.sendto(a.pack(), addr)

到

data, addr = sock_dns.recvfrom(1024)
q = dnslib.DNSRecord.parse(data)
a = q.reply()
# add an answer if query is relevant
# a.add_answer(*dnslib.RR.fromZone(qname + " 30 IN TXT " + verification_code))
if len(a.rr) > 0:
 sock_dns.sendto(a.pack(), addr)

这是可以接受的行为吗？

考虑了帕特里克·梅夫克（Patrick Mevzek）的答案，我现在将其修改为

data, addr = sock_dns.recvfrom(1024)
q = dnslib.DNSRecord.parse(data)
a = q.reply()
# add an answer if query is relevant
# a.add_answer(*dnslib.RR.fromZone(qname + " 30 IN TXT " + verification_code))
if not a.rr:
  a.header.rcode = dnslib.RCODE.REFUSED
sock_dns.sendto(a.pack(), addr)

虽然这可能是对有效客户端的正确响应，但是在正常操作下，leth.cc的查询永远不会到达服务器，因为除了我在服务器中配置的NS记录外，没有其他指向我的名称服务器的信息。注册商DNS联机配置界面。这是他们的域名服务器，指示客户应去我的域名服务器寻求答案，以解决他们无法回答的更具体的查询。

但是如果有leth.cc的查询到达我的服务器，则该查询很可能源自非常不寻常的来源。还是可以用RCODE.REFUSED回答那些请求，还是可以通过欺骗的方式欺骗请求，使得addr包含一个不应被联系的地址，以避免DDOS攻击的那个地址？毕竟，这是一种放大攻击；就像反射的DDOS攻击一样吗？我不介意我的域名服务器受到DDOS的攻击（这是我的业务要解决的问题），我只是不希望它参与其中，以防万一。

此外，这不是解析名称服务器，如果找不到信息，它也不会发出查询其他名称服务器的信息。我没有看到不回答对qnames的请求（不属于此域名服务器域）的任何不好的事情。

Answer 1

绝对不是您想要执行的操作（在正常操作中），因为客户端随后将重试，并在某个时候切换到另一个名称服务器，因此至少您可以造成延误，即使不是很糟糕的结果。

可能的返回码在https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6中定义，并且大部分在RFC 1035中定义。

对于您的情况，我认为您确实需要：拒绝

它的定义如下：

名称服务器拒绝执行指定的操作政策原因。例如一个名字服务器可能不希望提供给特定请求者的信息，或名称服务器可能不希望执行特定操作（例如，区域传输）。

现在，您的名称服务器在某些域名上具有权威性。如果它收到对其他查询的查询，则应说这对他们没有权威，这是 NXDOMAIN 或RFC 1035中定义的RCODE 3：

名称错误-仅对权威名称的回应服务器，此代码表示查询中引用的域名确实不存在。

这是一个很小的答案，因此您没有放大任何内容。您的服务器仍然可能受到许多此类查询的攻击，因此您可以决定实施速率限制（请参见下文）。的确，作为UDP的流量，您的服务器可能会回答受害者，而不是查询的真正来源，但没有放大，就像世界上任何其他名称服务器一样，这也是所有基于UDP协议的不幸命运

如果您以更大的答案回答查询（例如，即使您试图回答ANY，即使是您权威的名字，DDOS也是这样），因为在这里受害者可能会收到流量很大，而攻击者几乎不需要发送给您。

此外，ANY还是用于递归名称服务器的（较差的）故障排除工具（例如，“为特定标签提供缓存的当前状态”）而不是权威名称服务器。当前有一些作品可以完全弃用它：https://blog.cloudflare.com/what-happened-next-the-deprecation-of-any/

现在您似乎更多地谈论了操作问题和DDOS攻击。这是另一种情况，即使回复也很昂贵。当前的名称服务器基本上通过降低答复率来实现用于“响应率限制”的RRL机制。请参阅具有此功能的Bind这篇文章：https://kb.isc.org/article/AA-01000/0/A-Quick-Introduction-to-Response-Rate-Limiting.html

如果您担心自己的域名服务器可能遭到攻击，则不妨对其实施类似的操作。

没有发送相关查询时对域名服务器的正确响应？

1 个答案: