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

[[e-mail]]

Hi Suresh, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Suresh Krishnan <[e-mail]>
> Envoyé : lundi 17 juin 2024 12:10
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> Cc : [e-mail]; [e-mail]
> Objet : Re: [v6ops] Carrying large DNS packets over UDP in IPv6
> networks
> 
> 
> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-tsvwg-udp-
> options-32%23section-
> 11.4&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C4bcb4736fd01
> 484f075008dc8eb5a432%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7
> C638542158003670070%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=
> 96dIYE78m1YZXyWH204bSSilR2QjJrfRgkqei9aY3Vg%3D&reserved=0.
> 
> 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.
> 

[Med] I'm aware of https://datatracker.ietf.org/meeting/103/materials/slides-103-tsvwg-sessa-51-cco-and-implementation-status-for-udp-options-02 (or long version  https://datatracker.ietf.org/meeting/103/materials/slides-103-maprg-a-tale-of-two-checksums-tom-jones-00) Gorry may have more to share here I guess. 

> >
> > 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.

[Med] I thought that you had a proactive approach in mind. The cost will be an extra delay for resolution requests. This can be even exacerbated if the client blindly probes the resolver for QUIC support, in particular.

Focusing on the QUIC part, please note that RFC 9463 says the following:

"If a client learns both Do53 and encrypted DNS resolvers from the same network, and absent explicit configuration otherwise, it is RECOMMENDED that the client use the encrypted DNS resolvers for that network. If the client cannot establish an authenticated and encrypted connection with the encrypted DNS resolver, it may fall back to using the Do53 resolver."

A client that follows 9453 recommendation won't experience the resolution delay in draft-hinden. 

 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
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.