DNS DoS ???

Jimmy Hess mysidia at gmail.com
Sun Jul 31 02:15:38 UTC 2011


On Sat, Jul 30, 2011 at 5:53 PM, Dobbins, Roland <rdobbins at arbor.net> wrote:

> On Jul 31, 2011, at 3:08 AM, Jimmy Hess wrote:
> > A good example, would be services  such as OpenDNS.
> One can argue a) that services like OpenDNS aren't necessarily a Good Thing
> when run by those who don't take the proper precautions

Is there an RFC  specifying precisely what are considered the proper
precautions?
"precautions" should ideally be enabled in BIND by default.


> and b) that OpenDNS in particular is run by smart, responsible folks who
> take extra measures to ensure they don't become a party to DNS
> reflection/amplification attacks, even though they operate an open recursive
> lookup service.
>

My point here is that...  splitting recursive service and cordoning off
recursive service by
using a firewall or  ACL based on IP address, is only a partially effective
operational
workaround   to a  serious defect in the protocol.
Authoritative service is as subject to DoS as ever, especially with IPv6 and
DNSSEC
deployments.

It doesn't fall under "best common practices";  it falls under  "necessary
evils",  that everyone pretty much has to do.

Right now we have to say  "separate and restrict access to your recursive
service",  because it is the only option
we can implement without changes to the protocol,   and for now it should be
done wherever possible.
But this is not pallatable at all.    The DNS protocol should be fixed so we
don't need this workaround.

Standardization effort should concentrate on changing the protocol.



Restricting recursive service is a good short term solution,  but it is not
for every case.
The workaround is not a best practice,   it is evidence that the DNS
protocol should be changed.


How can it be changed?
Add a proof-of-work  for every DNS query and  an additional round-trip
for  the first  recursion-desired DNS query  a client makes to any
restricted DNS server, to obtain
some  "client token"  or  other unique hash    to be sent along with
queries.


--
-JH



More information about the NANOG mailing list