> Begin forwarded message: > > From: 神明達哉 <jin...@wide.ad.jp> > Subject: Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-5966bis > Date: 15 October 2015 01:52:09 BST > To: Sara Dickinson <s...@sinodun.com> > Cc: Joe Abley <jab...@hopcount.ca>, dnsop <dnsop@ietf.org> > > At Wed, 14 Oct 2015 13:20:39 +0100, > Sara Dickinson <s...@sinodun.com> wrote: > > > 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.@@ -477,6 +477,12 @@
Point taken! How about the following: @@ -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. As + a result a DNS server that resets its idle timeout after each “read” system call + 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 any part of a DNS message. + @@ -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 idle timeouts to the + receipt of a full message and MUST NOT close a connection simply + because the first “read” system call for a new message does + not contain the entire message. Sara.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
