Hi, thanks for the detailed response. I have a few comments below, and I've trimmed everything from this reply where I agree with the resolution you proposed in your response.
On 2021-11-30, at 1:53, Wessels, Duane <dwess...@verisign.com> wrote: >> Section 4.2. , paragraph 3, discuss: >>> Since host memory for TCP state is a finite resource, DNS clients and >>> servers MUST actively manage their connections. Applications that do >>> not actively manage their connections can encounter resource >>> exhaustion leading to denial of service. For DNS, as in other >>> protocols, there is a tradeoff between keeping connections open for >>> potential future use and the need to free up resources for new >>> connections that will arrive. >> >> For it to contain a MUST-level requirement, this section needs to give a lot >> more concrete guidance on what it means to "actively" manage connections. >> Most >> operating systems by default impose some application limits that usually >> effectively prevent DOS or other resource exhaustion issues. Is the intent >> here >> that DNS implementations need to do more? If so, what? > > I can easily be convinced that SHOULD is more appropriate than MUST here. I think that would be better, esp. for clients and because the "actively manage" term is still unclear to me - it seems to mean "must implement (some of) the limits below"? > I dont necessarily agree that operating systems alone do a very good job > of preventing DOS conditions. It is possible that Im not up-to-date on > the latest and greatest in terms of operating system features, but I think > historically applications have fared better when they manage their own > connections. For example, can we realistically expect the OS to know which > idle connections should be closed? The OS will certainly try to close sufficient connections under DDoS to remain operational. But if an application wants to see connections closed according to a certain policy - and DNS servers probably would - they need to actively engage. Maybe that's the rationale here? (Also, Linux and other major OSs these days handle very large numbers of TCP connections just fine, I think I recall seeing numbers up to a million for Linux (assuming sufficiently beefy hardware). And deployments that needs to handle such connection counts would normally load-balance into a server cluster anyway. So I remain a bit unconvinced that the limits described in this doc are all that important. But that's just a comment and I'm certainly not going to block the document over this.) >> Section 3. , paragraph 1, comment: >>> 3. DNS over TCP Requirements >> >> While the history preceding this section is interesting for context, I think >> moving this section up would increase readability significantly. > > Okay with me. I would like to hear from the Chairs. I'm OK with whatever resolution they prefer. >> Section 4.2. , paragraph 3, comment: >>> DNS server software MAY provide a configurable limit on the number of >>> established connections per source IP address or subnet. This can be >>> used to ensure that a single or small set of users cannot consume all >>> TCP resources and deny service to other users. Operators SHOULD >>> ensure this limit is configured appropriately, based on their number >>> and diversity of users. >> >> This limit only begins to establish fairness once the overall number of >> permitted connections is reached. Until that point, it possibly limits client >> performance without any benefit. > > I suppose this depends on how it is implemented and there are lessons to be > learned from the world of IP QOS. > > I surveyed open source DNS server code and their developers and found that > only > one implements this limit and ships with no limit by default. > > Perhaps this current (updated) paragraph is better: > > DNS server software MAY provide a configurable limit on the number of > established connections per source IP address or subnet. This can be > used to ensure that a single or small set of users cannot consume all > TCP resources and deny service to other users. Note, however, that > if this limit is enabled, it possibly limits client performance while > leaving some TCP resources unutilized. Operators SHOULD be aware of > these tradeoffs and ensure this limit, if configured, is set > appropriately based on the number and diversity of their users, and > whether users connect from unique IP addresses or through a shared > Network Address Translator [RFC3022]. > >> Section 4.2. , paragraph 3, comment: >>> DNS server software SHOULD provide a configurable timeout for idle >>> TCP connections. For very busy name servers this might be set to a >>> low value, such as a few seconds. For less busy servers it might be >>> set to a higher value, such as tens of seconds. >> >> Ditto. > > In this case all of the open source implementations I surveyed have this > limit enabled by default. It might be useful to add a brief note similar to the one above here as well. Thanks, Lars
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
