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

[Ben Schwartz <[e-mail]>]

I think the instruction to issue the request with RD=0 was helpful, even though it was not sufficient and may not be necessary.  It seems illogical for the client to say "recursion desired" when a recursively resolved answer would be rejected.

--Ben
________________________________
From: [e-mail] <[e-mail]>
Sent: Wednesday, March 6, 2024 11:07 AM
To: Mark Andrews <[e-mail]>; Ben Schwartz <[e-mail]>
Cc: tirumal reddy <[e-mail]>; [e-mail] <[e-mail]>
Subject: RE: [Add] draft-ietf-add-resolver-info-09

!-------------------------------------------------------------------|
  This Message Is From an External Sender

|-------------------------------------------------------------------!

Hi Mark, Ben,

Please let us know if the changes at [1] fix this issue.

Thank you

Cheers,
Tiru & Med

[1] https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-add-resolver-info&url_2=https://boucadair.github.io/add-resolver-information/draft-ietf-add-resolver-info.txt

> -----Message d'origine-----
> De : Add <[e-mail]> De la part de Mark Andrews
> Envoyé : mercredi 6 mars 2024 00:31
> À : Ben Schwartz <[e-mail]>
> Cc : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
> tirumal reddy <[e-mail]>; [e-mail]
> Objet : Re: [Add] draft-ietf-add-resolver-info-09
>
>
>
> > On 6 Mar 2024, at 08:19, Ben Schwartz <[e-mail]> wrote:
> >
> >
> >> On Mar 5, 2024, at 4:02 PM, Mark Andrews <[e-mail]> wrote:
> >
> >> Stop using +short and look at all of the response including whether
> aa is set or not in the flags.
> >
> > It is not set.  My complaint is that draft-ietf-add-resolver-info-11
> doesn’t mention the AA bit at all.  It needs to instruct the client to
> inspect this bit, and reject the response if AA=0.
>
> Yep.
>
> > draft-11 still contains text about the record appearing in the
> Authority section, which could be equivalent to this, but that text is
> in a different section and its normative effect on the client is
> unclear.  I don’t object to that text, but I don’t think it’s
> sufficient as written, and I don’t think it’s necessary if the client
> is required to enforce AA=1.
>
> That whole paragraph should be removed.
>
> > —Ben
> >
> >>
> >> --
> >> Mark Andrews
> >>
> >>> On 6 Mar 2024, at 07:09, Ben Schwartz <[e-mail]> 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
> >>>
> https://eur03.safelinks.protection.outlook.com/?url=http://www
> >>>
> .google.com%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C886ca
> >>>
> c3b3900432f540308dc3d6c5562%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7
> >>>
> C0%7C638452782716903830%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
> >>>
> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ml
> >>> L4GilpuruZ0Bz%2FR3YEY07eNE%2FRXs1%2B4EHa6eAIOL8%3D&reserved=0
> >>> @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
____________________________________________________________________________________________________________
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.