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

Shumon Huque <> Tue, 27 September 2016 19:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C7EA112B202 for <>; Tue, 27 Sep 2016 12:33:31 -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 ru9IjqL4dpaA for <>; Tue, 27 Sep 2016 12:33:29 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 57F2B12B014 for <>; Tue, 27 Sep 2016 12:33:29 -0700 (PDT)
Received: by with SMTP id l132so195125482wmf.0 for <>; Tue, 27 Sep 2016 12:33:29 -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=tF3yVf+FxCbipdbReH1NRla2LVvsMCxjxgZ/jWVbohg=; b=mPpCsuL9Ltw3g4IbSQKgREMq6FEc/fVEtsuzUcF220MUyKCnBP1H/ioFHyNbHAFhbv YY1ShRSqAOd42qOUqglo1Y7oFDp0N0jCNGIY6FOHzgu2/5G94ukjd+z9iydVETkXaxVv F0cKU05bO1vNyClkt39XQ8i1HWXDISQ7LPnFNq4Umi9QUyRpZmsYaUXNaw2ULFMIOag+ hLedjfwzsKKEAFRG2Q+Kajam2wddaqISbVvNkV4DoiE9om8j7b+1bMYN1WdUJH82mT7m eLNfKt/NnY5MlPyxXZRoBOJZa2ocKcn80Qf7oxwXrlATMmeRxyamGWu60c0vy0Go0bH5 P3sg==
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=tF3yVf+FxCbipdbReH1NRla2LVvsMCxjxgZ/jWVbohg=; b=U3jCAZcejfoGcYoY5LIrz1yQ050v7Z58F+/9fZGg21a3gtF4nzRpOSoTCbKxlfuP9C C1HC2JCiYRhiXAST+FkcuhggBNqrd1rabXxI+LfsarauWtssV+BFzjpfXlnK99aJDJlp hkvq+nLa/lUiM+BqSr1SiQftQ9vTl/ha1MR3yYnz1B6wRkK1s2j9kvPbxvhOk9i7ikQk zP39wLy+ZGmFaw3elZMf7CLDHOODBxZ5Eqizf6qgu4J5tDoUmZIxTs/n9B2xEsdu006+ ++PpdnN3bJykDe2hNlLxAtEOaFAg9SKfN0L97huzspXqqhn60/W1m8wK1exRvXyfdpcH zLBw==
X-Gm-Message-State: AE9vXwNVTY8vK7R0aOu/EpXA18WgsJP+R2h9DcSkUdm4U6Z0KIV0dVN0vdxaZkwTw0Jw+WTlzTOYnsFREDWYNw==
X-Received: by with SMTP id r8mr23932536wjt.190.1475004807772; Tue, 27 Sep 2016 12:33:27 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 27 Sep 2016 12:33:26 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Shumon Huque <>
Date: Tue, 27 Sep 2016 15:33:26 -0400
Message-ID: <>
To: "White, Andrew" <>
Content-Type: multipart/alternative; boundary=047d7bf0db909c0044053d8251ca
Archived-At: <>
Cc: Edward Lewis <>, "" <>
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: Tue, 27 Sep 2016 19:33:32 -0000

On Tue, Sep 27, 2016 at 3:10 PM, Shumon Huque <> wrote:

> On Tue, Sep 27, 2016 at 2:48 PM, White, Andrew <>
> wrote:
>> Hi Shumon,
>> What about this?
>> # When an iterative caching DNS resolver receives a response with RCODE
>> being NXDOMAIN,
>> # the resolver SHOULD store the response in its (negative) cache.  During
>> the time the response
>> # is cached, any query with a QNAME at or descended from the denied name
>> that is not otherwise
>> #cached (positively), can be assumed to result in a name error.
>> Responses to those queries
>> # SHOULD set RCODE=NXDOMAIN (using the DNSSEC records cached as proof).
>> When an iterative caching DNS resolver receives a query response with
>> The resolver should store the NXDOMAIN response in cache. During the time
>> that this response
>> is cached, any query with a QNAME at or descended from the query that
>> resulted in NXDOMAIN
>> and that is not already in cache can be assumed to result in a name
>> error. Responses to such
>> queries SHOULD respond with RCODE as NXDOMAIN using DNSSEC records from
>> cache as proof.
>> Andrew
> Andrew - this looks very similar to Ed's rewrite.
> The problem I see with both is that it says to reply with NXDOMAIN for all
> names at or below the cut, except for RRsets already positively cached. But
> the current draft also allows resolvers to immediately invalidate cached
> entries below the cut and also return NXDOMAIN for them. Your rewrite
> appears to remove (or at least not mention) that possibility.
> --
> Shumon Huque

One other quick comment on the rewrite:

" .. (using the DNSSEC records cached as proof)." is a bit unclear and
perhaps misplaced. I assume here this means signed NSEC or NSEC3 records,
which may or may not exist depending on whether the zone in question is
signed. And even if they exist, the resolver typically doesn't return them
as proof unless the querier sets DO=1. I think we cover this point further
down in the text, which I'll excerpt here:

  "If the NXDOMAIN response due to a cached non-existence is from a
   DNSSEC signed zone, then it will have accompanying NSEC or NSEC3
   records that authenticate the non-existence of the name.  For a
   descendant name of the original NXDOMAIN name, the same set of NSEC
   or NSEC3 records proves the non-existence of the descendant name.
   The iterative, caching resolver MUST return these NSEC or NSEC3
   records in the response to the triggering query if the query had the
   DNSSEC OK (DO) bit set."

Re-reading this paragraph, I think I'd suggest explicitly mentioning that
the NSEC/NSEC3 signatures must be returned also.

Shumon Huque