DOS attack against DNS?

Mark Andrews Mark_Andrews at isc.org
Sun Jan 15 23:33:45 UTC 2006


In article <20060115231056.75AAD11425 at 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



More information about the NANOG mailing list