> 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.
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
