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

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

 



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

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