Skip to main content

Last Call Review of draft-ietf-dnsop-5966bis-04

Request Review of draft-ietf-dnsop-5966bis
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-12-07
Requested 2015-11-29
Authors John Dickinson , Sara Dickinson , Ray Bellis , Allison Mankin , Duane Wessels
I-D last updated 2015-12-04
Completed reviews Genart Last Call review of -04 by Brian E. Carpenter (diff)
Genart Telechat review of -05 by Brian E. Carpenter (diff)
Opsdir Last Call review of -04 by Rick Casarez (diff)
Assignment Reviewer Rick Casarez
State Completed
Request Last Call review on draft-ietf-dnsop-5966bis by Ops Directorate Assigned
Reviewed revision 04 (document currently at 06)
Result Has nits
Completed 2015-12-04
Hello everyone,

I have reviewed draft-ietf-dnsop-5966bis-04 as part of the Operations
Directorate's ongoing effort to review all IETF documents being processed by
the IESG.  These comments were written primarily for the benefit of the
operation area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

Summary: I believe the document is 'Ready with Nits'.


Introduction, 1st paragraph, last sentence:

"It is now widely used in Response Rate Limiting [RRL]."

I looked and could not find any RFC or draft related to Response Rate Limiting
and TCP. Is there any reference that can be placed in the document to help
explain that sentence or allow one to go off and read into it? I did a Google
search and found RRL references but not all implementations use TCP. So
something needs to be added or the line removed I think.

Section 6.1, 1st paragraph after bullets:

There is a reference to HTTP/1.1 but why not reference HTTP/2.0 (RFC 7540) as
well (Or in place of)?

Section 6.2.1, 2nd paragraph:

"When sending multiple queries over a TCP connection clients MUST take care to
avoid Message ID collisions.  In other words, they MUST NOT re-use the DNS
Message ID of an in-flight query on the same TCP connection."

Are both sentences needed? It seems like they are repeating the same thing
using a different perspective. Something cleaner would seem to be in order:

"When sending multiple queries over a TCP connection clients MUST NOT
re-use the DNS Message ID of an in-flight query in order to avoid Message ID

Section, 4th paragraph:

I am a little bit confused about the third sentence here. I understand the two
previous sentences and their 'SHOULD's. This third sentence though reads like
you are saying a DNS server 'SHOULD process all queries' when it should be
'MUST process all queries'. I cannot imagine a scenario where we would want a
DNS Server to not process all queries even if they come in fast over a pipeline
but maybe I am misinterpreting.

Section 6.2.3, 3rd paragraph:

"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
any part of a DNS message."

I interpret the first part of this section as saying a server SHOULD NOT reset
its idle timeout timer until it gets the full message. The last sentence does
not seem to match that interpretation though and just mentioned idle timeout
should only be applied on full message but nothing about resetting the timer. I
also think a small editing change from 'to' to 'on' reads better. All proposed
changed in italics below:

"For this reason, servers SHOULD


 the idle timeout


the receipt of
 a full DNS message, rather than


receipt of any part of a DNS

If "apply" means "resetting" please let me know. :)

Section 6.2.4:

Throughout the whole document you use 'DNS Server' and 'DNS Client'. For
continuity I think this section needs an edit for this.

Section 8, 2nd paragraph:

Second paragraph is not clear to me. It discusses aborting connections due to a
TCP Segment missing some information. Not sure I would confuse it with a
reference to a section on idle timeout resets (or timer resets in general). The
only relevant part of 6.2.3 would be about not taking any action until all
segments are received. I am not sure why timeouts are referenced.


Cheers, Rick

Experiences not things.