Re: [DNSOP] How does NSEC record(s) prove the Name Error?

Mark Andrews <marka@isc.org> Wed, 27 October 2021 06:25 UTC

Return-Path: <marka@isc.org>
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 A46AB3A0AB0 for <dnsop@ietfa.amsl.com>; Tue, 26 Oct 2021 23:25:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isc.org header.b=hf0MRHwM; dkim=pass (1024-bit key) header.d=isc.org header.b=Cn597Vue
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 HsSjf_pofLaH for <dnsop@ietfa.amsl.com>; Tue, 26 Oct 2021 23:25:09 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 EC8E73A0AAA for <dnsop@ietf.org>; Tue, 26 Oct 2021 23:25:09 -0700 (PDT)
Received: from zimbrang.isc.org (zimbrang.isc.org [149.20.1.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 39A853AB0B0; Wed, 27 Oct 2021 06:25:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1635315907; bh=Mlasqg8dlTXgYj7rRwnzyeQHT25ilpmRW1inHazSgKQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=hf0MRHwMCjD6FBVKj2/T3Eks1zSuRRhWn2iZ1F9TGPSA5pAGjzFgnXlAPidxfSDsJ o1Qn3nBQ3yHk6UsXTL6HKijqEVz000LzjNfXaqxeEwDTCUh40ZML2bWvPOUQcGDrIh 4wn1iOs04t2FhMq9KiBFhNo+bc82YGdHBxE0b2Zc=
Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id 40B6AF03682; Wed, 27 Oct 2021 06:25:06 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id 0F9BAF03683; Wed, 27 Oct 2021 06:25:06 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org 0F9BAF03683
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1635315906; bh=lg44nht42lyb7AUo3FTLR8tM9imu5b3vdjrbSGZBCfA=; h=Mime-Version:From:Date:Message-Id:To; b=Cn597VueHD3ioyGoov+SyRweH1bR/k5kcl9k/sgPh/lD5pS1+VhXlN6iJGoT983mZ 0DfBHNHAd+kBg1exW7AqPNUS0NpdxNeOMS+7y40NSxDpB5U4fYJxbMdWTs9T+IMOSH 2Qo46rZbsi8NQfbwNpYy8m5AnQpyXvlz13secUOE=
Received: from zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id cXjO7EwSFaZ4; Wed, 27 Oct 2021 06:25:05 +0000 (UTC)
Received: from smtpclient.apple (n114-74-30-70.bla4.nsw.optusnet.com.au [114.74.30.70]) by zimbrang.isc.org (Postfix) with ESMTPSA id 3D3ADF03681; Wed, 27 Oct 2021 06:25:05 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <A28D84C7-FB84-4A3B-A041-04ADB799C0BC@apple.com>
Date: Wed, 27 Oct 2021 17:25:02 +1100
Cc: dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <A590298F-9AC5-4E68-87E0-45AF3DBFFC94@isc.org>
References: <A28D84C7-FB84-4A3B-A041-04ADB799C0BC@apple.com>
To: Joey Deng <qiaoyu_deng=40apple.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/PHSpegx3v_-dx3ym5W-6SBrJBGM>
Subject: Re: [DNSOP] How does NSEC record(s) prove the Name Error?
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: Wed, 27 Oct 2021 06:25:15 -0000

For a given QNAME there is exactly one possible wild card name it can match depending
on all the other names that exist.  See the rules for when a QNAME matches a wildcard.

NXDOMAIN proves that a QNAME does not exist.  The NSEC record that proves that a QNAME
does not exist also proves the closest encloser name.  It is this name to which you
prepend the * label and it is that name that you prove does not exist.  Similarly for
NSEC3 except that the closest provable encloser may or may not be the NSEC3 record
that proves the QNAME does not exist.

An NSEC NXDOMAIN proof has 1 or 2 NSEC records.  A given record can prove multiple things.

An NSEC3 NXDOMAIN proof has 1, 2, or 3 NSEC3 records. A given record can prove multiple things.

Mark

> On 27 Oct 2021, at 16:21, Joey Deng <qiaoyu_deng=40apple.com@dmarc.ietf.org> wrote:
> 
> Hi Folks,
> 
> I have a very basic question about NSEC record in DNSSEC validation:
> 
> How does NSEC record(s) prove the Name Error?
> 
> In [RFC 4035 5.4. Authenticated Denial of Existence](https://datatracker.ietf.org/doc/html/rfc4035#section-5.4), it says:
> 
>>    o  If the requested RR name matches the owner name of an
>>       authenticated NSEC RR, then the NSEC RR's type bit map field lists
>>       all RR types present at that owner name, and a resolver can prove
>>       that the requested RR type does not exist by checking for the RR
>>       type in the bit map.  If the number of labels in an authenticated
>>       NSEC RR's owner name equals the Labels field of the covering RRSIG
>>       RR, then the existence of the NSEC RR proves that wildcard
>>       expansion could not have been used to match the request.
>> 
>>    o  If the requested RR name would appear after an authenticated NSEC
>>       RR's owner name and before the name listed in that NSEC RR's Next
>>       Domain Name field according to the canonical DNS name order
>>       defined in [
>> RFC4034
>> ], then no RRsets with the requested name exist
>>       in the zone.  However, it is possible that a wildcard could be
>>       used to match the requested RR owner name and type, so proving
>>       that the requested RRset does not exist also requires proving that
>>       no possible wildcard RRset exists that could have been used to
>>       generate a positive response.
>> 
>> 
> 
> I can understand the first point, because it is an exact name matching. However, what makes me feel confused is the second one:
> 
> If the question name appears in-between the current owner name and the next owner name of the NSEC record, which means that there is no exact name matching:
> We should prove that
>> no possible wildcard RRset exists that could have been used to generate a positive response.
> 
> But it does not describe how to prove it,
> 
> What are possible wildcard RRsets for a given name?
> 
> My understanding about possible wildcard RRsets for a given name are all the possible sources of synthesis.
> For example, the possible wildcard RRsets that can be used to answer question wwww.ietf.org AAAA are:
> *.ietf.org
> *.org
> * (but I think root can never be a wildcard, so this is impossible)
> 
> Is my understanding correct?
> 
> ————————————————————————————————————————————————————————————————————————
> 
> For example, if I send a DNS query for wwww.ietf.org with DO/CD bit set, there will be two NSEC records returned:
> 
> ```
> $ dig "wwww.ietf.org" AAAA +dnssec +cdflag +tcp @1.1.1.1
> 
> ; <<>> DiG 9.10.6 <<>> wwww.ietf.org AAAA +dnssec +cdflag +tcp @1.1.1.1
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 34013
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 1232
> ;; QUESTION SECTION:
> ;wwww.ietf.org.			IN	AAAA
> 
> ;; AUTHORITY SECTION:
> ietf.org.		1800	IN	SOA	ns0.amsl.com. glen.amsl.com. 1200000537 1800 1800 604800 1800
> ietf.org.		1800	IN	RRSIG	SOA 5 2 1800 20221019014909 20211019005139 40452 ietf.org. GUaWdfXoPWOjb+/1w5Dtn8VoeemBYXdDIQui365JuuIBkEC4YKFLb+m+ u8YJ+cbnTzDb768HkTX8AbWaupZVR2FLn2r06hf6YruVi5jRjzExYLQ6 22Rn8TCvNpNRBZ7fyEcBd9m3aacGr+2iBXgYL9QRXag0tSAAW5oxjI8H CcQLLylwGKDvQv2sNIQLxZlkYFXa+swBOuFQdT8MmymOKjV1d+p3s+S0 1HdUb7JAR2vTK/UVib5zfyXGiQcpD6F3XOQNVTY2dgc2ywAqoudANVmz Rm9rql12MALn2hu5HwrfC0djzXxo6Ry8I0KLmRtAsDoz4ie95Oh1Bnt4 qUhJLA==
> wwwtest.ietf.org.	1800	IN	NSEC	xml2rfc.ietf.org. CNAME RRSIG NSEC
> wwwtest.ietf.org.	1800	IN	RRSIG	NSEC 5 3 1800 20221019015021 20211019005139 40452 ietf.org. regwKawm6O9BAaHVyBICHjPlGiwDWoXO8OaqH4zJOOgAglrAMXajbEmx XHJsbq3DVEVGkU8NSQJxmGYjklyKzmMbIBpt7+RaXKT7WIGd/zRjSlnI gWSztB6gWTMQq98vQKeFgrt5X8a10p6C36gtJh5sGFq8FpiAvKoKuGO8 tyWKxux7pEQhlhTySr7ipRe8qmGDpy4H+8bkGqvJ7UJ0f3A366bZyD2Q XLdTG4DUrNWt8wKK0FiL2851PegU8FdQb0IXOlBHNF6qXiKCIhBLbK4W 3O3UYKsNLhYPBYuWNGZQ2mlEsfgUC9ddBU1trmMEObm3E+1tR/jemSYA uF+S7Q==
> ietf.org.		1800	IN	NSEC	_dmarc.ietf.org. A NS SOA MX TXT AAAA RRSIG NSEC DNSKEY SPF
> ietf.org.		1800	IN	RRSIG	NSEC 5 2 1800 20221019015032 20211019005139 40452 ietf.org. PiCNEGBSBbC/ALNR5ebDwk1wQGMH/l6MtV5ZAGYl9M1wf43NrqHapDlU AP2E07FsPIyo9PcWui67PidLgVA4e0rRJbyHK2B92tEeprZbxSOCeIFi NWiLl1oCZt+IQCCnFlzJkbwk2MWOVRYxUdQfmWk0QZZZtRr1c/i4VwPU MAVqCORkGpc6W6LLiTITLphe7X0NHb7e41n8J06tPh1a6GmRYRJCy41c F26Bf6GcEJBpNTvlNuirimbhvjL4Ax+FHBe5MA/Tjp4K1AeUIA0ibBVI 20o14zUqSsph67/Snz9fdpJ/dsvP9QwTNLTKR6Jxofi/ArWEBEheXsm+ pkZTRA== 
> ```
> 
> The two returned NSEC records are:
> wwwtest.ietf.org. -> xml2rfc.ietf.org.
> ietf.org. -> _dmarc.ietf.org.
> 
> If we follow the steps described by [RFC 4035 5.4. Authenticated Denial of Existence](https://datatracker.ietf.org/doc/html/rfc4035#section-5.4), we will find that:
> 
> wwwtest.ietf.org. -> xml2rfc.ietf.org. tells us that the exact name match for wwww.ietf.org does not exist, since it appears in-between the two names. Therefore, the remaining ietf.org. -> _dmarc.ietf.org. NSEC should be used to prove that “no possible wildcard RRset exists that could have been used to generate a positive response” for the name wwww.ietf.org.
> 
> Therefore, my question is:
> How can ietf.org. -> _dmarc.ietf.org NSEC be used to prove that there is no wildcard record for the name wwww.ietf.org? Do we need to prove that all the possible sources of synthesis for wwww.ietf.org appear in-between ietf.org. and _dmarc.ietf.org?

wwwtest.ietf.org. -> xml2rfc.ietf.org proves that the closest encloser is ietf.org.  The corresponding wildcard name
is *.ietf.org. ietf.org. -> _dmarc.ietf.org proves that *.ietf.org does not exist.

> Or do we only need to prove that *.ietf.org appears in-between ietf.org. and _dmarc.ietf.org? If so why do we choose *.ietf.org instead of *.org or *?
> 
> Thanks.
> 
> --
> Joey Deng
> 
> 
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org