[dns-operations] A Case Against DNSSEC (A Matasano Miniseries)

[Paul Vixie]

> > The reality is that we can not find one solution that fixes all of
> > the security issues we can come up with. Instead we need all security
> > measures we can invent. Yes, all of them. Because only with multiple
> > pieces of the puzzle we can get the environment we all need.
> 
> I remain (October 2002) convinced that no matter what "solution[s]" we end
> up with, we'll *have* to include a control plane, in some form or another.

i was puzzled by this when rodney first brought it up (october 2002) but when
i looked at his inputs i agreed with his conclusion.  many attacks on dns are
against the dns control signals not the dns data signals, and separating out
the control plane so that only privileged traffic can reach it is every bit
as important as the similar efforts to protect the bgp system or every ospf
system.  it's not that attackers are troubled by finding enough bandwidth to
firehose the data plane, it's that we don't want attackers to have easy low
bandwidth attacks in their toolboxes.

now, when protecting igp, the protectors are the protected.  a backbone squad
can put their RE's in 1918 space, or put them in VPNs, or otherwise make the
routing control plane unreachable by the general internet or by their own
customers or whatever.  symmetry (or identity as in this case) between the
protector and protected is always helpful when designing protections.  this
even works to some degree with bgp, since cooperating pairwise backbone squads
can work out pairwise solutions, or meet for beer and pizza at nanog and work
out ways to do this.  no rfc's needed, no consensus, no open debate, nothing
except hard engineering realities which easily overcome competitive pressures.

protecting the dns control plane is far, far harder.  first and foremost, the
thing that needs to be changed to effect protection (routing, addressing,
VPNs) is usually not under the control (direct or otherwise) of the DNS squad.
second and nearly as important, there aren't obvious pairwise relationships
beyond primary/secondary or customer/provider, and those are often high-splay
and amorphous rather than simply pairwise.  so we're moving water with a fork.
we can make all kinds of software and protocols (TSIG comes to mind) but there
will still be a lot of other people's water in between cooperating forks.  i'm
not giving up -- in fact, neustar and isc are working together on pairwise
efforts for the benefit of our constituents and/or the community -- but i'm
keenly aware that the problem is huge and our efforts are puny.