Recursion 如何使绑定DNS递归地发送CLASS=ANY（255）的查询？

如果我用类not type查询我的本地递归BIND9 DNS！任何情况下，它都会递归地向转发器发送一个查询，但class=IN。如何让他用和我发送的相同的类发送递归查询？ 可能吗

我想要的是：

****** 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
};

---

有趣的角落案例

抛开这一切，你为什么要这么做？问题是，我认为答案是，它实际上并没有很好地定义QCLASS的递归意味着什么

RFC 1035指定NS记录保存指定类和域的名称服务器数据RFC 1035第3.3.11节。这意味着对于不同的类可能有不同的NS RRSET。这反过来意味着，使用如此不同的集合到达某个点的递归必须从两个名称服务器集合中分离并继续。没有定义的过程将这种拆分递归的结果合并到单个响应中，单个递归不能有多个响应。因此，这不是一个定义明确的过程。还有一个更复杂的问题，RFC1034和1035都指定对QClassAny查询的响应永远不能是权威的

您可以通过比较dig ns-c CH www.google.com+trace和dig ns-c在www.google.com+trace中的输出，并尝试想象将这两者都作为同一查找过程的一部分意味着什么，就可以得到一个相当清晰的提示。这真的没有道理

---

我猜想，您从BIND中看到的确切行为只是没有人尝试实现任何QCLASS递归的结果。可以合理地说，将您的查询转换为IN查询是一个错误，更正确的响应应该是FORMER RFC 1035第4.1.1节，名称服务器无法解释该查询。

谢谢您的来电，它很好地解释了该行为！