On Thu, 22 Apr 2021 20:23:19 +0100 Tony Finch <[email protected]> wrote: > I needed minimal-any when my auth servers were being hammered by lots of > recursive servers making ANY requests; the responses were being truncated > because my servers have for a long time been configured to avoid > fragmentation, and the retries over TCP caused an overload.
Hi Tony, Minimal answers I think is an interesting and in a more general context I'm interested in exploring it as an operational practice (e.g. I think it can help relieve some of the burden and problems of parent/child inconsistency). 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? Thanks for taking on a bulk of replies so far. I tend to like to digest them first, before replying to them in rapid succession so you're beating me to it. I can do some of the follow up work in the repo where I find things that are not yet addressed. > > > Should RFC 2136 UPDATE be mentioned? (sections 2.1, 6.2, 7.8, 7.9) TBH I'm > > > not sure how much UDP is used, but I certainly rely on 60+ KB updates. > > > > I probably don't have enough direct experience with UPDATE to say. If > > it is largely over TCP then I think it should be included. > > I listed the main section numbers that mention TCP. One point in RFC 2136 > that's notable from an operational point of view is that an UPDATE client > has to use TCP if it wants to be sure to get a response. Unlike QUERY, > UPDATE is not idempotent so UPDATE-over-UDP can't be retried when there is > packet loss. (But `nsupdate` still uses UDP for small changes; I run it > over localhost which is reliable enough.) IETF RFC 2136 (UPDATE) is already referenced in our draft, section 2.2. Is this insufficient? John _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
