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 <[email protected]>, 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 > [email protected] > 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: [email protected] _______________________________________________ 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
