Re: [Last-Call] [Add] DDR A/AAAA fallback RE: Last Call: <draft-ietf-add-dnr-09.txt> (DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)) to Proposed Standard

[<mohamed.boucadair@xxxxxxxxxx>]

Re-,

 

I think Tommy was referring to configuring ONE single protocol.

 

If more are available/configured, then probing should be avoided for the same reasons we are avoiding it in DNR:

 

==

   Nevertheless, this approach requires a

   client that supports more than one encrypted DNS protocol (e.g., DoH

   and DoT) to probe that list of IP addresses.  To avoid such a

   probing, the options defined in Sections 4, 5, and 6 associate an IP

   address with an encrypted DNS protocol.  No probing is required in

   such a design.

==

 

SVCB should be preferred in DDR whenever more than one encrypted protocol is supported/configured. That’s also an aspect worth to be mentioned in Section 5 of DNR.

 

Thanks.

 

Cheers,

Med

 

De : tirumal reddy <kondtir@xxxxxxxxx>
Envoyé : jeudi 30 juin 2022 09:36
À : Tommy Pauly <tpauly=40apple.com@xxxxxxxxxxxxxx>
Cc : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@xxxxxxxxxx>; Martin Thomson <mt@xxxxxxxxxxxxxx>; add@xxxxxxxx; last-call@xxxxxxxx
Objet : Re: [Add] [Last-Call] DDR A/AAAA fallback RE: Last Call: <draft-ietf-add-dnr-09.txt> (DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)) to Proposed Standard

 

On Wed, 29 Jun 2022 at 20:26, Tommy Pauly <tpauly=40apple.com@xxxxxxxxxxxxxx> wrote:

Thanks, Med.

 

To be clear, what is the question about A/AAAA fallback? If you only have an ADN, and you thus don’t have information about which encrypted DNS protocol (or the protocol details) until you do an SVCB query for the name, you will need to do the DDR query for the SVCB record to get the information.

 

I suppose nothing stops the client from just assuming that the support is DoT or DoH with the common URI template and trying to connect anyhow, but if that’s a strategy we’d want to suggest,

 

The client will have to try multiple probes in parallel (e.g., DoT, DoH and DoQ) to figure out the encrypted transport supported by the resolver and the client may possibly get an invalid response with the common URI template. If the client has enabled DNSSEC, encrypted transport is not required. If the client uses Do53 (without DNSSEC), it could be subjected to a downgrade attack (e.g., attacker removing SvcParamKeys like ECH etc). In this case, security considerations in draft-ietf-add-svcb-dns need to be taken into account.

 

-Tiru

 

I think that belongs more in DNR than DDR, since it’s specific to a case where the DNR information only contains a name, and then is about clients using something other than DDR to actually connect to the resolver.

 

Best,

Tommy

On Jun 29, 2022, at 4:26 AM, mohamed.boucadair@xxxxxxxxxx wrote:

 

Hi Martin,

(updating the subject so that this can be tracked by DDR authors).

I left that unanswered in my previous reply because I think this is a question for DDR, not DNR.

Thanks.

Cheers,
Med

-----Message d'origine-----
De : Martin Thomson <mt@xxxxxxxxxxxxxx>
Envoyé : mercredi 29 juin 2022 02:50
À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@xxxxxxxxxx>;
add@xxxxxxxx; last-call@xxxxxxxx
Objet : Re: [Last-Call] [Add] Last Call: <draft-ietf-add-dnr-
09.txt> (DHCP and Router Advertisement Options for the Discovery
of Network-designated Resolvers (DNR)) to Proposed Standard

Thanks for the response Med.

...

You missed this piece:

Do you have an A/AAAA fallback?

 

_________________________________________________________________________________________________________________________

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.

--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

 

--
Add mailing list
Add@xxxxxxxx
https://www.ietf.org/mailman/listinfo/add

_________________________________________________________________________________________________________________________

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.

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call