Re: [DNSOP] Spencer Dawkins' Yes on draft-ietf-dnsop-nxdomain-cut-04: (with COMMENT)

Tim Wicinski <tjw.ietf@gmail.com> Thu, 15 September 2016 08:49 UTC

Return-Path: <tjw.ietf@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 3218912B4A6; Thu, 15 Sep 2016 01:49:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 c2hOjGOiIxVy; Thu, 15 Sep 2016 01:49:56 -0700 (PDT)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 CB20112B4A3; Thu, 15 Sep 2016 01:49:55 -0700 (PDT)
Received: by mail-qk0-x233.google.com with SMTP id w204so40147519qka.0; Thu, 15 Sep 2016 01:49:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=dwiCbwqEhFafVPPSHtxHMBMtqfJNuK33KH6S5pr3YFk=; b=tclCw4k3IToRbElbkXzB5hw8XW4GNSp91edDGKTUtn5r56FJN+5qBpTEsfzubLj1iJ 6+gAY2XOuGlD/gRzVtVGUKWOwEPLk249UXQD2mk3VSP5w690AEdhKk9FoGHiU6JNgHQ/ n7qUO0WRbpv1b8AGvhYAzE+kKGaruIC2+1dqE/SqQAKeQTm06t/FIU3e/LoP3We124iD 37KGH95r7KQuxPBuwkneJX/aZ/qLJRdBp7toVczzxBWJpAi7lh+uTFZ6YkaGrL47EbDg qPJhZzZqr5JEQ3GrGwD+QleO28Cw15fzXVgb4TRNT6O7h6JyyZeQ3BF1o6dBiECqatdN Ua0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=dwiCbwqEhFafVPPSHtxHMBMtqfJNuK33KH6S5pr3YFk=; b=XXvx0K1J6G7FZsiQo0WbsvtGp+0Xho+WRgODcKelndhwd9H28dhi0vYktGwcInWxYT fO0i2BJSxoW4IforqQKY/gyL6O6RD7NbhF8/8OfRvItQkyBtRgY383ZJrUCjEqFBjJrW eILdPoGF+U+0JrqMEydBYh9OOek6LcYvHKlIRSFplNu6MMrnAGtEII9cnCdnnhPEMETG 7xdbsoaO46B38l/WYkzU5X1lgYF6Wbx7ke2SMmdtpXKGgvWtmpptLJ17xsfq5EuBzyls IRVSgZ+3uB2lew2MSEtinY9/w1zk7wk4fCNB04OK1WlHCgQTqkUuvbA78nyVhKxk8IX5 44+g==
X-Gm-Message-State: AE9vXwOh4kfQW8aG6UeVJVMflfNKlN0PFSFGKvJPwRNRTn3wzKaY2bBPyel1RbU8RYvXhw==
X-Received: by 10.55.11.20 with SMTP id 20mr172791qkl.258.1473929394860; Thu, 15 Sep 2016 01:49:54 -0700 (PDT)
Received: from twicinski-ltm1.internal.salesforce.com ([204.14.236.152]) by smtp.googlemail.com with ESMTPSA id s56sm1334489qts.4.2016.09.15.01.49.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Sep 2016 01:49:54 -0700 (PDT)
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>, Shumon Huque <shuque@gmail.com>
References: <147387558442.19766.339355303388852115.idtracker@ietfa.amsl.com> <CAHPuVdVdLP=j3UCUopt9fS99hg0EuDK_XV+cWpNoU9ZyKGz=5g@mail.gmail.com> <20160915083710.6obsa5osozkiymkn@nic.fr>
From: Tim Wicinski <tjw.ietf@gmail.com>
Message-ID: <b1af5b14-5651-6240-a968-23bdae064780@gmail.com>
Date: Thu, 15 Sep 2016 04:49:52 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <20160915083710.6obsa5osozkiymkn@nic.fr>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/m--_PQD_Btn2oAf_NxiHnCbGMDo>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>, draft-ietf-dnsop-nxdomain-cut@ietf.org, dnsop-chairs@ietf.org, Spencer Dawkins <spencerdawkins.ietf@gmail.com>, The IESG <iesg@ietf.org>
Subject: Re: [DNSOP] Spencer Dawkins' Yes on draft-ietf-dnsop-nxdomain-cut-04: (with COMMENT)
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: Thu, 15 Sep 2016 08:49:57 -0000


On 9/15/16 4:37 AM, Stephane Bortzmeyer wrote:
> On Wed, Sep 14, 2016 at 02:33:58PM -0700,
>  Shumon Huque <shuque@gmail.com> wrote
>  a message of 146 lines which said:
>
>> The section [appendix A] is attempting to say that it is NOT OK to
>> use the SOA record owner name. We could make that clearer.
>
> OK, but I don't see how.

Here is the paragraph in question:

    In this document, we deduce the non-existence of a domain only for
    NXDOMAIN answers where the denied name was this exact domain.  If a
    resolver sends a query to the name servers of the TLD example, and
    asks the MX record for www.foobar.example, and receives a NXDOMAIN,
    it can only register the fact that www.foobar.example (and everything
    underneath) does not exist.  Even if the accompanying SOA record is
    for example only, one cannot infer that foobar.example is
    nonexistent.  The accompanying SOA indicates the apex of the zone,
    not the closest existing domain name.

Here is a possible update (changes marked with *'s)

    In this document, we deduce the non-existence of a domain only for
    NXDOMAIN answers where the denied name was *the* exact domain.  If a
    resolver sends a query to the name servers of the TLD example, *then*
    asks *for* the MX record for www.foobar.example, and receives a
    NXDOMAIN,it can only register the fact that www.foobar.example (and
    everything underneath) does not exist.  *This is true regardless*
    if the accompanying SOA record is for example only*. O*ne cannot
    infer that foobar.example is nonexistent.
    The accompanying SOA *record* indicates the apex of the zone,
    not the closest existing domain name.

tim

>
>> I would personally be okay with removing this section also. I can't
>> recall what discussion happened that caused this scenario to be
>> included - maybe Stephane remembers.
>
> This was mostly because I did not get the point at the beginning (I
> think John Levine explained it to me). IMHO, it is important to keep
> this appendix (not a "real" section) because other DNS people may make
> the same mistake as I originally did and ask "why not use the SOA
> record to find the NXDOMAIN cut?"
>