Re: [DNSOP] Second Working Group Last Call - draft-ietf-dnsop-nsec-aggressiveuse
神明達哉 <jinmei@wide.ad.jp> Wed, 21 December 2016 19:34 UTC
Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C3F12956E for <dnsop@ietfa.amsl.com>; Wed, 21 Dec 2016 11:34:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 CkHA5goTg-zB for <dnsop@ietfa.amsl.com>; Wed, 21 Dec 2016 11:34:54 -0800 (PST)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 DDDCB12947D for <dnsop@ietf.org>; Wed, 21 Dec 2016 11:34:53 -0800 (PST)
Received: by mail-qk0-x232.google.com with SMTP id n21so86866877qka.3 for <dnsop@ietf.org>; Wed, 21 Dec 2016 11:34:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=306qncbC+6EIFj5sxCXYzRMeTHUdeWS1cN4RPatP92o=; b=N32IA+WYTelHWbTm3Ncyg2m5Xv7+dtEqsj2qpwuCP4/B+fNExngBx7SGebokxtjwB1 sGPnZ56zpN3lzzJX4rYH2+PxugPR/Nc97KRSSwYk16dn50wfq0sqn+hiCpHw7PZeT1FY AHfpLPCJTcd4ZYGZIVwjg5VTIfTpu/IRre2Hnno6rKCGyrRzVaP93orgb4SqsT7bMLGH oBmlcXVu8dZqfdrfZ4u4lHy4nuPf5v5mbo96G+cpwIUDhXCDADDoce8Ef69nWpxyfbcW O2a1NAKOZa7Poke6Ednf5L54LyybHzX1pU1xMDRVBBaYswHvI0vQaun5ooT46fw6uVVn DYvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=306qncbC+6EIFj5sxCXYzRMeTHUdeWS1cN4RPatP92o=; b=kNyGDgO1z62Tke+J5LL8E1ChxDpbtnmPMLOsIm4qvjAf6gLwenxb3ZRukc7F0CckQd WbmKkKakdrdpbjUtrDbgVDLYbjHZTRaZfaWS6MZ9HZYvMEAVAE9PMbXZBp1NsoGps1bz jRB35HoLaB/42D2bRAdj39lk9DV7UjIye3wYM6Gmqf7dg5/NxAoELnkAlcNzc9obIDRm gAQeLSlUL6ZfotPbKCzbdDJqoUALxshqiOixYmoSlLyUH+FX0EJngZ0/rVzT4AiEKKGm lAtTM5rLvBYMpAgTRFVL6+mxfvnwcppySnGQlsISZlgQlfzAuc/QFj+D3Nd5Ou5d6hjs wA8Q==
X-Gm-Message-State: AIkVDXIuzgfTboEFYkrFK9lR7E+gD4HSqjfdZ4sXGMqWjPAR6p5f5aqO/qs+J0rJU7uZi9AIKwWo4iGNT72R/A==
X-Received: by 10.55.64.69 with SMTP id n66mr6484293qka.20.1482348892915; Wed, 21 Dec 2016 11:34:52 -0800 (PST)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.200.51.154 with HTTP; Wed, 21 Dec 2016 11:34:52 -0800 (PST)
In-Reply-To: <CADyWQ+EJ0LO=pU-yUdEHwC3aP5KdXxsnD9kEvmmTeAoe0BxK3A@mail.gmail.com>
References: <CADyWQ+EJ0LO=pU-yUdEHwC3aP5KdXxsnD9kEvmmTeAoe0BxK3A@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
Date: Wed, 21 Dec 2016 11:34:52 -0800
X-Google-Sender-Auth: e9AyQzPSkF2C1ec45yLtCGH1zjQ
Message-ID: <CAJE_bqeVEsPA8ySOGQFB_Q99hyvtzy_1dey7ddwDv+zvdT779Q@mail.gmail.com>
To: tjw ietf <tjw.ietf@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/lCEW5hef9zmMjKSX4J-KlM3mStY>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Second Working Group Last Call - draft-ietf-dnsop-nsec-aggressiveuse
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 21 Dec 2016 19:34:56 -0000
At Tue, 13 Dec 2016 14:13:27 -0500, tjw ietf <tjw.ietf@gmail.com> wrote: > We felt another formal Working Group Last call was needed, though hopefully > shorter. > > This starts a Working Group Last Call for: > "Aggressive use of NSEC/NSEC3" > draft-ietf-dnsop-nsec-aggressiveuse > > Current versions of the draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/ [...] > 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 *one* week Working Group Last Call process, and ends at > midnight 20 December 2016 UTC. A bit belated, but I've read the 07 version. I'm not necessarily opposed to advancing it, but I personally it's better to spend some more time to bake it. The main reason is because the latest change to describe the aggressive use of deduced wildcards with an equal weight is quite substantial while I suspect many of the reviewers now only gave a quick sanity check to confirm whether specific technical details are addressed. On a relatively fresh read after some period, I found the 07 version somewhat awkward in some places due to the latest change (specific comments follow). Similarly, it's not clear to me whether it now includes the idea of aggressive use of NSEC/NSEC3 for returning NOERROR/NODATA? I see a new sentence in Section 4: Proof that a type does not exist is accomplished by providing a (DNSSEC secured) record containing the queried for name, and a type bitmap which does not include the requested type. but, overall, it still seems to only assume the NXDOMAIN type of negatives (see, e.g, a comment on Section 6 below). If the intent is to also support NOERROR/NODATA, I think we need another round of overall updates (mostly an editorial effort, but not trivial). Another reason for the wish of having some more discussion is that I think the described justification for changing the recommendation in RFC4035 is still weak (although I don't disagree with the change itself). Section 4 states: We believe this recommendation can be relaxed because, in the absence of this technique, a lookup for the exact name could have come in during this interval, and so a negative answer could already be cached (see [RFC2308] for more background). But this argument has always been the case including when RFC4035 was written. As RFC4035 still made this recommendation... In theory, a resolver could use wildcards or NSEC RRs to generate positive and negative responses (respectively) until the TTL or signatures on the records in question expire. However, it seems prudent for resolvers to avoid blocking new authoritative data or synthesizing new data on their own. Resolvers that follow this recommendation will have a more consistent view of the namespace. ...I'd logically expect some new argument that was not true or not recognized at the time of RFC4035 if we wanted to revise the recommendation. Examples of such a new argument include: - some statistics that shows "a lookup for the exact name comes in during this interval" more often than previously expected, so it turns out the old recommendation really doesn't help much. - the benefits of the aggressive use of NSEC(3)/deduced wildcards are now considered so big that they outweigh the prudence recommended in RFC4035. I'd like to see something like these with convincing facts or rationale in Section 4. Specific comments: - Title: "Aggressive use of NSEC/NSEC3" I think this should now be e.g., "Aggressive use of DNSSEC-validated cache" because of the equal weight given to the aggressive use of deduced wildcards. Even if the aggressive use of NSEC/NSEC3 can be used as part of steps to use a deduced wildcard aggressively (i.e., to confirm the query name wouldn't exist without the wildcard), the aggressive use of deduced wildcard has its own "aggressiveness" with its own caveats. For example, in addition to the case where the wildcard-matched name is added to the zone, we also take the risk of not returning a negative answer sooner when the wildcard is removed. So I think this document should now use both NSEC/NSEC3 (for negative) and wildcard (for positive) equally when it says "aggressive use of XXX". The above example suggestion is one attempt to do this. And, if this suggestion makes sense, it should apply throughout the document (this is one reason why it's better to spend some more time before shipping it). - Section 4 queried for name. In the first example above, if the (DNSSEC validating) recursive server were to query for dog.example.com it In this context I don't see why this has to be a recursive server. I also found some other occurrences of "recursive" when it doesn't necessarily have to be a recursive in that context. It would be nice to clean up the terminology issue, but maybe it's too minor and/or too subtle. Since they are now only in examples, the additional clarity may not be worth the additional editorial effort. - Section 6 Reduced latency: By answering directly from cache, validating resolvers can immediately inform clients that the name they are looking for does not exist, improving the user experience. This only seems to assume the NXDOMAIN type of negative response. It's not necessarily incorrect as it just shows an example benefit, but, overall, text like this makes me wonder whether this doc also intends to cover the NOERROR/NODATA type of negative. - Section 11 Thanks to Mark Andrews for providing the helpful notes for implementors provided in Appendix B. ... [...]. Mark Andrews also provided the helpful notes for implementors (https://www.ietf.org/mail- archive/web/dnsop/current/msg18332.html) which we made into Appendix B. I'm not sure if it's intentional (if it is, that's fine for me), but these two sentences are almost a duplicate and can be unified. -- JINMEI, Tatuya
- [DNSOP] Second Working Group Last Call - draft-ie… tjw ietf
- Re: [DNSOP] Second Working Group Last Call - draf… Warren Kumari
- Re: [DNSOP] Second Working Group Last Call - draf… Matthijs Mekking
- Re: [DNSOP] Second Working Group Last Call - draf… tjw ietf
- Re: [DNSOP] Second Working Group Last Call - draf… Stephane Bortzmeyer
- Re: [DNSOP] Second Working Group Last Call - draf… Bob Harold
- Re: [DNSOP] Second Working Group Last Call - draf… Warren Kumari
- Re: [DNSOP] Second Working Group Last Call - draf… Matthijs Mekking
- Re: [DNSOP] Second Working Group Last Call - draf… Stephane Bortzmeyer
- Re: [DNSOP] Second Working Group Last Call - draf… Ralph Dolmans
- Re: [DNSOP] Second Working Group Last Call - draf… Paul Wouters
- Re: [DNSOP] Second Working Group Last Call - draf… Stephane Bortzmeyer
- Re: [DNSOP] Second Working Group Last Call - draf… Paul Wouters
- Re: [DNSOP] Second Working Group Last Call - draf… Warren Kumari
- Re: [DNSOP] Second Working Group Last Call - draf… 神明達哉
- Re: [DNSOP] Second Working Group Last Call - draf… Stephane Bortzmeyer
- Re: [DNSOP] Second Working Group Last Call - draf… Stephane Bortzmeyer