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

From: Tommy Jensen <[email-masked]>
Date: Tue, 23 Mar 2021 16:21:06 +0000

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>

Thanks,
Tommy

From: Benjamin M. Schwartz <[email-masked]>
Sent: Monday, March 22, 2021 6:46 PM
To: ietf-wg-add/draft-ietf-add-ddr <[email-masked]>
Cc: Tommy Jensen <[email-masked]>; Author <[email-masked]>
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>.

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 23 Mar 2021 09:39:32 -0700

> On Mar 23, 2021, at 9:21 AM, Tommy Jensen <Jensen.Thomas=[email-masked]> wrote:
> 
> 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 <[email-masked] <mailto:[email-masked]>> 
> To: ietf-wg-add/draft-ietf-add-ddr <[email-masked] <mailto:[email-masked]>>
> Cc: Tommy Jensen <[email-masked] <mailto:[email-masked]>>; Author <[email-masked] <mailto:[email-masked]>>
> —
> 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>.
> 
> -- 
> Add mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/add <https://www.ietf.org/mailman/listinfo/add>

---

From: Erik Kline <[email-masked]>
Date: Tue, 23 Mar 2021 17:16:34 -0700

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=
[email-masked]> wrote:

>
>
> On Mar 23, 2021, at 9:21 AM, Tommy Jensen <
> Jensen.Thomas=[email-masked]> wrote:
>
> 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 <[email-masked]>
> *Sent:* Monday, March 22, 2021 6:46 PM
> *To:* ietf-wg-add/draft-ietf-add-ddr <
> [email-masked]>
> *Cc:* Tommy Jensen <[email-masked]>; Author <
> [email-masked]>
> *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.
>
> —
> 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>
> .
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>
>
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 23 Mar 2021 22:25:24 -0400

Erik,

That's interesting and relevant to a different conversation about SVCB, but
I don't think it matters here.  In the case of this PR, the name being
resolved is the Special Use Domain Name "_dns.resolver.arpa", i.e. there is
no authoritative server, and the answer is being synthesized locally by the
recursive resolver.  ECS is therefore irrelevant.

Things get slightly more interesting in the case of "Discovery Using
Resolver Names" (Section 5), but in that case the usual guidance from SVCB
applies: if you set TargetName to the base name (i.e. $RESOLVER_NAME), the
client will query the relevant A and AAAA records in parallel, so there's
no reliance on Additional sections.