[dns-operations] DNS Attack over UDP fragmentation

Paul Vixie paul at redbarn.org
Wed Sep 4 17:22:46 UTC 2013

ondrej.sury at nic.cz wrote:
> On 2013-09-04 18:12, Paul Vixie wrote:
>> ..., then i think we can safely tell anyone who is worried that their
>> authority data or recursive server is vulnerable to fragmentation-based
>> attacks, that they ought to just deploy dnssec.
> Paul,
> the problem is that it needs to deployed on both sides otherwise it will
> just make things evey worse, so I don't think we can flush this by just
> saying "enable DNSSEC now". ...

if you want to spend time on solutions for A/Z where A cares about
security and Z does not, that's your decision. for me, if Z does not
care, then i do not care. we have a solution for A or Z which will work
if their transaction partners also deploy it. in 2008 that wasn't good
enough, but in 2013 it is.

there's a meta-decision hovering over this battlefield. if we believe
that DNSSEC can be deployed within our lifetimes, then we'll say it's
the solution to the fragmentation problem. conversely if we say that
DNSSEC is not the solution to the fragmentation problem, then we're
implying that we do not believe DNSSEC can be deployed within our
lifetime. let's choose carefully and with eyes open.

> ...  At least the parties that have some customers
> can't (e.g. registries, registrars, DNS operators).  We definitely should
> say "enable DNSSEC" if you want to be protected (and we are saying that
> even longer than from summer 2008), but we also need to ensure we do
> everything we can to secure those who don't.

as you know there is a very long tail of non-source-port-randomization
recursives and stubs out there, and a lot of those who have deployed
source port randomization are behind de-randomizing NAT boxes. if you're
going to accept the burden of protecting all A in A/Z pairs in which Z
does not care, then your top priority should be the population of Z who
are not yet kaminsky-safe.


More information about the dns-operations mailing list