Re: [Add] draft-ietf-add-resolver-info-09

[[e-mail]]

Hi Steffen, 

> By the way i am really not worth being noted for anything
> acknowledgeable regarding the work of this WG.  

FWIW, the ACK is specific to all those who commented on the specific RR formatting issue in the mailing list:

==
Thanks to Mark Andrews, Joe Abley, Paul Wouters, and Tim Wicinski for the discussion on the RR formatting rules
==

I just removed you from that list: https://github.com/boucadair/add-resolver-information/commit/10718504b0de570fc59ea1aedb729fac1ef032de

Cheers,
Med

> -----Message d'origine-----
> De : Add <[e-mail]> De la part de Steffen Nurpmeso
> Envoyé : mardi 20 février 2024 20:30
> À : tirumal reddy <[e-mail]>
> Cc : Mark Andrews <[e-mail]>; [e-mail]
> Objet : Re: [Add] draft-ietf-add-resolver-info-09
> 
> tirumal reddy wrote in
>  <[e-mail]>:
>  |On Thu, 15 Feb 2024 at 06:02, Mark Andrews <[e-mail]> wrote:
>  |> Why is it necessary to change the standard processing of queries
> for  |> RESINFO when we already have a signal (AA=1) about whether the
> answer  |> is coming from elsewhere or not ?
>  |
>  |It is introduced to handle a scenario where SUDN is used to discover
> the  |encrypted resolver, and if the discovered resolver does not
> support  |RESINFO, it will forward the query upstream. An attacker
> might provide a  |RESINFO response with AA=1. The proposed mechanism
> aims to help the client  |identify whether the response is coming from
> the discovered encrypted  |resolver.
> 
> By the way i am really not worth being noted for anything
> acknowledgeable regarding the work of this WG.  At all.
> If you have another iteration of the document, i would prefer if you
> would simply scratch my name from your work.
> It is solely your work, for sure.
> And the above is possibly very smart: my DNS work was two decades ago,
> and i could not even tell whether i have ever seen authority section
> entries being passed through or not.
> 
> My main topics are simplicity so small teams can still exist
> competetively as was true over two decades ago (ie, with knowing the
> entire picture, not by delegating to "trusted" external modules in
> uncounted numbers), when there were <3000 RFCs.
> 
> As such i very much appreciated RFC 8499, but i alone from my
> superficial out-of-interest reading have 17 DNS-related RFCs added
> locally since then, plus the draft of yours and whatever else from
> this WG.
> 
> And a different way to get the TLS trust (or, rather, use existing
> ways of various kind eg rpki, ikev2, or simply public keys as is done
> by DKIM (certificates are a bit larger, but with the TCP that is more
> and more needed per se, or QUIC; or even the permanent HTTP proxying
> of everything, that is "no problem")) away from CA pools, to DNS/TLS +
> DNSSEC zone records.  Thank you for that, too!
> 
> Ciao, and greetings from Germany,
> 
> --steffen
> |
> |Der Kragenbaer,                The moon bear,
> |der holt sich munter           he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off (By Robert
> Gernhardt)
> 
> --
> Add mailing list
> [e-mail]
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fadd&data=05%7C02%7Cmohamed.boucadair%4
> 0orange.com%7C500a775487b6483b54d108dc324a6dd5%7C90c7a20af34b40bfbc48b
> 9253b6f5d20%7C0%7C0%7C638440542457440730%7CUnknown%7CTWFpbGZsb3d8eyJWI
> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7
> C%7C&sdata=Fi0T%2FNbDwmbuVZU8Oxeg3jIzcySa6Jk3vb2Nu%2FgQdSE%3D&reserved
> =0
____________________________________________________________________________________________________________
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.