[dns-operations] AT&T DNS Cache Poisoning?

[Paul Vixie]

On 2012-10-28 5:55 AM, bert hubert wrote:
> ... the trend that all purported cache poisonings observed have
> been registry hacks.
>
> It appears that source port randomization works. 

it doesn't, though.

> Probably the only vulnerable servers are those behind NAT that derandomizes
> the source port. But important servers are unlikely to suffer from network
> address translation.

DNS SPR is not universally deployed even among recursive name servers
for large populations. and the de-randomization techniques described by
shulman and herzberg (http://arxiv.org/pdf/1209.1482.pdf) work in what
should be an alarming number of cases.

but nobody is alarmed because attempted use of this vulnerability is at
most "not widespread" and possibly also "rare".

DNS SPR does not "work" in the sense that its non-universal deployment
leaves significant attack surface uncovered. the reason we're not seeing
wide spread poisoning isn't that DNS SPR is preventing it. the reason
is, wide spread poisoning is not being attempted.

On 2012-10-28 7:40 AM, bert hubert wrote:
> ... people used the Kaminsky hack as a way to push DNSSEC. 

yes, we did.

DNSSEC is a spend-money-to-save-money proposition, which is never
compelling. those of us who knew that DNSSEC was needed and who had been
working on it for over a decade by the time kaminsky came along were
very happy to hear from kaminsky, and we rode the "fear curve" all the
way to partial deployment, including seeing the root zone signed, seeing
lots of TLD's signed, seeing DNSSEC as a requirement for all the new
gTLD's, and seeing implementors who had previously eschewed DNSSEC
decide to implement it after all. (for example, powerdnssec.)

in that sense we were a bunch of fear-mongering opportunistic bastards.
in our defense let me say that DNSSEC isn't an earn-money proposition
for me or for most of the rest of the opportunistic bastards who climbed
on the kaminsky band-wagon and trumpeted it as the reason why DNSSEC
should be taken seriously. rather, we were concerned internet citizens
who saw a long term problem that we knew others would not take seriously
until the world's losses were significant. and, as DRC pointed out
up-thread, DNS SPR is path protection and the path is already known to
be corrupt (nxdomain redirection, dns filtering). the things DNSSEC
prevents against are broader and more fundamental than kaminsky.

so the geeks did some fear-based marketing to get a win. it's a win i'll
take any way i can get it. we need DNSSEC.

> ... It might have been easier all round to just start from scratch and not
> pretend that this is 'an enhancement of DNS'. The length of the DNSSEC RFCs
> exceeds the length of the standardizing RFCs of DNS.

we naively believed that we could get DNSSEC into production before Y2K
if we tried hard to work within the existing system. the idea of the
root not being signed until 2010 was unthinkable. had we known that we
had that much time we would have cut much deeper. sixteen years into the
effort, DNSSEC is still not ready to become ubiquitous.

less naively, i now know that had we cut deeper, as in use a new port
number, call it "DNS V2", let initiators treat UDP/53 as a fallback
path, then sixteen years would have been much too short. many people
would have come out of the woodwork to help us. we would have unicode
encoding of all names, XML encoding of all transactions, TLS security
for all parts of the path, X.509 dependencies, no possibility of DANE,
and most transactions would now use TCP. the result would never work
outside anyone's lab, but would have been standardized anyway, several
times over a twenty year span, by the end of which the world would have
moved on to less open standards that could deliver usable functionality
in fractional-year time frames.

so it's probably for the best that we didn't know it would take sixteen
years when we first started this.

paul