Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

Shumon Huque <> Wed, 28 September 2016 15:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5D45D12B1BA for <>; Wed, 28 Sep 2016 08:21:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IjfZxV5oUomy for <>; Wed, 28 Sep 2016 08:21:28 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9E22212B1A4 for <>; Wed, 28 Sep 2016 08:21:26 -0700 (PDT)
Received: by with SMTP id l132so241731606wmf.0 for <>; Wed, 28 Sep 2016 08:21:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8onCr/dwwrORmFz3s1cn7NATw997m3JAMIvb5ut8e/4=; b=NNgi9AFi1YSO8+PT3glT5RhxG2Pb30JCn+qaxZgdHptwO2pHucDYvh5KZqQial2Dnt BVdv38/eqqdJB4cKE8OCJF2LKOw1XbYRQqmWHahNmiLRZ2woxIFi3CsOtZpTb3IM8f+8 Hl4Jzk5PUxlTmg9qvTWPeD2T28vBnabgc5o8Jc7xJOUhKlkQ2JbyV5xsYa/EJ75vC/HJ JagCFUZmpGdaQhDamxIhYwPSpHzGYpC+W7nznmqesfi4Zkly08DiwkrI4FhlgjccdPk8 /JsHl/xRiDBjtOYMB2CGaVyge6ZPOWG88jlbVr1OOZLjOfuygRAqQGcYz5ubE4KCbp2a lIdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8onCr/dwwrORmFz3s1cn7NATw997m3JAMIvb5ut8e/4=; b=OlkUmtfLoLMALiBiSOgSkDh4CZXZP/HR5HNP8K5wf/qm0pFS+tHwifZ5wkiR7L3zK+ Xw7Pv8mhgwhRjS2o1nmoiybw4SDPAvzXN9MlcmEMDH4zf3gIq5o8IfDVs++VAwOiDmoh kxYdQfnQg8YdSs8a2Jf1DKgOatIz7An5ZFzzXE6AUn0nkC2HnejdTgDM1UwX2eosy7QH KbaQ8sJtlwmZ5klQJm2WdFTrtMJNR6MseP82iB5h4vVmkB/xJGEv3nk/Chdjg1TEwluT bgMHqqUJMgLJwtgD2PyxwjfXYXJjuqayIpQXM+gXd9Bjyq3xCL/9DAQed/PFrW3/OOaI T11A==
X-Gm-Message-State: AA6/9RkfZGLDkb94+yM5tWUdNttLSi83BlUJwmHIJ1tbb7XZWb3lTpcN69Lr/X4r93ymCz3TPEGeQUhbiFL8jQ==
X-Received: by with SMTP id z205mr9092750wmb.123.1475076085114; Wed, 28 Sep 2016 08:21:25 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 28 Sep 2016 08:21:24 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
From: Shumon Huque <>
Date: Wed, 28 Sep 2016 11:21:24 -0400
Message-ID: <>
To: Edward Lewis <>
Content-Type: multipart/alternative; boundary=001a114b317c1218e3053d92eaaa
Archived-At: <>
Cc: "" <>
Subject: Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Sep 2016 15:21:33 -0000

On Wed, Sep 28, 2016 at 9:42 AM, Edward Lewis <>

> On 9/27/16, 18:46, "Matthew Pounsett" <> wrote:
> >Would it be better then to leave early expiry as an implementation choice
> I think it comes down to implementer's choice.  The goal of the (IETF in
> general) documents is interoperability. Whether or not a cache chooses to
> keep the cached entries or remove them, or the way in which it chooses
> which of two (or more) valid answers to give doesn't impact
> interoperability.  So long as the response given is protocol-appropriate.
> The issue is, which response (of a set of possible responses) is correct
> is not definable within the DNS protocol.  So, there's no winner here.

I agree, and this seems entirely in keeping with the loosely coherent
distributed database model of the DNS.


> As far as DNSSEC, this only works with DNSSEC in place, right?  You need
> the missing span proofs or you are NXDOMAIN'ing entire zones, not just
> entire domains (within a zone).

The draft does not currently require DNSSEC. It's true that without DNSSEC,
the impact of a spoofed NXDOMAIN is much larger, and for this reason the
draft does mention that implementations could choose to deploy this
enhancement only for signed data (and some implementations have already
taken this route).

To be precise, I would say we are not necessarily always pruning out entire
zones. For a leaf zone, we are pruning all names within that zone below the
nxdomain-cut, modulo cached entries, i.e. a subset of the zone. But yes,
for non-leaf zones, all zones below too are pruned.

Shumon Huque