Re: [Add] [ietf-wg-add/draft-ietf-add-ddr] Clarifying IP hint behavior (#12)

If geolocality applies to the IP addresses being returned, putting them in
the Additional section would (I think) actually exclude EDNS Client Subnet
usage.

>From RFC 7871 section 7.3.1:

   Note that the Additional and Authority sections from a DNS response
   message are specifically excluded here.  Any records from these
   sections MUST NOT be tied to a network.

On Tue, Mar 23, 2021 at 9:39 AM Tommy Pauly <tpauly=
40apple.com@dmarc.ietf.org> wrote:

>
>
> On Mar 23, 2021, at 9:21 AM, Tommy Jensen <
> Jensen.Thomas=40microsoft.com@dmarc.ietf.org> wrote:
>
> Thank you for the feedback, Ben, and for the indirect reminder to bring
> the PR to the list.
>
> What does the list think re: SHOULD include IP hints versus SHOULD NOT in
> favor of A/AAAA records? The full text changes I am proposing to address
> Issue #2 and #5 can be found here: Clarifying IP hint behavior by
> mstojens · Pull Request #12 · ietf-wg-add/draft-ietf-add-ddr (github.com)
> <https://github.com/ietf-wg-add/draft-ietf-add-ddr/pull/12/files>
>
>
>
> If the A and AAAA are in the additional section, that’s good too. As long
> as we say that the SVCB, A, and AAAA information should all come in one
> response, that’s fine with me. I’d suggest wording it to clarify that
> that’s the intent, and to prefer the use of an additional section, but
> mention hints too.
>
> Tommy
>
>
> Thanks,
> Tommy
>
> *From:* Benjamin M. Schwartz <notifications@github.com>
> *Sent:* Monday, March 22, 2021 6:46 PM
> *To:* ietf-wg-add/draft-ietf-add-ddr <
> draft-ietf-add-ddr@noreply.github.com>
> *Cc:* Tommy Jensen <Jensen.Thomas@microsoft.com>; Author <
> author@noreply.github.com>
> *Subject:* Re: [ietf-wg-add/draft-ietf-add-ddr] Clarifying IP hint
> behavior (#12)
>
>
> I think we should invert this advice. We should recommend *not* including
> IP hints, and instead instruct recursive resolvers to append the relevant A
> and AAAA records in the Additional Section.
>
> The IP hints are strictly a performance hack when using a legacy *non*-SVCB-aware
> recursive resolver. This text is specifically applicable only to SVCB-aware
> recursive resolvers, so we can tell them to do it the right way instead.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-wg-add%2Fdraft-ietf-add-ddr%2Fpull%2F12%23issuecomment-804521139&data=04%7C01%7CJensen.Thomas%40microsoft.com%7Cab39b2a73e844921ce6708d8ed9d6a56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637520607647347856%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3wYmgzzOtGuj4CBxE5l3C1Ssy%2BO8bu52ICve%2F%2FNIGuY%3D&reserved=0>,
> or unsubscribe
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAKYFHAW2LG5WPFIF7W7T24DTE7XFTANCNFSM4ZUBYGHA&data=04%7C01%7CJensen.Thomas%40microsoft.com%7Cab39b2a73e844921ce6708d8ed9d6a56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637520607647347856%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ebif56IWGHQRSnX4nSXvejbaPk3MRn%2BAxCMpkjgiPJg%3D&reserved=0>
> .<~WRD0000.jpg>
> --
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add
>
>
> --
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add
>