[dns-operations] question for DNS being attacked

[Michael Graff]

On Jun 28, 2012, at 1:37 PM, Vernon Schryver wrote:
> 
> A separate aspect of this supposedly much, much longer window is that
> it seems to assume that after the client has received a truncated or
> TC=1 response and is going through the DNS/TCP dance, it will still
> accept forged, evil DNS/UDP responses from the attacker.  Is that true
> of common resolving servers and resolver libraries?  It's not how I'd
> write a resolver.  Instead I'd discard all of the state needed to
> accept apparently stale UDP responses before the TCP SYN is sent.

Please correct me if I misunderstand the following statement.  "A slip rate of 2 drops 50% of the outgoing answers for a specific tuple, and returns a truncated response for the other 50%."  If I do not understand that behavior, ignore the rest of the message and I'll re-evaluate my concerns.  Also, is the default slip rate 2?

If that is the case, then if a legitimate query comes into an auth server which is currently being rate limited, the reply will be dropped 50% of the time.  So, half the time it gets no response (== timeout) and the other half it gets a truncated response, thereby translating into TCP (which is another whole can of worms I'm leaving for later.)

If it gets a truncated response, all is well enough.  If it gets no response, the additional time it waits will leave the window open for spoofing, using whatever lengths it has configured or defaults to.

I'm not worried about the TC=1 response case here, although I would point out that an attacker being able to change the behavior of a system just by attacking it seems scary as well, and causing a server to have to fall back to TCP more often and an auth server to have to respond to more TCP than it otherwise would seems like a major behavioral change, and I can think of several interesting attacks based on that alone.

--Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20120628/3fced78c/attachment.html>