John Kristoff <j...@dataplane.org> wrote: > > However, I think we'd be reluctant to say much about minimal-answers > here in a context that suggests it is some sort of DDoS mitigation > mechanism and that you need it because... "TCP". Maybe there is some > adjustments to the text somewhere that can help highlight that certain > RRsets or settings may lead to more TCP traffic?
There's this paragraph: Often, reducing the EDNS0 UDP packet size leads to a successful response. That is, the necessary data fits within the smaller message size. However, when the data does not fit, the server sets the truncated flag in its response, indicating the client should retry over TCP to receive the whole response. This is undesirable from the client's point of view because it adds more latency and potentially undesirable from the server's point of view due to the increased resource requirements of TCP. which is followed by discussion of various ways of reducing response sizes to avoid fragmentation and truncation. I thought that minimal-responses and minimal-any could also be mentioned as useful ways to avoid large responses. The anti-DDoS aspect of minimal-any isn't the main point in this context. > IETF RFC 2136 (UPDATE) is already referenced in our draft, section > 2.2. Is this insufficient? Oh yes, that's the kind of text I was expecting :-) I guess I had forgotten about it by the time I got to the appendix and thought it must have been missing because RFC 2136 isn't listed in the appendix. Tony. -- f.anthony.n.finch <d...@dotat.at> https://dotat.at/ Lundy: Northeast 4 to 6 becoming variable 4 or less. Smooth or slight, but moderate until later in west. Rain then showers. Good, occasionally moderate at first. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
