[dns-operations] DNS flag day 2020: Recommended EDNS buffer size discussion

[Paul Vixie]

On Monday, 2 September 2019 17:31:50 UTC Lee wrote:
> On 9/2/19, Paul Vixie <paul at redbarn.org> wrote:
> > ...
> >> 
> >> we should not needlessly invent something that's different from TCP MSS.
> >> just use what works.
> 
> I think tcp mss working as well as it does is because the mss is
> negotiated at connection setup time (syn, syn+ack option tcp mss
> size).

no.

> Your machine can figure out the mss & middle boxes that know
> better can reduce the mss value to something they know will work.
>   eg. 'ip tcp adjust-mss ' in ciscoland
>  
> https://www.cisco.com/en/US/docs/ios-xml/ios/ipapp/command/ip_tcp_adjust-ms
> s_through_ip_wccp_web-cache_accelerated.html#GUID-68044D35-A53E-42C1-A7AB-92
> 36333DA8C4
> 
> How do you do that with udp?

TCP MSS is an offer not an acknowledgement, and it proceeds from local 
knowledge of the path MTU like the routing table or the sysctl definitions set 
by a sysadmin. generally speaking path MTU discovery does not work and is not 
used, and so there is no automated process i know of today which populates the 
ro_mtu field of "struct route" (in /usr/include/net/route.h, at least on BSD 
systems). however, it can be set in static routes, and it is always set on 
interface routes, and it is almost always set on default routes.

if PMTUD is ever made to work, then its findings will go into the place where 
TCP looks for them, which is the routing table.

DNS should look in the same place, for the same reasons.

in WIN32, Microsoft exposes this as follows:

https://docs.microsoft.com/en-us/windows/win32/rras/search-for-the-best-route

in BSD and Linux, there is no easy way to get this information. that should 
change.

-- 
Paul