If I make a query to my local recursive BIND9 DNS with class (not type!) ANY, it recursively sends a query to the forwarder, but with class = IN. How to make him send recursive query with the same class as I've sent? Is it possible?
What I want:
****** QUERY WITH CLASS "ANY" *********************** CLASS "ANY" *************
* ME *----------------------->* Local Recursive DNS *------------>* FORWARDER *
****** *********************** *************
What actually happens:
****** QUERY WITH CLASS "ANY" *********************** CLASS "IN" *************
* ME *----------------------->* Local Recursive DNS *----------->* FORWARDER *
****** *********************** *************
The config is
options {
directory "/var/cache/bind";
allow-query { any; };
forwarders {
8.8.8.8
};
forward only;
listen-on {
...
};
auth-nxdomain no; # conform to RFC1035
};
Interesting corner case.
Leaving aside the whole "Why would you want to do that?" thing, I think the answer is that it's not actually well-defined what a recursion with QCLASS
ANY
means.
RFC 1035 specifies that an NS
record holds data about a nameserver "for the specified class and domain" (RFC 1035 section 3.3.11). Which means that there may be different NS RRSets for different classes. Which in turn means that a recursion reaching a point with such differing sets would have to split and continue on from both sets of name servers. There is no defined procedure to merge the result of such a split recursion into a single response, and a single recursion cannot have more than one response. So, not a well-defined process. There is also the added complication that both RFCs 1034 and 1035 specify that the response to a QCLASS
ANY
query can never be authoritative.
You can get a reasonably clear hint of what would happen just by comparing the outputs of dig ns -c CH www.google.com +trace
and dig ns -c IN www.google.com +trace
, and trying imagine what it would mean to have both of those be parts of the same lookup process. It doesn't really make sense.
The exact behavior you see from BIND is, I suspect, simply a consequence of nobody ever trying to implement ANY
QCLASS
recursion. It could be reasonably argued that it's a bug that your query gets turned into an IN
query, and that a more correct response would be FORMERR
(RFC 1035 section 4.1.1, "The name server was unable to interpret the query").