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

Stop using +short and look at all of the response including whether aa is set or not in the flags. 

-- 
Mark Andrews

> On 6 Mar 2024, at 07:09, Ben Schwartz <bemasc@meta.com> wrote:
> 
> 
> Mark's suggestion is correct, but I don't think draft-11 captures it correctly.  The draft-11 text only says
> 
>    The DNS client MUST set the Recursion
>    Desired (RD) bit of the query to 0 to ensure that the response is provided by the resolver.
>    If the resolver does not support RESINFO, it will return an authoritative name error.
> 
> This is factually incorrect, as can be observed by sending an RD=0 query to an ordinary recursive resolver:
> 
> % dig +short +norecurse www.google.com @1.1.1.1
> 142.251.167.104
> 142.251.167.147
> 142.251.167.99
> 142.251.167.106
> 142.251.167.103
> 142.251.167.105
> 
> Mark's suggestion is that the client verify that the response has AA=1.  That check ensures that the result was not populated insecurely over the network, but the draft doesn't mention it.
> 
> --Ben
> From: Add <add-bounces@ietf.org> on behalf of mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
> Sent: Wednesday, February 21, 2024 2:37 AM
> To: Mark Andrews <marka@isc.org>
> Cc: tirumal reddy <kondtir@gmail.com>; add@ietf.org <add@ietf.org>
> Subject: Re: [Add] draft-ietf-add-resolver-info-09
>  
> !-------------------------------------------------------------------|
>   This Message Is From an External Sender
> 
> |-------------------------------------------------------------------!
> 
> Hi Mark, all, 
> 
> We think this is fair. Thanks. 
> 
> We created a PR to fix this: https://github.com/boucadair/add-resolver-information/pull/19/files.
> 
> Cheers,
> Tiru & Med
> 
> > -----Message d'origine-----
> > De : Add <add-bounces@ietf.org> De la part de Mark Andrews
> > Envoyé : mercredi 21 février 2024 01:50
> > À : Steffen Nurpmeso <steffen@sdaoden.eu>
> > Cc : tirumal reddy <kondtir@gmail.com>; add@ietf.org
> > Objet : Re: [Add] draft-ietf-add-resolver-info-09
> > 
> > If a recursive server passes through a response with AA=1 it is
> > broken. If a recursive  server forwards a query with RD=0 it is
> > broken.  If a “recursive server” is just forwarding queries and
> > responses the attacker will just put the response in the authority
> > section.  The change of section provides no security. It doesn’t
> > prevent problems. It is just change for changes sake.
> > 
> > --
> > Mark Andrews
> > 
> > > On 21 Feb 2024, at 06:30, Steffen Nurpmeso <steffen@sdaoden.eu>
> > wrote:
> > >
> > > tirumal reddy wrote in
> > > <CAFpG3gd5GwSAoOs3SX2xWZyKVR7F5y-
> > y1VxxbTmfooC4AWo5Mw@mail.gmail.com>:
> > > |On Thu, 15 Feb 2024 at 06:02, Mark Andrews <marka@isc.org> 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
> > Add@ietf.org
> > https://eur03.safelinks.protection.outlook.com/?url=https://www .
> > ietf.org%2Fmailman%2Flistinfo%2Fadd&data=05%7C02%7Cmohamed.boucadair%4
> > 0orange.com%7C3a00adf00f6c4a88f66d08dc32770e24%7C90c7a20af34b40bfbc48b
> > 9253b6f5d20%7C0%7C0%7C638440734117558876%7CUnknown%7CTWFpbGZsb3d8eyJWI
> > joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7
> > C%7C&sdata=GUI2%2FfrtBz%2FtYaA8ZmAGjR2jzb8mcp%2BmewuFjMiI3CE%3D&reserv
> > ed=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.
> -- 
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add 