[dns-operations] latest bind, EDNS & TCP

[Simon Munton]

> BIND 9.10 starts at 512.  If it gets TC=1 it will retry with TCP.
> This establishes whether the server supports EDNS or not.

Even if the EDNS data is included in the TC=1 reply?

> Named will record the actual size of the UDP response it gets and
> use that, provided it is > 512 as the minimum when it talks to the
> server again.

So, if a server did not include *any* DNSSEC proof, unless it was able 
to fit it *all* in, is it possible that bind could conclude that it can 
only receive small packets from that server (and fall back to TCP).

Is that correct ?

> Authoritative server operators can help by ensuring ...

This is all useful advice - however, all just as true before the sudden 
increase in use of TCP - so not necessarily useful in trying to identify 
the cause of the sudden increase.

As I have said before, I have *no* idea where the sudden increase in TCP 
usage is coming from, but as bind has changed its policy on its use of 
bufsize, it seems a *possibility*.

A single carrier starting to mishandle UDP fragment seems just as 
likely, hence asking if anybody else is seeing this - although I'd hope 
carriers are more aware of the dangers in this area, now DNSSEC has been 
in the wild for some time - may be wishful thinking.



After further investigating the example I posted, and a number of the 
other ones we are seeing in Vienna, it seems a lot of the TCP traffic is 
coming from name server owned by T-Mobile who seems to have deliberately 
limited their bufsize to 512 bytes - they all reply with

; EDNS: version: 0, flags:; udp: 512

If this is the case, I would expect *all* owners of signed zones to be 
seeing the same behaviour we are seeing - from these servers.

Is limiting the maximum bufsize in this way a new feature?

> "timeout" is never a correct response.

Unfortunately, the most common cause of this will be in transit, so 
outside the knowledge or control of either DNS operator, e.g. incorrect 
filtering of UDP fragments, incorrect fragment handling or low packet 
size support on a DNS proxy (e.g. DSL router), etc.