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.
>
>
>