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/
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
