On 09/06/11 15:37, Ewen McNeill wrote:
If anything, to echo Jay, this seems like "over engineering" to solve a perceived problem that I'm not really convinced will exist in real life for more than a trivial amount of time.�� If it turns out that there is a genuine need at the initial deployment to allow more time for people to deal with the packet fragmentation/no-TCP issue, I'd probably live with "1280-bit ZSK in first year, raised to 1536-bit/2048-bit after 12 months" as a policy.�� But it's not clear to me that even that is needed.

I'd add the observation that for heavy DNS, fall back to TCP needs to be an absolute last resort. TCP fall-back has three major drawbacks:
  1. It puts a lot more load on the name server as it has to keep state. Stateful things are inherently vulnerable to denial of service attacks by overflowing state tables. (Maybe Geoff Huston's "stateless TCP DNS" needs more research ...)
  2. There are delays setting up the TCP session. A UDP transaction's takes only one RTT to complete (assuming processing time is negligible). A TCP response requires a three way handshake, plus data, plus session close, or three times RTT. Add another RTT for the truncated UDP response. If that DNS server is over 250 ms away (e.g. eastern USA, or Europe), that's a full second to get a response; a few referrals and those seconds start adding up.
  3. TCP fall-back only occurs on receiving a truncated response (TC bit set).
3. is a killer if a fragmentation black-hole exists. If a fragmented packet does not (fully) arrive, the DNS resolver gets no indication that it needs to fall back to TCP. Failure to get the response will cause it to retry another server, not fall back to TCP, which if the fragmentation black-hole is nearby means you just don't get a response.

And of course there are still idiots configuring firewalls who think DNS only works on UDP.

I haven't done all the numbers, but I have to say that avoidance of both fragmentation and truncation needs to be a goal in setting key sizes. Gut feel is that one should be aiming for layer 3 packet lengths of < 1400 octets, possibly less to allow for tunneling, PPPoE and other not-quite-1500 MTU channels.

-- don