Bugtraq mailing list archives
Re: Thoughts about DNS...
From: tqbf () ENTERACT COM (Thomas H. Ptacek)
Date: Sun, 27 Apr 1997 03:02:57 -0500
True, and I just thought up a solution: Once a server notices fake responses arriving, it can reattempt the lookup via TCP. Then we can be
You can't guarantee that every nameserver in the world will support TCP. [ re: the possibility of manipulating servers into caching NXDOMAIN as a result of forgery protection ]
Well since we are dealing with these problems right now, we can be intelligent and not cache a host/IP as broken when we receive spoofed
Ok, just bringing it up. However, we've still prevented a legitimate query from resolving, so the only choices we have are to play dead or to incorrectly return an NXDOMAIN (right?).
mechanism on multiple servers in parallel? What happens if I open up N recursive queries to a nameserver, following them up with a stream of invalid requests? Can I starve the nameserver of resources (some state is
To protect against this we can refuse recursive queries from outside the subnets that the server is set up to serve, protecting us against outside
That doesn't work. This is a blind attack; I can make the queries come from any address in the world I want them to come from. I don't think anything that relies on router configuration is a solution - do you? [ re: TCP vs Cookie Response ]
I think connecting to the servers via TCP would be the better solution, since it is a capability built into almost every DNS server in existence.
Responding NXDOMAIN to a query is a capability built into every DNS server in existance. TCP DNS is not. It's an excellent idea, though!
Cookies would have to be supported on the server that is being spoofed,
No, the point behind the "cookie" support is that they don't require support. We don't need the server to UNDERSTAND the cookie, we just need it to acknowledge it in a response. We're embedding the cookie in a legitimate query, and expecting to receive an NXDOMAIN back. The NXDOMAIN confirms that the server is alive. [ the problem is... ]
server's throat before the lookup times out.. However, I didnt realized
What happens when the server times out? We try again. Does the server cache an NXDOMAIN simply due to a timeout? It shouldn't. If it doesn't, I can continue trying this attack indefinitely until I win.
it would be that quick and easy. This is really a serious problem that should be addressed.
Agreed. I think the combination of D.O.S. with the ID prediction attack is the most significant issue here. ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf () enteract com] ---------------- "If you're so special, why aren't you dead?"
Current thread:
- Re: CPSN 4-970424: Possible buffer overflow in pop3d, (continued)
- Re: CPSN 4-970424: Possible buffer overflow in pop3d J. Joseph Max Katz (Apr 28)
- Re: CPSN 4-970424: Possible buffer overflow in pop3d Johannes Erdfelt (Apr 28)
- Overflow in xlock George Staikos (Apr 26)
- Re: Overflow in xlock David Hedley (Apr 27)
- Re: Overflow in xlock Bollinger (Apr 27)
- Re: Overflow in xlock Andrew G. Morgan (Apr 27)
- Thoughts about DNS... Thomas H. Ptacek (Apr 26)
- Re: Thoughts about DNS... Illuminati Primus (Apr 26)
- Re: Thoughts about DNS... Thomas H. Ptacek (Apr 26)
- Re: Thoughts about DNS... Illuminati Primus (Apr 26)
- Re: Thoughts about DNS... Thomas H. Ptacek (Apr 27)
- BIND ID Brute Force Fix Illuminati Primus (Apr 27)
- Re: Thoughts about DNS... Illuminati Primus (Apr 27)
- Re: Thoughts about DNS... Thomas H. Ptacek (Apr 27)
- Re: Thoughts about DNS... Illuminati Primus (Apr 26)