如何使 BIND DNS 递归地发送 CLASS = ANY (255) 的查询?
How to make BIND DNS recursively send a query with CLASS = ANY (255)?
如果我使用 class(不是类型!)ANY 对本地递归 BIND9 DNS 进行查询,它会递归地向转发器发送查询,但使用 class = IN。如何让他发送与我发送的 class 相同的递归查询?
可能吗?
我想要的:
****** QUERY WITH CLASS "ANY" *********************** CLASS "ANY" *************
* ME *----------------------->* Local Recursive DNS *------------>* FORWARDER *
****** *********************** *************
实际发生了什么:
****** QUERY WITH CLASS "ANY" *********************** CLASS "IN" *************
* ME *----------------------->* Local Recursive DNS *----------->* FORWARDER *
****** *********************** *************
配置为
options {
directory "/var/cache/bind";
allow-query { any; };
forwarders {
8.8.8.8
};
forward only;
listen-on {
...
};
auth-nxdomain no; # conform to RFC1035
};
有趣的角落案例。
撇开整个 "Why would you want to do that?" 的事情不谈,我认为答案是 well-defined QCLASS
ANY
的递归实际上不是什么意思。
RFC 1035 指定 NS
记录保存有关名称服务器 "for the specified class and domain" 的数据(RFC 1035 第 3.3.11 节)。这意味着不同的 类 可能有不同的 NS RRSets。这反过来意味着递归到达具有这些不同集合的点将必须 拆分 并从 both 组名称服务器继续。没有定义的过程来将这种拆分递归的结果合并为单个响应,并且单个递归不能有多个响应。所以,不是 well-defined 过程。 RFC 1034 和 1035 都指定对 QCLASS
ANY
查询的响应永远不会是权威的,这也增加了复杂性。
您可以通过比较 dig ns -c CH www.google.com +trace
和 dig ns -c IN www.google.com +trace
的输出,并尝试想象让这两个都成为相同的查找过程。这真的没有意义。
我怀疑您从 BIND 中看到的确切行为只是没有人尝试实现 ANY
QCLASS
递归的结果。可以合理地认为,您的查询变成 IN
查询是一个错误,更正确的响应是 FORMERR
(RFC 1035 第 4.1.1 节,"The name server was unable to interpret the query") .
如果我使用 class(不是类型!)ANY 对本地递归 BIND9 DNS 进行查询,它会递归地向转发器发送查询,但使用 class = IN。如何让他发送与我发送的 class 相同的递归查询? 可能吗?
我想要的:
****** QUERY WITH CLASS "ANY" *********************** CLASS "ANY" *************
* ME *----------------------->* Local Recursive DNS *------------>* FORWARDER *
****** *********************** *************
实际发生了什么:
****** QUERY WITH CLASS "ANY" *********************** CLASS "IN" *************
* ME *----------------------->* Local Recursive DNS *----------->* FORWARDER *
****** *********************** *************
配置为
options {
directory "/var/cache/bind";
allow-query { any; };
forwarders {
8.8.8.8
};
forward only;
listen-on {
...
};
auth-nxdomain no; # conform to RFC1035
};
有趣的角落案例。
撇开整个 "Why would you want to do that?" 的事情不谈,我认为答案是 well-defined QCLASS
ANY
的递归实际上不是什么意思。
RFC 1035 指定 NS
记录保存有关名称服务器 "for the specified class and domain" 的数据(RFC 1035 第 3.3.11 节)。这意味着不同的 类 可能有不同的 NS RRSets。这反过来意味着递归到达具有这些不同集合的点将必须 拆分 并从 both 组名称服务器继续。没有定义的过程来将这种拆分递归的结果合并为单个响应,并且单个递归不能有多个响应。所以,不是 well-defined 过程。 RFC 1034 和 1035 都指定对 QCLASS
ANY
查询的响应永远不会是权威的,这也增加了复杂性。
您可以通过比较 dig ns -c CH www.google.com +trace
和 dig ns -c IN www.google.com +trace
的输出,并尝试想象让这两个都成为相同的查找过程。这真的没有意义。
我怀疑您从 BIND 中看到的确切行为只是没有人尝试实现 ANY
QCLASS
递归的结果。可以合理地认为,您的查询变成 IN
查询是一个错误,更正确的响应是 FORMERR
(RFC 1035 第 4.1.1 节,"The name server was unable to interpret the query") .