Lars Eggert has entered the following ballot position for draft-ietf-dnsop-dns-tcp-requirements-13: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 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? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 2.4. , paragraph 1, comment: > 2.4. Fragmentation and Truncation Fragmentation and IP fragments getting dropped is one reason for needing more retries with EDNS(0). But IIRC, a larger contributing factor is that EDNS(0) doesn't detect or recover from loss of any UDP packets making up the overall message. That means that a normal packet loss (due to congestion or other reasons) amplifies into loss of the entire DNS message. 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. Section 4.2. , paragraph 3, comment: > DNS server software SHOULD provide a configurable limit on the total > number of established TCP connections. If the limit is reached, the > application is expected to either close existing (idle) connections > or refuse new connections. Operators SHOULD ensure the limit is > configured appropriately for their particular situation. Again, the OS generally already imposes limits. Why recommend that DNS implementations self-impose other (lower?) limits? 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. 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. Section 4.2. , paragraph 3, comment: > DNS server software MAY provide a configurable limit on the number of > transactions per TCP connection. What does that limit protect against? Section 4.2. , paragraph 2, comment: > Similarly, DNS server software MAY provide a configurable limit on > the total duration of a TCP connection. What does that limit protect against? Section 4.5. , paragraph 3, comment: > Most open source DNS server implementations provide a configurable > limit on the total number of established connections. Default values > range from 20 to 150. In most cases, where the majority of queries > take place over UDP, 150 is a reasonable limit. For services or > environments where most queries take place over TCP or TLS, 5000 is a > more appropriate limit. 20-150 is orders of magnitude less than I expected. Even 5000 seems very low, given the capabilities of even low-end servers. Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Term "master"; alternatives might be "active", "central", "initiator", "leader", "main", "orchestrator", "parent", "primary", "server". * Term "slave"; alternatives might be "follower", "peripheral", "replica", "responder", "secondary", "standby", "worker". ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. "Abstract", paragraph 2, nit: > document also considers the consequences with this form of DNS communicatio > ^^^^^^^^^^^^^^^^^ The usual preposition to use after "consequences" is not "with". Did you mean "consequences of", "consequences for", or "consequences on"? Section 2.4. , paragraph 7, nit: > ctions occur without interference. However there has also been a long-held be > ^^^^^^^ A comma may be missing after the conjunctive/linking adverb "However". Section 5. , paragraph 4, nit: > e no reported problems during the two month period when the old key was publi > ^^^^^^^^^ When a number forms part of an adjectival compound, use a hyphen. Section 11.2. , paragraph 54, nit: > s explain why DNS over TCP may often have been treated very differently than > ^^^^^^^^^^^^^^^ The adverb "often" is usually put between "have" and "been". Section 11.2. , paragraph 60, nit: > teworthy, perhaps less common today then when this document was written, it > ^^^^ Did you mean "than"? Reference [RFC2671] to RFC2671, which was obsoleted by RFC6891 (this may be on purpose). Document references draft-ietf-dnsop-avoid-fragmentation-04, but -05 is the latest available revision. Reference [RFC5966] to RFC5966, which was obsoleted by RFC7766 (this may be on purpose). Reference [RFC0883] to RFC883, which was obsoleted by RFC1034 and RFC1035 (this may be on purpose). Reference [RFC2541] to RFC2541, which was obsoleted by RFC4641 (this may be on purpose). These URLs in the document can probably be converted to HTTPS: * http://verisign.com _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
