On Sat, Aug 9, 2008 at 5:18 PM, Chris Paul <chris.paul@rexconsulting.net> wrote:
Sorry if this is real stupid for some reason because I don't think about DNS all day (I'm the ldap dude) but since we have faster networks and faster cpus today, what would be the harm in switching to use TCP for DNS clients? The latency on the web isn't dns anymore ever it seems to me.....
Latency on in-addr lookups where you typically traverse multiple forward trees to find the NS servers would seriously suck. At best, a TCP-based lookup performs at about a third of the speed of a UDP lookup. Worse unless your implementation is carefully optimized and you make sure that the OS isn't adding options to the front of the handshake. You have at least the whole syn/synack/ack handshake before you can even ask the question. Then there's the server cost associated with keeping that much state... On Sat, Aug 9, 2008 at 6:10 PM, Matt F <matt@credibleinstitution.org> wrote:
Why not just require TCP for a lookup if a response with an incorrect TXID is received? You could require TCP for just the one lookup or for some configured interval, say 1 hour. That should slow attackers down substantially.
Because the attacker is using a sequence of lookups in order to hit one that lets him poison the cache. That is, he looks up a.google.com, then he looks up b.google.com, then c.google.com, etc. until he gets one where the server accepts his fake DNS server record for google.com. To be an effective defense, you'd have to do TCP lookups for the whole scope ({anything}.google.com) for some period of time following the bad ID. That in turn would open up a potential DOS where an attacker could force the DNS server to fall back on TCP for essentially everything, overwhelming it. On Sat, Aug 9, 2008 at 8:25 PM, brett watson <brett@the-watsons.org> wrote:
On Aug 9, 2008, at 3:48 PM, Chris Paul wrote:
Hey authority DNS server operators. Can you make a change to your servers to always allow TCP client connections? Would this be difficult? What would be the harm?
SYN flooding?
SYN flooding is a solved problem. On Sat, Aug 9, 2008 at 6:04 PM, Joe Abley <jabley@ca.afilias.info> wrote:
TCP works pretty well with anycast too, if you're careful. It's helpful if your transactions are short-lived.
Define "careful." It's always possible for someone to find themselves with an equal cost path to two different servers in the anycast set. Add per-packet load balancing at the fork (which is outside the control of the server operator) and what happens is the request times out and the resovler fails over to the other NS record that isn't anycasted. Though the protocol is simple enough that it might be possible to fake it. Build yourself a DNS-only stateless TCP stack for the anycasted address. Have the server send the syn-ack without creating any state. The request will almost certainly be entirely contained in one packet, so when it arrives reply to it without creating any state. Ship off as many packets as you need to reply followed by a Fin. Blindly ack any packet that looks like it needs it. If any packets are lost, there won't be any retransmit (you haven't really established a TCP connection) so the query will time out and retry. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004