At Wed, 14 Oct 2015 13:20:39 +0100, Sara Dickinson <[email protected]> wrote:
> > Section 8: is there benefit perhaps in including a matching SHOULD for the > > desired server behaviour? The paragraph notes that servers may respond in > > an unhelpful way if the message length and the message itself don't arrive > > in the same segment, but doesn't specify in a normative way what we think > > of that. Perhaps they SHOULD NOT do that? > > > That seems reasonable. Would the following additions (which go a little > further) clarify this point enough? > > Section 6.2.3 Idle Timeouts > > @@ -477,6 +477,12 @@ > specified in [RFC1035]. Servers MAY use zero timeouts when > experiencing heavy load or are under attack. > > + DNS messages delivered over TCP might arrive in multiple segments. A > + DNS server that resets its idle timeout after receiving a single > + segment might be vulnerable to a "slow read attack." For this > + reason, servers SHOULD apply the idle timeout to the receipt of a > + full DNS message, rather than to receipt of a TCP segment. > + > > @@ -542,7 +549,18 @@ > problems due to some DNS servers being very sensitive to timeout > conditions on receiving messages (they might abort a TCP session if > the first TCP segment does not contain both the length field and the > - entire message) > + entire message). Such behavior is certainly undesirable. As > + described in [6.2.3], servers SHOULD apply connection timeouts to the > + receipt of a full message and MUST NOT close a connection simply > + because the first segment does not contain the entire message. I think the additional text for these sections has the same problem I pointed out before for the sending side of Section 8: a DNS server implementation usually cannot know which TCP segment contains what amount of data. All it can know in practice is which amount of data a single "read" API call returns. I suggest you rephrasing the text as we did for the sending side of Section 8. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
