Wessels, Duane <dwess...@verisign.com> wrote: > Thanks for looking through my suggestions! All the changes look good. A few follow-up points:
> Oops, correcting myself here. It needs to be RFC 2541 because that is the > one that mentions TCP. Aha, that makes sense > > 2.4: > > > > Last 2 paragraph s re. avoiding fragmentation, it might be worth > > suggesting minimal-any [RFC 8482]. > > I did add 8482 to the Appendix as you also suggested below. I'm a > little reluctant to add a reference in section 2.4 since I think the > primary motivation for 8482 was about DDoS amplification, rather than > fragmentation. But I could still be convinced otherwise. 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. I tend to think of all settings that reduce response size as tools for avoiding fragmentation. Which makes me realise that BIND's minimal-responses setting is probably also worth a mention. (I dunno if other servers have a similar knob?) > > A: > > > > 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.) Tony. -- f.anthony.n.finch <d...@dotat.at> https://dotat.at/ East Forties: Northwesterly 3 to 5. Moderate. Showers. Good. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
