Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-chain-query
Bob Harold <rharolde@umich.edu> Tue, 02 June 2015 20:06 UTC
Return-Path: <rharolde@umich.edu>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 049521ACEDE for <dnsop@ietfa.amsl.com>; Tue, 2 Jun 2015 13:06:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpmlb4ZNKlEm for <dnsop@ietfa.amsl.com>; Tue, 2 Jun 2015 13:06:25 -0700 (PDT)
Received: from mail-yk0-f182.google.com (mail-yk0-f182.google.com [209.85.160.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 275371ACEDA for <dnsop@ietf.org>; Tue, 2 Jun 2015 13:06:24 -0700 (PDT)
Received: by yked142 with SMTP id d142so57162217yke.3 for <dnsop@ietf.org>; Tue, 02 Jun 2015 13:06:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=inFVxOeBVlHQT28nFBttNTGj3Dej1/+1Kkbx+lanqLo=; b=NNPHxELHTOCG1vJ9ZCYJZboGkRiKSRhRnu8epyavIDNpjGAUPTIBhzMYpCqYq5nnJB WWnLtsR2PGX90HsUyv5Z1th/105c6n5/FS8dluszXOEYvsDiLtxej+rC2/TBhivgY5ex ePp/D4GZ6caTPFdSonGka2FLkERtFL5kU0+PJXoKiqBSzq1uFxnn3aDcDrQlzAdkbBkO aPiEL6x3ikvcnMmXWt0WLcqEksTuReE93lps15dgLRV/W1LsC+SkzjMySruLJ5axk7hT 61oKeAPATaQkdbzyyV3LNnDSWbkbDiQiz+oLQ19eUskqWqvzYxN1NxGx1N0f5yIRSHeG ruWw==
X-Gm-Message-State: ALoCoQkHmTA70fCMpWCgRE1ETsw6q6DDAgJLhuW08vWKovrKNut2ZVtmom7EL1wrBGe/IwespDeO
MIME-Version: 1.0
X-Received: by 10.170.130.15 with SMTP id w15mr23833273ykb.8.1433275584045; Tue, 02 Jun 2015 13:06:24 -0700 (PDT)
Received: by 10.129.76.144 with HTTP; Tue, 2 Jun 2015 13:06:23 -0700 (PDT)
Date: Tue, 02 Jun 2015 16:06:23 -0400
Message-ID: <CA+nkc8BwQqv0T2ox0nYq+GbYN9hK0ztKydYo7ufOC90ij_JQug@mail.gmail.com>
From: Bob Harold <rharolde@umich.edu>
To: Tim Wicinski <tjw.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="001a113958520d7a3e05178e7afd"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/kd3NHZCumehUGxRBp_1XOKD6Iro>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-chain-query
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jun 2015 20:06:28 -0000
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 On Tue, Jun 2, 2015 at 2:28 PM, Tim Wicinski <tjw.ietf@gmail.com> wrote: > 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. > > >
- Re: [DNSOP] Working Group Last Call for draft-iet… Tony Finch
- Re: [DNSOP] Working Group Last Call for draft-iet… Tony Finch
- [DNSOP] Working Group Last Call for draft-ietf-dn… Tim Wicinski
- Re: [DNSOP] Working Group Last Call for draft-iet… Bob Harold
- [DNSOP] Working Group Last Call for draft-ietf-dn… Tim Wicinski
- Re: [DNSOP] Working Group Last Call for draft-iet… Joe Abley
- Re: [DNSOP] Working Group Last Call for draft-iet… Tony Finch
- Re: [DNSOP] Working Group Last Call for draft-iet… Shumon Huque
- Re: [DNSOP] Working Group Last Call for draft-iet… Paul Hoffman
- Re: [DNSOP] Working Group Last Call for draft-iet… Tony Finch
- Re: [DNSOP] Working Group Last Call for draft-iet… Paul Hoffman
- Re: [DNSOP] Working Group Last Call for draft-iet… Evan Hunt
- Re: [DNSOP] Working Group Last Call for draft-iet… Ólafur Guðmundsson
- Re: [DNSOP] Working Group Last Call for draft-iet… Tim Wicinski
- Re: [DNSOP] Working Group Last Call for draft-iet… Viktor Dukhovni
- Re: [DNSOP] Working Group Last Call for draft-iet… Tony Finch
- Re: [DNSOP] Working Group Last Call for draft-iet… Tony Finch
- Re: [DNSOP] Working Group Last Call for draft-iet… Paul Vixie
- Re: [DNSOP] Working Group Last Call for draft-iet… Tony Finch
- Re: [DNSOP] Working Group Last Call for draft-iet… Paul Vixie
- Re: [DNSOP] Working Group Last Call for draft-iet… Tony Finch
- Re: [DNSOP] Working Group Last Call for draft-iet… Paul Vixie
- Re: [DNSOP] Working Group Last Call for draft-iet… Tony Finch
- Re: [DNSOP] Working Group Last Call for draft-iet… Paul Vixie
- Re: [DNSOP] Working Group Last Call for draft-iet… Wiley, Glen
- Re: [DNSOP] Working Group Last Call for draft-iet… Paul Wouters
- Re: [DNSOP] Working Group Last Call for draft-iet… Tim Wicinski