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

[Peter van Dijk <[e-mail]>]

On Thu, 2019-11-21 at 15:37 +0800, Ben Schwartz wrote:
> I think we are talking about performance in a situation that (a) is so pathological that it will almost never happen and (b) at worst, will only slow down failure, not success.  For that reason, I would avoid introducing any additional protocol complexity in pursuit of optimization.  I think our simplest and most appealing option would be to treat EDE exactly like any existing EDNS Option (i.e. set the TC bit).
> 
> 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.

Please do not write specifications that require software to receive a corrupt packet (in this case, one where the RDLEN of the last record extends beyond the end of the packet) and draw any conclusion from it other than 'this is a corrupt packet'. Also, please do not truncate packets on arbitrary byte boundaries.

In other words, please always send well-formed packets that contain what they say they contain in terms of Answer/Additional/Auth counts, and the sizes of those individual records.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/