Subject: [DNSOP] Suggestion related to draft-ietf-dnsop-avoid-fragmentation

From: Brian Dickson <[email-masked]>
Date: Tue, 23 Mar 2021 21:52:48 -0700

In my comments regarding section 3.3 of the
draft-ietf-dnsop-avoid-fragmentation,
I alluded to the need for a method of validating a configured DNS UDP
default MTU value,
when a client is starting up, and has been configured to use one or more
resolvers. This test would be performed towards each resolver, as
appropriate.

If this idea is received with support, I'll write it up. It is quite
simple, I believe, and should
be easy to implement.

The short version is, the client requests a packet from the resolver, which
is exactly the
size of the MTU. This means the resolver returns a response which is padded
with data, so that the DNS payload size matches the maximum size allowed
per EDNS0 rules: the minimum of the configured value on the resolver, and
the requested value from the EDNS0 BUFSIZE value.

The suggested record name, class, type is "lorem.ipsum" CH TXT.
The value would be padded with repeated instances of the canonical
"lorem ipsum" text,
in TXT record format, truncated to the correct length to match the
requirements.
(While "quick brown fox" might be similarly suitable, it is frequently used
by test sets, and its presence as payload might cause confusion and errors.)

The resolver would set the DF bit, and if the response is not received, the
client would need to react accordingly. E.g retry, reduce size, iterate
until a response is received.

Feedback on this idea is welcome.

Thanks,
Brian Dickson

---

From: [email-masked]
Date: Tue, 30 Mar 2021 18:27:55 +0900 (JST)

> The short version is, the client requests a packet from the resolver, which is exactly the
> size of the MTU. This means the resolver returns a response which is padded with data, so that the DNS payload size
> matches the maximum size allowed per EDNS0 rules: the minimum of the configured value on the resolver, and the
> requested value from the EDNS0 BUFSIZE value.

Do you mean that each stub resolver discovers path MTU to a
full-service resolver with new method ?

If we add aggressive path MTU discovery, we should use RFC 8899
specifies Packetization Layer Path MTU Discovery for Datagram
Transports.

However, changing stub resolvers is hard.

Currently, most of stub resolvers don't use EDNS0 and don't set DO bit.
Then, fragmentation does not happen.

Software developpers of validating stub resolvers are limited.
They know DNS protocol well and limit default DNS/UDP payload size
1232 or other smaller value.

When full-service resolvers support this draft,
changing stub resolvers are not necessary, I think.

--
Kazunori Fujiwara, JPRS <[email-masked]>

> From: Brian Dickson <[email-masked]>
> In my comments regarding section 3.3 of the draft-ietf-dnsop-avoid-fragmentation,
> I alluded to the need for a method of validating a configured DNS UDP default MTU value,
> when a client is starting up, and has been configured to use one or more resolvers. This test would be performed
> towards each resolver, as appropriate.
> 
> If this idea is received with support, I'll write it up. It is quite simple, I believe, and should
> be easy to implement.
> 
> The short version is, the client requests a packet from the resolver, which is exactly the
> size of the MTU. This means the resolver returns a response which is padded with data, so that the DNS payload size
> matches the maximum size allowed per EDNS0 rules: the minimum of the configured value on the resolver, and the
> requested value from the EDNS0 BUFSIZE value.
> 
> The value would be padded with repeated instances of the canonical "lorem ipsum" text,
> in TXT record format, truncated to the correct length to match the requirements.
> (While "quick brown fox" might be similarly suitable, it is frequently used by test sets, and its presence as payload
> might cause confusion and errors.)
> 
> The resolver would set the DF bit, and if the response is not received, the client would need to react accordingly.
> E.g retry, reduce size, iterate until a response is received.
>

---

From: Brian Dickson <[email-masked]>
Date: Tue, 30 Mar 2021 13:10:15 -0700

On Tue, Mar 30, 2021 at 2:27 AM <[email-masked]> wrote:

> > size of the MTU. This means the resolver returns a response which is
> padded with data, so that the DNS payload size
> > matches the maximum size allowed per EDNS0 rules: the minimum of the
> configured value on the resolver, and the

Stub resolvers, maybe.

Forwarders, yes.

Forwarders are generally going to be either full resolver packages
configured for forwarding to resolvers, or purpose-built forwarders (but
still more capable and better maintained and more accessible than stubs).

If forwarders are close to the stub, avoiding fragmentation on the
resolver-forwarder path is probably beneficial from a
performance perspective.
This could also improve retry activity at the resolver (e.g. due to lost
fragments).

If the path from forwarder to stub happens to be on an internal network
within a DC, it is possible that jumbo frames (and thus larger
un-fragmented UDP packets) would be supported, thus eliminating
fragmentation without any changes on the stub.

If this is pursued, obviously coupling this with cookies would be a good
idea (strongly recommended or required).

Brian

> resolvers. This test would be performed
> > size of the MTU. This means the resolver returns a response which is
> padded with data, so that the DNS payload size
> > matches the maximum size allowed per EDNS0 rules: the minimum of the
> configured value on the resolver, and the
> > (While "quick brown fox" might be similarly suitable, it is frequently
> used by test sets, and its presence as payload
> > The resolver would set the DF bit, and if the response is not received,
> the client would need to react accordingly.