Re: [DNSOP] NXDOMAIN and RFC 8020

"libor.peltan" <libor.peltan@nic.cz> Tue, 06 April 2021 18:29 UTC

Return-Path: <libor.peltan@nic.cz>
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 BBE443A2B85 for <dnsop@ietfa.amsl.com>; Tue, 6 Apr 2021 11:29:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.399
X-Spam-Level:
X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 WNqFtPYOkdTs for <dnsop@ietfa.amsl.com>; Tue, 6 Apr 2021 11:29:08 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B425F3A2B81 for <dnsop@ietf.org>; Tue, 6 Apr 2021 11:29:07 -0700 (PDT)
Received: from [IPv6:2001:1488:fffe:6:fb3b:a4dc:6981:74f9] (unknown [IPv6:2001:1488:fffe:6:fb3b:a4dc:6981:74f9]) by mail.nic.cz (Postfix) with ESMTPSA id 08BA5140A94; Tue, 6 Apr 2021 20:29:03 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1617733744; bh=XXDlLB2qYJFmwFtKseZEIv85h8AZWx3LQvi2+8nAfhg=; h=To:From:Date; b=btFtBeDvKvKCGWZbR25KNqj1eqkiu/bZL2co97i3JAsXLMKhxiPJ11U7IBAiHveSI klnZXUwXJX2bvmdFbeJRW3j3/kVDXUJ4qAfooFAHop65ko02sov1NI2beNBacyzVYV aU62kwHRCRrVtYaA57hMNq9zj7fHB9WOxnmHyztQ=
To: dnsop@ietf.org, "Murray S. Kucherawy" <superuser@gmail.com>
References: <CAL0qLwai81BFYfG=u-Z+sVgE8aBvU1gGgOjO_vYH_aLP9GsnxA@mail.gmail.com>
From: "libor.peltan" <libor.peltan@nic.cz>
Message-ID: <3c163088-2b5b-a64b-129f-de9932ebad40@nic.cz>
Date: Tue, 06 Apr 2021 20:29:03 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <CAL0qLwai81BFYfG=u-Z+sVgE8aBvU1gGgOjO_vYH_aLP9GsnxA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------4226D4C3C8AD0D5B3FB3C696"
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.102.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/DlBvWReK540CqUrYEBI3Xf_7Xr8>
Subject: Re: [DNSOP] NXDOMAIN and RFC 8020
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 06 Apr 2021 18:29:13 -0000

Hi Murray,

if foo.example does not exist and DNSSEC is in place, than the resolver 
actually, even with the queries "in reverse order", obtains and NSEC(3), 
proving non-existence for much more.

For example, the query is bar.foo.example, and the authoritative returns 
an NSEC proving that there is nothing between fa.example and fz.example. 
Thus, the resolver can later deduct nonexistence not only for 
foo.example, but also for fun.example and bar.fun.example, etc...

Without DNSSEC, this deduction (called "aggresive NSEC caching") is not 
possible.

Cheers,

Libor

Dne 06. 04. 21 v 20:11 Murray S. Kucherawy napsal(a):
> I'm wondering something about tree walks, which John Levine asked 
> about in November, as it's a topic of interest to the evolution of DMARC.
>
> I've read RFC 8020 which says an NXDOMAIN cached for "foo.example" 
> also covers later queries for "bar.foo.example".  Makes sense.
>
> Can this be used (or maybe amended) to cover the queries if they come 
> in the reverse order?  For instance, if "bar.foo.example" arrives 
> first, but the authoritative server can determine that the entire 
> "foo.example" tree doesn't exist, could it reply with an NXDOMAIN for 
> the question plus a cacheable indication about the entire tree instead 
> of just the name that was in the question?
>
> This would make an ascending tree walk even for something crazy like 
> "a.b.c.d.....y.z.foo.example" extremely cheap as the cached NXDOMAIN 
> for "foo.example" covers the entire subtree, for a caching nameserver 
> implementing RFC 8020.
>
> Maybe this is discussed somewhere that I missed in the references.  
> I'm happy to take a "go read this for the answer" if that's the case.
>
> Thanks,
>
> -MSK
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop