maybe a dumb idea on how to fix the dns problems i don't know....

William Herrin herrin-nanog at
Sun Aug 10 22:21:01 CDT 2008

On Sat, Aug 9, 2008 at 5:18 PM, Chris Paul <chris.paul at> 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 at> 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,
then he looks up, then, etc. until he gets
one where the server accepts his fake DNS server record for

To be an effective defense, you'd have to do TCP lookups for the whole
scope ({anything} 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 at> 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 at> 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

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.

Bill Herrin

William D. Herrin ................ herrin at bill at
3005 Crane Dr. ...................... Web: <>
Falls Church, VA 22042-3004

More information about the NANOG mailing list