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.
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
