Re: [Last-Call] DDR A/AAAA fallback RE: [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

<mohamed.boucadair@xxxxxxxxxx> · Thu, 30 Jun 2022 07:02:04 +0000

Hi Tommy,

Please see inline.

Cheers,
Med

De : Tommy Pauly <tpauly@xxxxxxxxx> 

Envoyé : mercredi 29 juin 2022 16:55

À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@xxxxxxxxxx>

Cc : Martin Thomson <mt@xxxxxxxxxxxxxx>; add@xxxxxxxx; last-call@xxxxxxxx

Objet : Re: [Last-Call] DDR A/AAAA fallback RE: [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, 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.

[Med] Yes. 

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

[Med] Agree, such a case can be discussed as part of this text in DDR:

   A DNS client that already knows the name of an Encrypted Resolver can
   use DDR to discover details about all supported encrypted DNS
   protocols.  This situation can arise if a client has been configured
   to use a given Encrypted Resolver, or if a network provisioning
   protocol (such as DHCP or IPv6 Router Advertisements) provides a name
   for an Encrypted Resolver alongside the resolver IP address, such as
   by using Discovery of Network Resolvers (DNR) [I-D.ietf-add-dnr].

The text may be tweaked. For example, “..has been configured to use a given Encrypted
 Resolver..” part can be expanded a bit to discuss both the case where an encrypted protocol is configured as well and the case where it isn’t. The change is straightforward and allows for consistent behaviors. Thanks.  

, but if that’s a strategy we’d want to suggest, I think that belongs more in DNR than DDR

[Med] I still think this is related to DDR: the information about an explicit support of a given encrypted protocol is only available to the DNS client itself, not DHCP clients.

, 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

_________________________________________________________________________________________________________________________

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