On Thu, Nov 21, 2019 at 3:10 AM Viktor Dukhovni <[email protected]> wrote:
> > On Nov 21, 2019, at 2:37 AM, Ben Schwartz <[email protected]> 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 protected] > https://www.ietf.org/mailman/listinfo/dnsop >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
