In article <20060115231056.75AAD11425@sa.vix.com> you write:
# > class "ANY" has no purpose in the real world, not even for debugging. if # > you see it in a query, you can assume malicious intent. if you hear it in # > a query, you can safely ignore that query, or at best, map it to class # > "IN". # # er... i guess that is true, although the DNS does work for # things other than IP based networks... dispite our respective # best efforts to cripple it.
i'm not trying to cripple it. i'm saying RFC 1034/1035 was wrong about class "ANY". all answer/authority/additional data where OP=QUERY and QR=1 will have the same class as the QCLASS (of which, in spite of the QDCOUNT field, there can be only one). nodes do not have classes. not even zones have classes. each class has a hierarchy of NS RRs making a "namespace". each class needs its own root name servers. there are less-coherent / more-useful ways to interpret "the spec", and one such way could give meaning to class "ANY", but no dns implementation i'm aware of follows those alternate interpretations.
since nanog isn't a protocol-fine-points mailing list, at least for the DNS protocol, one could ask "why are we discussing this?" and my answer is, there is an operational tie-in. if you see QCLASS=ANY in a firewall, that is prima facie evidence of malfeasance, not merely misconfiguration or misinterpretation.
And if you want to refuse class ANY queries in BIND 9 create a view like the following. view "blackhole" any { allow-query { none; }; }; Note: all zones have to be in a view once you start using views. Again this really is only a stop gap measure as the attack can quite easily morph into something this won't catch. Mark