Subject: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-chain-query

From: Tim Wicinski <[email-masked]>
Date: Tue, 02 Jun 2015 11:28:55 -0700

The chairs feel that the Author has addressed all the comments that have 
been brought up on the mailing list and updated this draft to reflect 
this.  We are ready to move forward with a Working Group Last Call.

At this time, this starts a Working Group Last Call for
	draft-ietf-dnsop-edns-chain-query

Current versions of the draft is available here:

https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-chain-query/
https://www.ietf.org/id/draft-ietf-dnsop-edns-chain-query-02.txt

Please review the draft and offer relevant comments. Also, if someone 
feels the document is *not* ready for publication, please speak out with 
your reasons.

This starts a two week Working Group Last Call process, and ends on 17 
June, 2015.

thanks,
tim

---

From: Bob Harold <[email-masked]>
Date: Tue, 2 Jun 2015 16:06:23 -0400

A few minor notes on draft-ietf-dnsop-edns-chain-query-02
My apologies for not seeing these earlier.
Or perhaps I am not understanding this correctly.

pg 6
sec 5.2
"Depending on the size of the labels of the last known entry point
   value, a DNS Query packet could be arbitrarily large.  If using the
   last known entry point would result in a query size of more then 512
   bytes, the last known entry point should be replaced with its parent
   entry until the query size would be 512 bytes or less.  A separate
   query should be send for the remainder of the validation chain."

-- Replacing the last know entry point with a shorter parent entry would
require more than the minimum validation chain to be sent, so there would
never be any 'remainder' to be requested later, if I understand this right.
  For example, if f.e.d.c.b.a was too long, and only c.b.a was sent as the
last known, then the answer would include the validation for f, e, and d,
which the requestor had already known.  So the line "A separate query
should be send for the remainder of the validation chain." should be
deleted.

pg 6
sec 5.4
"Requests resulting in chains that the receiving resolver is unwilling
   to serve can be rejected by sending a REFUSED response to the sender,
   as described by [RFC6891].  This refusal can be used for chains that
   would be too big or chains that would reveal too much information
   considered private."

-- How could it be private, when the fallback will be for the client to ask
for each part of the chain individually anyway?  If too big, it would seem
better to just omitting the edns-chain-query option in its reply as
explained in the next paragraph, rather than an error.

pg 10
sec 8.1
"A Recursive Resolver MUST NOT return Query Chain answers to clients
   over UDP without source IP address verification.  An example of UDP
   based source IP address verification is [DNS-COOKIES].  A Recursive
   Resolver refusing a Query Chain request MUST ignore the ends-query-
   chain option and answering the DNS request as if it was received
   without the ends-query-chain option.  It MUST NOT send an RCODE of
   REFUSED."

-- 'ends-query-chain' should be 'edns-query-chain', twice in this paragraph.

pg 11
-- 'ommited' -> 'omitted' (3 places - pages 11, 13, 13)

-- 
Bob Harold