[dns-operations] latest bind, EDNS & TCP

[Mark Andrews]

BIND 9.10 starts at 512.  If it gets TC=1 it will retry with TCP.
This estabishes whether the server supports EDNS or not.  The next
time it talks to the server it will try at 4096 and if that times
out it will fall back to what it knows works and if that get TC=1
it will go to TCP.

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.

It it get three timeouts at 4096 it will drop the size to 1432 if
that timeout it will drop the buffer size to 1232.

You can see where named is up to if you run rndc dumpdb.

4 successful EDNS queries to 199.212.0.108 and the largest response
is 1319 bytes.

199.212.0.108 [srtt 179321] [flags 00806000] [edns 4/0/0/0/0] [plain 0/0] [udpsize 1319] [ttl 678]

Authoritative server operators can help by ensuring that they
generate packets that are unlikely to cause PMTUD.  Path MTUD does
not work with DNS/UDP as the server don't have the data to generate
a new packet when it get a PTB message.

If you don't want problems don't set DF=1 for IPv4 UDP.
If you don't want problems fragment at 1280 for IPv6 UDP.

TCP also has issues with PMTUD for many TLDs as the PTB's don't
appear to make it through to the correct box.  For IPv6 force the
interface MTU to 1280 so that there shouldn't be a need to get
PTB's.  IPV6_USE_MIN_MTU should also do this but not all OS's
implement it nor is it properly integrated with MSS negotiation in
all OS's.  Named sets IPV6_USE_MIN_MTU on both UDP and TCP sockets.

Named starts at 512 because that reduces the number of variable tha
can trigger a timeout.  If TLD's really want to help they will audit
the servers for the delegated zones to ensure that they respond
correctly to CD=1 queries, AD=1 queries, EDNS queries, DO=1 queries,
EDNS with unknown versions, EDNS queries with unknown options, EDNS
queries with unknown flags.  That they respond to queries other
than A or AAAA correctly. 

Note: The correct response to EDNS queries varies depending upon
whether the server supports EDNS or not.

"timeout" is never a correct response.  A number of TLD operators
need to fix their own servers in this respect.

Mark

In message <5439014A.9000601 at cdns.net>, Simon Munton writes:
> On 11/10/14 10:56, Peter Koch wrote:
> > What makes you believe that your larger reponses (fragments?) really
> > make it through?
> 
> OK - I see what you mean now.
> 
> If someone, for example, was filtering UDP fragments somewhere in the 
> path, the effect would be the same.
> 
> 
> A Path-MTU of 512 for so many resolvers seems terribly small - although 
> I seems to remember from Nominet's analysis of DSL routers many are 
> limited to 512 in their DNS proxy, but the fact this came in rather 
> suddenly does not fit with that being the source of the issue.
> 
> 
> I really have no idea what the cause is, I was simply alarmed by the 
> sudden and significant increase in TCP, and the bind policy change on 
> bufsize seemed to be related.
> 
> Presumably the code change was to resolve exactly the possibility you 
> describe?
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org