DNS DoS ???

Mark Andrews marka at isc.org
Mon Aug 1 00:42:32 UTC 2011

In message <09D7A1D0-0B13-4570-8891-835CA6568AD7 at arbor.net>, "Dobbins, Roland" 
> On Jul 31, 2011, at 9:15 AM, "Jimmy Hess" <mysidia at 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.

Named already takes proper precautions by default.  Recursive service
is limited to directly connected networks by default.  The default
was first changed in 9.4 (2007) which is about to go end-of-life
once the final wrap up release is done.

> > 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

The real problem is that many ISP's don't do effective ingress/egress
filtering.  This prevents compromised machines impersonating other

There is absolutely no reason that DSL and Cable connection shouldn't
be tied down to provider source addresess and perhaps a specfic set
of exception source addresses on request.  There is absolutely no
reason that NOC's and other service networks in the ISPs shouldn't
be tied down.  If you to spoof addresses for testing do it from
networks explictly setup to support this.

> 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 at arbor.net> // <http://www.arbornetworks.com>
>                   Sell your computer and buy a guitar.=20
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org

More information about the NANOG mailing list