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

Matthew Pounsett <> Tue, 27 September 2016 22:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03A5C12B401 for <>; Tue, 27 Sep 2016 15:46:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 49b1TD04kUvA for <>; Tue, 27 Sep 2016 15:46:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 991FB12B322 for <>; Tue, 27 Sep 2016 15:46:18 -0700 (PDT)
Received: by with SMTP id g67so31762825qkd.0 for <>; Tue, 27 Sep 2016 15:46:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tVCxIwti/q+Os8KfY2ny/Nqdja9tiYTU/EnUHsh+ibQ=; b=IRM9aRNFGG0BM3FCo02xyMaFbzIdofoFP61hmbCKsWZIEXxXX3CsnWp9Q1Y6cHKdh5 iV5erXLOZM8kwvrsZNo1Z1wEO27zFWjqvNB4uiwGw4R8+vgyBm1sIIJ6OM678tbGIeHD nwWFjCcEWQt7Q5npowGEXIaK/eMuXBEWNOQHaIbasE3rHs4qJDTgBRCchyqLWgdn0nC0 vnLRUFAqJW6wF6juIBVI3MqYQQo6M6mM4lCyq7Q3hnA5diagWcQCOHzsZ22AvRpsnHLR mD7ZZAQJISg13V4f4W+JWIG5j2nAytFWcN8nyypVg9YPzFe+Q52SYakEMm0sXUTNUQdr jgPg==
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=tVCxIwti/q+Os8KfY2ny/Nqdja9tiYTU/EnUHsh+ibQ=; b=W8/vIQqlZIRWS1lu35mFweD0a8JjlbGstfmzrQcrpww45/wI1FCJQ1qtiMEyRWxvSC lmacGgwXDXFMtJLYMzEmrp6dU2H6T9qi4SUWl7sbhFaB1808PzS8RKWjZoJ91PISz9EK nqMcFi0ElvjFGz/IzgaarWlBAOfXlUDJUeTIZoMaAK2D6l5osdorg0TyECJTAbjwRe3P pJ+Q1j+Z1tXI1PhAuUQtbLhbeP3eLTGmzkzMw7f+q9Oh7zwIJRhESwJugr5eeUITk15O l0ZDUIVwsKsk7nDvKJm51RLoWn6eu8D9DIX4+LJP0QKQ8lShCoFkpkxCVzaBxPZ7dqTZ x9Qw==
X-Gm-Message-State: AA6/9RlnASiyb0uVMbaQcTglZ+kHwPAfrnuUclCycg8Vl3ZxSLw7oVbKx7vaoR4VjFktFsXNWyNQJUVyEsPCyA==
X-Received: by with SMTP id o133mr28566567qka.191.1475016377366; Tue, 27 Sep 2016 15:46:17 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 27 Sep 2016 15:46:16 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: Matthew Pounsett <>
Date: Tue, 27 Sep 2016 15:46:16 -0700
Message-ID: <>
To: "White, Andrew" <>
Content-Type: multipart/alternative; boundary=001a114891c03636c1053d8503e4
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 22:46:21 -0000

On 27 September 2016 at 12:28, White, Andrew <>

> Hi Shumon,
> True. When a resolver gets an NXDOMAIN for, say, would it
> better to say the resolver SHOULD drop from cache all descendents of
>, or MAY?
> It may be computationally expensive to search cache to remove cached
> NXDOMAIN responses below, and I see no harm in letting
> those cached entries expire as their TTL runs out.

Would it be better then to leave early expiry as an implementation choice,
and instead say that the implementation SHOULD respond with NXDOMAIN for
any QNAME at or below a cached NXDOMAIN?

# When an iterative caching DNS resolver receives a response with RCODE
# 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 SHOULD be assumed to result in a name
# Responses to those queries SHOULD set RCODE=NXDOMAIN (using the DNSSEC
# records cached as proof).  Any names at or below the name received in the
# NXDOMAIN response MAY be flushed from cache at the time the response is
# received.

If has a cached record, and an nxdomain for is then cached, further queries for
would also trigger NXDOMAIN for as long as is in the
negative cache.

If the negative response for expires before the positive
response for, then that name could pop up in positive
responses again... if the implementation hasn't chosen to expire it as well.

My rationale is that if were still a valid name at the
time that the NXDOMAIN response was issued, then NXDOMAIN
was not the correct response.  It would be inappropriate to answer for out of the cache in that case.