
Spoofing DNS with fragments - ahubert
https://blog.powerdns.com/2018/09/10/spoofing-dns-with-fragments/
======
peterwwillis
Don't rely on DNS for security.

DNS is a reverse phone book. It doesn't matter if the phone book is über-
secure. Even if the number you get is really your friend Gary's number, the
person who picks up on the other end might not be Gary. Maybe Fred knocked
Gary out with a lead pipe and answered the phone. You can't be sure it's Gary
talking to you just because the phone number was right.

~~~
jedisct1
It's not a phone book. It's a distributed key/value store.

~~~
ianleeclark
A phone book is a great analogy?

If you want someone in Berlin, you'd look in a Berlin phonebook; if you want
someone in Austin, you'd look in an Austin phonebook. Maybe the underlying
storage mechanism doesn't rely on consistent hashing or buckets, but phone
books are inherently distributed key/value stores.

------
teddyh
Well, yes, DNS is spoofable. The solution is, and has always been, DNSSEC.
This just makes it slightly more urgent to start using it.

~~~
tptacek
DNS is virtually never spoofed in practice because of a combination of (1)
sensitive systems being built to assume the DNS was already insecure and (2)
the settings where DNS spoofing is useful are already so insecure than DNS
security doesn't do much to help you (for instance, coffee shop wireless).

In practice, there are two significant targets for DNS spoofing:

1\. SMTP email, where TLS isn't universally required among MTAs.

2\. CA domain validation.

For problem (1), we has SMTP STS, which simply establishes a long-term
requirement for TLS between a pair of MTAs, sidestepping the spoofing problem.

For problem (2), there is a whole panoply of countermeasures to DNS spoofing,
erratically deployed across a variety of CAs. CAs _do not_ as a rule do strict
DNSSEC validation (it's too broken), but many of them do multi-perspective
lookups which make packet-level spoofing tricky to accomplish in practice.

The real solution to this problem isn't a government-run PKI that forklifts in
a whole new DNS protocol, but rather a culling of CAs that can't deploy
adequate countermeasures against these attacks.

Note that the Usenix paper illustrates scenarios in which DNSSEC makes this
attack _easier_ , not harder.

~~~
tialaramex
> CAs do not as a rule do strict DNSSEC validation (it's too broken), but many
> of them do multi-perspective lookups which make packet-level spoofing tricky
> to accomplish in practice.

Can you give specific examples of "many of them" doing multi-perspective DNS
today ?

~~~
tptacek
Can't. But if I've given the impression that the majority of CAs are
sophisticated, that wasn't intentional.

~~~
tialaramex
So to be clear:

You say DNSSEC validation is "too broken" for any public CA to be doing that,
but actually the largest (by issuance volume) does exactly that

Whereas you say multi-perspective is so prevalent "many of them" do it, but
you aren't able to produce any examples at all.

Maybe time for a re-think?

~~~
tptacek
I do not understand your argument at all, sorry.

~~~
JdeBP
tialaramex is mis-reading "do not as a rule" as "never" and then constructing
a straw man based upon that, and is also asking you to specifically name any
CA that does what you say many of them do. (-:

------
Dylan16807
Do any DNS resolvers monitor for huge spikes of spoofed results? Is falling
back to TCP for those queries likely to break much?

~~~
baolongtrann
My question as someone who doesn't know much about DNS beyond the most basic
stuff, how would a DNS resolver know a when query is spoofed? You can maintain
a query cache to filter out unsolicited (spoof) responses but what would make
a query valid or invalid? I'm talking about DNS/UDP btw.

Maybe some sort of challenges? Authentication? Like DNS cookies or something.

~~~
Dylan16807
At a level that needs OS cooperation to detect, there are packets with invalid
ports or invalid sequence numbers for TCP. On top of that, the requests
themselves have a 16-bit ID that acts as a random cookie. If we could extend
DNS to make the ID bigger that would solve the problem by itself. There have
been attempts to use rAnDOm CAsE to make spoofing harder, but it only works on
some DNS servers.

For attacks like this, there are thousands to billions of spoofed responses
coming in. It's not subtle at all, or very hard to keep track of the domains
under fire.

Edit: Oh wait, the queries themselves? That's a very different problem and
there's no good solution. Harass more ISPs into implementing filters that drop
spoofed IPs from their users.

~~~
JdeBP
Daniel J. Bernstein discussed the collision likelihoods with message ID and
port numbers years ago, which he later repeated on his WWW site;
distinguishing between various forms of attackers according to how much
network access they have (for snooping the query traffic). From the design of
his TAICLOCK protocol one could tell that such thinking had been a
contributory factor. 236 bytes are available for (say) a client-generated
random number.

* [http://cr.yp.to/proto/taiclock.txt](http://cr.yp.to/proto/taiclock.txt)

* [http://cr.yp.to/djbdns/forgery.html](http://cr.yp.to/djbdns/forgery.html)

