In article <[EMAIL PROTECTED]> 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
