[dns-operations] maybe a dumb idea on how to fix the dns problems

[Roger Marquis]

Chris Paul wrote (in NANOG):
> 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.....

That's the best idea I've read so far. You wouldn't want to toggle
protocols on the first mismatch, but maybe the 10th or 50th. Would also be
worthwhile to factor in some rate limiting and an algorithm for timing the
toggle-back. Stir in some simple statefulness via btree and voila. We do
something like this with Python-based IDS scripts and it's really not all
that complex.

Add in a few more bits of randomness and you would have some robust
hardening. Better than simply randomizing udp ports IMO, particularly from
the packet filtering side of the equation.

Paul Vixie wrote (in NANOG):
> TCP is considered optional by many authority DNS server operators. it's
> only required if you expect AXFR or if you ever emit a TC bit. if you don't
> want to do TCP then you can rule out the TC bit and AXFR and just not do
> TCP, and you'll be dead-to-rights within the various DNS protocol RFCs.

Could be an opportune time to update the RFCs and discourage 53/tcp
filtering. Are there reasons not to?

Roger Marquis