Re: [DNSOP] Martin Duke's Discuss on draft-ietf-dnsop-avoid-fragmentation-16: (with DISCUSS and COMMENT)

[Martin Duke <[e-mail]>]

Thanks Paul, this PR (and your responses) would resolve my DISCUSS.

On Mon, Feb 5, 2024 at 8:16 AM Paul Wouters <[e-mail]> wrote:

> I don't think I saw any response to this from the authors or dnsop, so let
> me reply to your DISCUSS points (as individual DNS enthousaist only):
>
> On Tue, Jan 2, 2024 at 2:44 PM Martin Duke via Datatracker <
> [e-mail]> wrote:
>
>> Martin Duke has entered the following ballot position for
>> draft-ietf-dnsop-avoid-fragmentation-16: Discuss
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> 1) I'm unclear about Sec 4, R11 and Appendix B. When configured for
>> minimal
>> response, are responses to ALL requesters reduced in size, or only to
>> those
>> requesters that indicate a small MTU?
>>
>
> Responses to all clients are reduced, but only for "gratuitous" NS record
> from the authority section.
> When queried with qtype=NS, it would still give the full response of
> NS/A/AAAA records (and set TC if it did not fit). Although details might
> vary per implementation, as there is no RFC definition of a minimal
> response. So I think the actual change on the wire is pretty negligible.
>
> On top of that, there are proposals that could/would mitigate this by
> explicitly signaling a query to ask for multiple qtypes at once, if this
> would become a problem, eg
> https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-multi-qtypes-00
>
> As DNS becomes a more important vehicle for various discovery protocols
>> (e.g.
>> ECH), I would hate for responders to globally invoke a policy that makes
>> it
>> hard to deploy those protocols. But I'm happy to discuss this.
>>
>
> Note that a lot of those connections would be using DoT or DoH for privacy
> reasons, and at that point minimal responses does not affect things because
> those are meant mostly for UDP only.
>
>
>> 2) In section 3.2, R8, please add RFC 8961 as a normative reference for
>> how to
>> set the timeout (e.g. "UDP requestors MUST observe [RFC8961] in setting
>> their
>> timeout.")
>>
>
> A PR proposed for inclusion in the next draft added that reference:
> https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-avoid-fragmentation/pull/40
>
> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> Thanks to Mirja Kuhlewind for the TSVART review, and to the authors for
>> responding.
>>
>> (1) I support Rob's DISCUSS (and Paul's comment) about SHOULD/MAY. "do it
>> unless the OS makes it impossible" is a typical use of SHOULD.
>>
>
> See same PR :)
>
>
>>
>> (2) Section 3.1, R1 says that responders SHOULD omit the fragment header.
>> Under
>> what circumstances would it be reasonable to keep it?
>>
>
> I'll update the PR as Eric also commented on that line. The fragment
> header should not be there ever because there should not be fragmentation.
>
> Paul
>
>