Subject: Re: [DNSOP] Consensus suggestion for EDE and the TC bit

From: Ben Schwartz <[email-masked]>
Date: Mon, 2 Dec 2019 12:27:23 -0500

On Thu, Nov 21, 2019 at 3:10 AM Viktor Dukhovni <[email-masked]>
wrote:

> > On Nov 21, 2019, at 2:37 AM, Ben Schwartz <[email-masked]> wrote:
> >
> > To be clear, we are talking only about the case where a response "fits"
> until the EDE is added, after which it exceeds the limit and is truncated.
> If optimizing this situation is important, I would suggest adding a
> requirement to the EDE draft that EDE be the last option in OPT.  Then as a
> client, I can easily detect this situation, because the truncation point is
> in the middle of the EDE option.  The client logic then is very simple: if
> I don't care about EDE, I can ignore the TC bit.
>
> Not sure what you mean by "in the middle of the EDE option", IIRC
> truncation IIRCin DNS is never "in the middle" of an element, we
> either send the whole element or don't send it.
>
> For the OPT RR, I think that means that it includes a set of
> complete options.
>

Thanks for the correction.  With that in mind, I agree that this trick
would not work.

>
> I do agree that truncation due to EDE should be rare, and therefore
> also TCP failover as a result of such truncation, so if the consensus
> is to keep it simple, so be it, but I don't see how how the client
> could figure out what was left out...
>
>
> --
>         Viktor.
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Eric Orth <[email-masked]>
Date: Mon, 2 Dec 2019 13:54:57 -0500

I still have a soft preference (but am definitely not going to call it a
hard blocker) for some way to avoid followup queries when the only thing
causing truncation is EDE.

My concern comes from the EXTRA-TEXT being an open-length field, and I
imagine many operators would want to create long verbose error messages.
Seems that could lead to many cases where EDE causes common excessive
truncation.

Maybe an alternate easy solution would be to add a don't-do-that note to
section 3.4 along the lines of "Long EXTRA-TEXT fields may cause truncation
and bad resolve performance, which is usually undesirable for the
supplemental nature of EDE. Operators setting the field SHOULD avoid
setting unnecessarily long contents, especially when it can be determined
that doing so will cause truncation." With something like that, I think my
concerns are enough resolved that I wouldn't worry about DP unless future
experience shows EDE truncation to be a significant problem.

But otherwise, if people don't like my suggested note, because I only have
a soft preference to do something, I agree that moving TC/DP to a separate
doc is a good idea.  If EDE is otherwise consensus-ready, let's get it
published.

On Thu, Nov 21, 2019 at 12:04 PM Ray Bellis <[email-masked]> wrote:

>
>
> On 21/11/2019 15:37, Ben Schwartz wrote:
>
> > I would suggest adding a requirement to the EDE draft that EDE be
> > the last option in OPT
>
> And what if some other future option wants to lay claim to that
> requirement?
>

 I agree that this would be a difficult requirement to set.  Only one thing
can be last, and I would argue that EDE is not important enough to claim
that distinction and take away the flexibility from future specs.

---

From: Michael StJohns <[email-masked]>
Date: Mon, 2 Dec 2019 14:15:58 -0500

On 11/21/2019 1:53 AM, Wes Hardaker wrote:
> During the first DNSOP meeting at IETF 106 there was a discussion that
> had multiple opinions about what to do with setting the TC bit for EDE
> information, which is generally supplemental.  During my presentation I
> mentioned that an associate of Viktor suggested creating a new bit, and
> during the conversation there was discrepancy about whether or not that
> was a good idea.  Brian Dickson then proposed that the new bit only
> modify future clients that wanted to use it, thus leaving the EDE spec
> setting the TC bit.  A future bit could be defined that would indicate
> that only supplemental information was dropped.
>
> My proposal for EDE is that we follow this train of thought, which seems
> to be the widest idea accepted from what I could tell.  TLDR for things
> to do:
>
> 1. We have the EDE document say to set the TC bit (which it already did)
> 2. We create a new document that defines an extra bit for indicating
>     that the dropped information was supplemental and didn't contain
>     operationally important information.
>
> If this sounds like a good compromise, great!  If you would like to
> propose an alternative, great!  do so!

 From 2181:

>   The TC bit should be set in responses only when an RRSet is required
>     as a part of the response, but could not be included in its entirety.
>     The TC bit should not be set merely because some extra information
>     could have been included, but there was insufficient room.

I finally got a chance to go back and do some reading and found the above.

The way I read this is that setting the bit simply because you couldn't 
include diagnostic info is a no-no.   Let's not do it.

I read "required" not as "the querier (person) requires it" but as "the 
protocol requires it".

So - 3rd (4th?) option.   Include a bit in querier EDNS(0) that says 
"set the TC bit if I dropped EDE" and maybe "return the EDE info that 
was dropped instead of or in preference to the query response data".

Later, Mike

>
> In the mean time, I threw together a quick ID for the new bit as well:
>
> https://datatracker.ietf.org/doc/draft-hardaker-dnsop-drop/
>

---

From: Puneet Sood <[email-masked]>
Date: Mon, 2 Dec 2019 23:12:34 -0500

My preference is also to not add the DP bit as part of the EDE
feature. We should gain more experience with EDE before adding any new
bits to the protocol.

On Mon, Dec 2, 2019 at 1:55 PM Eric Orth
<ericorth=[email-masked]> wrote:
>
> I still have a soft preference (but am definitely not going to call it a hard blocker) for some way to avoid followup queries when the only thing causing truncation is EDE.
>
> My concern comes from the EXTRA-TEXT being an open-length field, and I imagine many operators would want to create long verbose error messages.  Seems that could lead to many cases where EDE causes common excessive truncation.
>
> Maybe an alternate easy solution would be to add a don't-do-that note to section 3.4 along the lines of "Long EXTRA-TEXT fields may cause truncation and bad resolve performance, which is usually undesirable for the supplemental nature of EDE. Operators setting the field SHOULD avoid setting unnecessarily long contents, especially when it can be determined that doing so will cause truncation." With something like that, I think my concerns are enough resolved that I wouldn't worry about DP unless future experience shows EDE truncation to be a significant problem.

I would support text like the above in section 3.4 to remind operators
not to put very long text in the EXTRA-TEXT field.

>
> But otherwise, if people don't like my suggested note, because I only have a soft preference to do something, I agree that moving TC/DP to a separate doc is a good idea.  If EDE is otherwise consensus-ready, let's get it published.
>
>> And what if some other future option wants to lay claim to that requirement?
>
>
>  I agree that this would be a difficult requirement to set.  Only one thing can be last, and I would argue that EDE is not important enough to claim that distinction and take away the flexibility from future specs.

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 3 Dec 2019 11:41:43 +0100 (CET)

> Il 3 dicembre 2019 05:12 Puneet Sood <puneets=[email-masked]> ha scritto:
> 

Thinking at how that field could be used in practice for a use case that we have in mind, I think it would be structured and contain pointer(s?) to more detailed information, under the form of URL(s). As long as it can keep a couple of average-length URLs and some shorter things, I think it will be ok. Also, independently from whether I like this or not, I expect this type of advanced use cases to require DoH as a transport protocol - I don't see clients trusting this information if received from an unauthenticated resolver over a cleartext connection.

-- 
 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: "Ralf Weber" <[email-masked]>
Date: Wed, 04 Dec 2019 06:21:58 +0800

Moin!

On 3 Dec 2019, at 3:15, Michael StJohns wrote:
> The way I read this is that setting the bit simply because you 
> couldn't include diagnostic info is a no-no.   Let's not do it.
I disagree. The EDNS0 OPT RRSet is needed and thus if can not be fitted 
entirely a TC bit has to be set. Also 2181 was before EDNS0 so IMHO it 
doesn’t apply here anyway. EDE is all is new stuff we have to decide 
over what do with it now and not some ancient RFC. And a lot of people 
(including me) have said that they, because of the rare cases this 
appears, see TC as the right solution as it is simple and backwards 
compatible. EDE already is complex we should not increase it complexity 
for a rare corner case.

So long
-Ralf
—--
Ralf Weber

---

From: Paul Vixie <[email-masked]>
Date: Tue, 3 Dec 2019 18:33:12 -0800

> On 3 Dec 2019, at 3:15, Michael StJohns wrote:
...
> compatible. EDE already is complex we should not increase it complexity 

i think EDNS0 is no longer optional. if you can't speak it because of 
response truncation problems, you set TC=1.

so, i am +1 to ralf's text above.

-- 
P Vixie

---

From: Michael StJohns <[email-masked]>
Date: Wed, 4 Dec 2019 01:31:50 -0500

On 12/3/2019 5:21 PM, Ralf Weber wrote:
> I disagree. The EDNS0 OPT RRSet is needed and thus if can not be 
> fitted entirely a TC bit has to be set. Also 2181 was before EDNS0 so 
> IMHO it doesn’t apply here anyway. EDE is all is new stuff we have to 
> decide over what do with it now and not some ancient RFC. And a lot of 
> people (including me) have said that they, because of the rare cases 
> this appears, see TC as the right solution as it is simple and 
> backwards compatible. EDE already is complex we should not increase it 
> complexity for a rare corner case.

*bleah*

In the querying EDNS0 set a bit (EDERequested) that says "Consider EDE 
as 'important' in the response - return TC if there is an overflow and 
EDE is omitted".   Maybe set a second bit (EDERequired) that says "EDE 
is more important than any other data - return it at the head of the 
response and drop something else in preference."

Responder:

If EDERequested or EDERequired is set, and overflow occurs because of 
the EDE, set the TC bit on the response.

If EDERequired is set, return the EDE EDNS0 option in preference to any 
other data - you may still end up setting the TC bit if other info is 
omitted.

The first bit says that the client understands EDE and that it considers 
it is as important as any other data and should not be omitted without 
setting the TC bit.

Clients that don't understand EDE (e.g. most of them right now) that 
would ignore EDE anyways don't need to re-query for data that they don't 
understand.

Clients that do understand EDE leave both bits unset if they really 
don't care about the reasons why (e.g. the typical end user), can set 
the first bit if they do (typical resolver) and can set both bits for 
debugging (the geeks in the DNSOP group).

In the case of truncation due to EDE, omit the EDE option from the 
response EDNS0 RR.  If you're still overflowing, set the TC. (E.g. this 
isn't about omitting the EDNS0 in the response, only about removing 
bloat when the client hasn't indicated the bloat is useful.

Later, Mike