> From: Petr Špaček <pspa...@isc.org>
> On 15. 08. 22 12:18, Kazunori Fujiwara wrote:
>>
>>> I assume section 3.2 means the EDNS bufsize in the request when it
>>> says
>>> "their payload size", but I am not sure. The text could be clearer on
>>> that.
>>>
>>>> * UDP requestors MAY probe to discover the real MTU value per
>>>> destination.
>>> How?
>> For example, recent BIND 9 starts small EDNS requestors maxiumum
>> DNS/UDP payload size (512), and increases gradually.
>
> Correction:
> Recent BIND starts with EDNS buffer size 1232 bytes, and it does not
> rise the value to "probe" the destination address by to "probe".
>
> FTR I'm testing on 9.19.5-dev commit b13d973, but I believe it is like
> that for a long time already.
THanks very much.
commit bb990030d344dafe40a62fe5ed2741de28b8ca66 removed the probing heuristics.
BIND 9.17.6 and later
5516. [func] The default EDNS buffer size has been changed from 4096
to 1232 bytes, the EDNS buffer size probing has been
removed, and named now sets the DF (Don't Fragment) flag
on outgoing UDP packets. [GL #2183]
> I think the draft as it is currently does not have enough information
> for implementers to be followed in safe way.
>
>
> I'm against publication as it is.
>
> There should be running code, experiments, and measurements to back up
> data in this draft. I can't see them at the moment.
Then, do you agree the following requirements ? (as DNS software developpers)
1. SHOULD set DF bit on outgoing UDP packets on IPv4,
and SHOULD not use FRAGMENT header on IPv6.
2. limit DNS payload size 1232 without path MTU discovery.
(After DNSFlagDay2020, many implementations use 1232)
3. If path MTU discovery works, UDP responders can send larger (>1232)
responses fit in the path MTU.
4. TCP implementations SHOULD set DF bit / not use FRAGMENT header.
(many TCP implementations already set DF bit)
# If there is a link whose MTU is smaller than 1260 (on IPv4),
# the link may be a blackhole.
Regards,
--
Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
