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

[Paul Vixie]

On Monday, 2 September 2019 23:26:47 UTC Lee wrote:
> On 9/2/19, Paul Vixie <paul at redbarn.org> wrote:
...
> > see also this text from RFC 1122:
> >> However, in general the TCP layer may not have the
> >> appropriate information to make this decision, so it is
> >> preferable to leave to the IP layer the task of
> >> determining a suitable MTU for the Internet path.  We
> >> therefore recommend that TCP always send the option (if
> >> not 536) and that the IP layer determine MMS_R as
> >> specified in 3.3.3 and 3.4.  A proposed IP-layer
> >> mechanism to measure the MTU would then modify the IP
> >> layer without changing TCP.
> > 
> > the final sentence is, to me, the key to the future of PMTUD(6).
> 
> I thought we both agreed that path mtu discovery couldn't be relied
> on, but whatever..

i thought we agreed it wasn't working today.

> > what i am asking is that any standard we write be future-proof in the 
> > sense that whatever "practical maximum" is chosen (1200, or similar) 
> > be described in the context of "unless better information is available".
> 
> I think I understand now.  "unless better information is available"
> sounds reasonable enough

and, there _is_ better information available, like the local routing table, or 
the local interface table. a DNS QUERY initiator (stub or full resolver, for 
example) which is multihomed, has a SLIP link (576 MTU) as well as an internal 
ethernet (1500 MTU) would be unwise to use a single value (such as either 1200 
or 500) for all its queries. if it uses 1200 for everything, it'll have to use 
TCP for many SLIP-sent queries. if it uses 512 for everything, it'll have to 
fall back to TCP for many ethernet-sent queries.

-- 
Paul