[143153] in North American Network Operators' Group
Re: DNS DoS ???
daemon@ATHENA.MIT.EDU (Dobbins, Roland)
Sun Jul 31 02:48:35 2011
From: "Dobbins, Roland" <rdobbins@arbor.net>
To: "nanog@nanog.org" <nanog@nanog.org>
Date: Sun, 31 Jul 2011 06:48:41 +0000
In-Reply-To: <CAAAwwbXVAeMkv8d-rXDD-B5xvsx+J6RE2=poVRH7DzKQoBrj2g@mail.gmail.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jul 31, 2011, at 9:15 AM, "Jimmy Hess" <mysidia@gmail.com> wrote:
> Is there an RFC specifying precisely what are considered the proper prec=
autions?
> "precautions" should ideally be enabled in BIND by default.
Not of which I'm aware. I'm happy to contribute to any efforts you or anyon=
e else are volunteering to coordinate on this topic, as it's important work=
which ought to be done sooner & not later.
;>
> My point here is that... splitting recursive service and cordoning off =
recursive service by
> using a firewall
Using a stateful firewall is contraindicated.=20
> or ACL based on IP address, is only a partially effective operational wo=
rkaround to a serious defect in the protocol.
It's actually a combination of serious defects in a number of protocols, st=
arting with IPv4 itself.=20
IPv4 went into service ~27 years ago as testbed protocol. The first formal =
security assessment of the IPv4 core protocols was completed last month.=20
IPv6 inherits all the security problems inherent in IPv4, & introduces new =
ones - the ND mess & the untold billions of dollars in opex costs that the =
consonance of the letters 'B', 'C', 'D', & 'E' will entail are just two gla=
ring examples.=20
So, if we're looking for protocol architecture dragons to slay, there're fa=
r more basic issues in need of a strong sword-arm before we even get to out=
liers like the DNS, heh.
> Authoritative service is as subject to DoS as ever, especially with IPv6 =
and DNSSEC
> deployments.
And there are deployment & operational BCPs which can mitigate DDoS of auth=
oritative DNS services, from logical separation of functions (see <https://=
files.me.com/roland.dobbins/m4g34u> for an example) to S/RTBH to flowspec t=
o commercial IDMS solutions.=20
[Full disclosure: my employer is a vendor of such solutions.]
> The DNS protocol should be fixed so we don't need this workaround.
By all means.=20
In the meantime, it's important to realize that many of the resource constr=
aints which were extant at the time the DNS was designed no longer hold swa=
y. DNS reflection/amplification attacks can be eliminated by the simple (a=
nd, nowadays, practical, IMHO) expedient of re-configuring resolver-facing =
DNS servers to force the use TCP by default.=20
The best part is that DNS operators can start doing this today, without rec=
ourse to standards bodies, working groups, et. al. No need for any inter-o=
rganizational coordination at all - each can move at his own pace, within h=
is own span of administrative control.=20
As an aside, it should be noted that switching the DNS over to TCP by defau=
lt would accomplish a great deal of what DNSSEC is intended to provide, wit=
h far less in the way of architectural, operational, & administrative compl=
exity.=20
Most folks who still misguidedly filter TCP/53 are unlikely to support EDNS=
0, either, so they're already hurting - a widespread switch to TCP would li=
kely finally force them out of their jungle fastnesses and out blinking int=
o the sunlight.=20
;>
> Standardization effort should concentrate on changing the protocol.
It's important to keep in mind how long the last substantive changes to the=
DNS have required, as opposed to the near-term expedient of implementing B=
CPs & switching to TCP.=20
> Restricting recursive service is a good short term solution, but it is n=
ot for every case.
Concur 100%. Meanwhile, we continue to resolve with the DNS we have until t=
he new, improved version is designed, tested, & generally deployed.=20
;>
> The workaround is not a best practice, it is evidence that the DNS protoc=
ol should be changed.
There's a reason proof-of-work solutions have never been widely deployed - =
in the final analysis, they all too often end up simply a form of cost-shif=
ting which leaves the system in question just as vulnerable (if not more so=
) to DoS as it was in the first place, just within a different transaction =
path/layer.=20
So, while I agree with you that changes are called for, implementing proofs=
-of-work into the DNS transactional model isn't one I'd personally recommen=
d, FWIW.=20
---------------------------------------------------------------------
Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Sell your computer and buy a guitar.=20
