Dear Mr Vixie and Mr Fujiwara,
I’m a relative noob to DNS and the IETF, and I’m often confused in
how the term MTU is used when discussing DNS. Essentially it is a
layer-2 term, and outside of layer-2 it can be difficult to understand
what is meant by it. It’s a term that’s become overloaded.
Mark Andrews wrote:
>
> Also I forget how Geoff was actually performing the test. Where any of
> the responses greater than the advertised EDNS buffer size sent? Was
> fragmentation introduced when the UDP response size was less that 1280?
Just this morning I saw another report from Geoff
On Thursday, 16 July 2020 03:12:45 UTC Mark Andrews wrote:
> > On 10 Jul 2020, at 01:34, Marek Majkowski wrote:
> > ...
> >
> > Slide 34 and 35 indicate, with IPv6:
> > - 38% recursive resolvers fail to reassemble packets with
> > fragmentation extension header
>
> Which means 62% of the world
> On 10 Jul 2020, at 01:34, Marek Majkowski wrote:
>
> On Thu, Jul 9, 2020 at 3:35 AM Mark Andrews wrote:
>>> I have two problems with this proposal. First, it doesn't mention IPv4
>>> vs IPv6 differences at all. In IPv4 landscape fragmentation, while a
>>> security issue, is generally fine.
On Thu, Jul 9, 2020 at 10:28 AM wrote:
> > From: Marek Majkowski
> >> UDP requestors and responders SHOULD send DNS responses with
> >> IP_DONTFRAG / IPV6_DONTFRAG [RFC3542] options, which will yield
> >> either a silent timeout, or a network (ICMP) error, if the path
> >> MTU is exceeded.
> >
>
On Thu, Jul 9, 2020 at 3:35 AM Mark Andrews wrote:
> > I have two problems with this proposal. First, it doesn't mention IPv4
> > vs IPv6 differences at all. In IPv4 landscape fragmentation, while a
> > security issue, is generally fine. In the IPv6 world, fragmentation is
> > disastrous -
> From: Marek Majkowski
>> UDP requestors and responders SHOULD send DNS responses with
>> IP_DONTFRAG / IPV6_DONTFRAG [RFC3542] options, which will yield
>> either a silent timeout, or a network (ICMP) error, if the path
>> MTU is exceeded.
>
> When MTU is exceeded the sender might also receive
> On 9 Jul 2020, at 00:50, Marek Majkowski wrote:
>
> On Wed, Jul 8, 2020 at 10:01 AM wrote:
>>
>> DNSOP WG,
>>
>> Paul Vixie and I submitted draft-ietf-dnsop-avoid-fragmentation-00.
>> Please review it.
>
> Hi!
>
>> UDP requestors and responders SHOULD send DNS responses with
>>
On Wed, Jul 08, 2020 at 04:50:30PM +0200, Marek Majkowski wrote:
> > The maximum buffer size offered by an EDNS0 initiator SHOULD be
> > no larger than the estimated maximum DNS/UDP payload size...
>
> This seems to indicate that EDNS0 over TCP should have a small buffer
> size as well. Consider
On Wed, Jul 8, 2020 at 10:01 AM wrote:
>
> DNSOP WG,
>
> Paul Vixie and I submitted draft-ietf-dnsop-avoid-fragmentation-00.
> Please review it.
Hi!
> UDP requestors and responders SHOULD send DNS responses with
> IP_DONTFRAG / IPV6_DONTFRAG [RFC3542] options, which will yield
> either a silent
DNSOP WG,
Paul Vixie and I submitted draft-ietf-dnsop-avoid-fragmentation-00.
Please review it.
> https://tools.ietf.org/html/draft-ietf-dnsop-avoid-fragmentation-00
I may have some mistakes, I could not find links to show differences
from draft-fujiwara-dnsop-avoid-fragmentation-03.
Please see
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.
Title : Fragmentation Avoidance in DNS
Authors : Kazunori Fujiwara
Paul
12 matches
Mail list logo
