[tsvwg] Re: [v6ops] Carrying large DNS packets over UDP in IPv6 networks

[Suresh Krishnan <[e-mail]>]

Hi Med,

> On Jun 14, 2024, at 10:10 AM, [e-mail] wrote:
> 
> Hi Suresh, all,
> 
> (ccing tsvwg)
> 
> FWIW, large DNS packets was the main driver for the FRAG UDP option: https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-32#section-11.4. 

Thanks for this pointer. I read the draft based on your message as well as Joe’s mail downthread. It is very interesting and I would love to learn more about the implementations on the client side and whether it would be a viable alternative in the near term.

> 
> On the reco in the draft, I'm not sure how this can be put into effect given that the client does not know whether the reply will be large or not when it reaches out a resolver.

As far as I know, there are two ways by which a client figures this out currently. When the TC bit is set in the response the client can switch to TCP/QUIC as recommended. Also based on the recommendations in the draft-ietf-dnsop-avoid-fragmentation draft, the client can use a timeout as a signal to switch to TCP or use a smaller EDNS UDP payload size to retry. Do you think any additional mechanisms are necessary?

> 
> Also, when you mention "DNS over QUIC" are you referring to DoQ per RFC 9250?

Yes. This is the intention as mentioned in Section 4.2 of the draft.


> If so, I'm afraid that there are many implications (e.g., authentication, compatibility with the presence of local forwarders). Also, if DoQ is recommended, why not DNS over TLS or DNS over HTTPS? You may refer to DNR/DDR (RFC9463/9462) for the discovery matters of whether local resolvers support DoQ, DoH, DoT, etc. + which authentication domain name to be used to authenticate a server.

I am sure these are all possible and we are totally open to discuss these options and fold them in if needed. When we wrote the -00 draft we were mainly focusing on the use of a more complete transport protocol than UDP to avoid IPv6 fragmentation. Hence the recommendation to use TCP or QUIC.

Thanks
Suresh