[dns-operations] DNS flag day 2020: Recommended EDNS buffer size discussion
paul at redbarn.org
Mon Sep 2 23:35:03 UTC 2019
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.
More information about the dns-operations