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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Jun 30, 2022, at 10:46 AM, mohamed.boucadair@xxxxxxxxxx wrote:

Hi Tommy,
 
Thanks.
 
The case I had specifically when reading the initial comment from Martin is a DoT-only client behind a forwarder. If a name is configured (which is the assumption of Section 5 of DDR), nothing stops to configure a specific protocol as well.
 
For such a case, falling back to A/AAAA would be just OK especially that the current text says that SVCB records SHOULD be in the public DNS.
 
Other than that, I think the text should be clear in recommending against probing + prefer the use of SVCB.

I don’t know if I necessarily want to say that in a document. DDR defines how to use SVCB to get the information. I don’t necessarily want to say that clients SHOULD NOT use some other probing heuristic that they may already have, or that may be defined in the future. Defining an alternate approach in sufficient detail to say it should or should not be preferred seems a bit out of scope here, IMO.

Tommy

 
 
Cheers,
Med
 
De : Tommy Pauly <tpauly@xxxxxxxxx> 
Envoyé : jeudi 30 juin 2022 19:39
À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@xxxxxxxxxx>
Cc : 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
 
Hi Med,
 
The text you quote in DDR, which refers to the fact that we can already know about a name (from DNR or some other config) and then use it for a DDR look up is specifically to explain when we’d do the SVCB DNS query for a specific name, rather than resolver.arpa.
 
The idea of a fallback to not use SVCB to look up the properties, but just try some encrypted DNS connections with default settings opportunistically isn’t something I think belongs in DDR. Specifically, that is the case where a client does not use DDR. For DoT, that’s effectively an opportunistic mode, as already defined.
 
If for some reason, we think we need a document describing purely opportunistic probing of different encrypted DNS protocols, I think that should be something separate. I don’t think it’s appropriate to add that into DDR (or DNR, likely) at this point of last call.
 
Best,
Tommy


On Jun 30, 2022, at 12:02 AM, mohamed.boucadair@xxxxxxxxxx wrote:
 
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.
 
_________________________________________________________________________________________________________________________

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

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux