[email protected] wrote:
> to wit:
>
> -P, --edns-packet-max=<size>
> Specify the largest EDNS.0 UDP packet which is supported by
> the DNS for-
> warder. Defaults to 1280, which is the RFC2671-recommended
> maximum for eth-
> ernet.
>
> Is there any interest in revisting this RFC or should we be happy with a
> functional limit
> on EDNS0 message size being 1280 bytes?
The RFC needs revision.
First of all, because the largest IPv4 header is 60B and UDP
header is 8B, the following statement:
> 4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP
> reassembly buffer.
is wrong and DNS requires the IPv4 reassembly buffer 580B or larger,
which is beyond the requirement of 576B in RFC791.
But, we can reasonably expect reassembly buffer > 1400B, of course.
Then, it is reasonable to allow messages as large as 1280B over IPv4,
as long as don't fragment bit is *NOT* asserted.
Further, *IF* we can safely assume path MTU larger than 1348B,
don't fragment bit may be asserted. But, if we can assume path
MTU larger than 1348B, there is no point to perform path MTU
discovery to send a 1348B packet. That is, we don't have to
assert the don't fragment bit.
On the other hand, for IPv6, as the minimum MTU is only 1280B long,
even when there are no extension headers, DNS message size can be
only as large as 1280-40-8=1232B.
Worse, as extension headers are silently inserted for mobility and
other purposes and can be infinitely lengthy, the DNS message size
safely carried over IPv6 is 0B.
You can request IETF to limit the maximum length of extension headers
below certain limit (e.g. 208B to allow for 1024B messages), though
a request was formally rejected by IPv6 WG when I did so last time
with the exact example of the DNS message size requirement.
It should be a lot of fun, because the request imply to change
the IPv6 specification and all the implementations (at least
those following RFC3542).
Or, just stick to (port restricted) IPv4 and to ignore IPv6
saying "you have been warned".
Masataka Ohta
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
