Re: [dmarc-ietf] Draft 10 notes: NXDOMAIN

Scott Kitterman <sklist@kitterman.com> Tue, 28 June 2022 18:54 UTC

Return-Path: <sklist@kitterman.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D33C15AAE2 for <dmarc@ietfa.amsl.com>; Tue, 28 Jun 2022 11:54:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=/hhsnKXY; dkim=pass (2048-bit key) header.d=kitterman.com header.b=iuTFbChV
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytrivUQql5mk for <dmarc@ietfa.amsl.com>; Tue, 28 Jun 2022 11:54:14 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B1E2C157B5D for <dmarc@ietf.org>; Tue, 28 Jun 2022 11:54:14 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 435C1F802E0; Tue, 28 Jun 2022 14:54:10 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1656442450; h=date : from : to : subject : in-reply-to : references : message-id : mime-version : content-type : content-transfer-encoding : from; bh=pnUMPkKFPxtWGv7Jls+d33+P/Rb2g5qZ7hK2ohF7avQ=; b=/hhsnKXYZt267YqTxseLXseRMHBaqCECUfAI6Y4COSLToLQSXzcEfycwxvjhYb03RgaTA h1+xCx1bblOab2MCQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1656442450; h=date : from : to : subject : in-reply-to : references : message-id : mime-version : content-type : content-transfer-encoding : from; bh=pnUMPkKFPxtWGv7Jls+d33+P/Rb2g5qZ7hK2ohF7avQ=; b=iuTFbChVeCezMT8hRKOhhUQWppPQrutQ5sEX0BecUBFvVlYIq2VIoy2/a9o3pUVQA09mn Q2NxcKCwOsv/II9wSrl7n7mV9eyZ7sZwdW0RIe1wrNyr++eDhCNSEtfAInU34kN+hEYN+0s kMTCJ09xbX4ZFuLneHLQWed5JHvVmMrhxn6VPnDBagquCLTHNMq8PHcwxuLAqzFD38kC01O z2O62ejknSruZnp2BbudbcyWLZWRgWeto2YReLCZTVmzJIVcSVgOnwcjyWeDJujlIAtbCK3 P5aIpEaymiiAzoXMDMrUsHUbnEaXfTl8ai4c+0cQtMHwxNl8iAzz/4+T9hgw==
Received: from [127.0.0.1] (mobile-166-170-57-161.mycingular.net [166.170.57.161]) by interserver.kitterman.com (Postfix) with ESMTPSA id DE4ACF801D9; Tue, 28 Jun 2022 14:54:09 -0400 (EDT)
Date: Tue, 28 Jun 2022 18:54:09 +0000
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
In-Reply-To: <CAHej_8nyF5F9Du+5YAEZStHtY_M5LWFm7w9NS2Vy8pO9f-xPuw@mail.gmail.com>
References: <CAH48Zfy4mKG=K+YamFiQVSt0D-oDPOBDaJLsW3iX7HucCQRV+g@mail.gmail.com> <CAHej_8nve0nevJ5=F7MPCQc4s=KPjQqNe++KOhiYbJPh_Q0yUg@mail.gmail.com> <CAH48Zfzk33iAd_8iyQ43kovXCf8pbNiNYP8MfY=gt7-=M6KZ7g@mail.gmail.com> <CAHej_8nyF5F9Du+5YAEZStHtY_M5LWFm7w9NS2Vy8pO9f-xPuw@mail.gmail.com>
Message-ID: <F7D21A3A-F948-447D-A4F6-5A9B1C22E785@kitterman.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/z_qCgxOvOElJQ9hYSYxAXm7WbpI>
Subject: Re: [dmarc-ietf] Draft 10 notes: NXDOMAIN
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jun 2022 18:54:18 -0000


On June 28, 2022 6:02:54 PM UTC, Todd Herr <todd.herr=40valimail.com@dmarc.ietf.org> wrote:
>On Mon, Jun 27, 2022 at 8:36 PM Douglas Foster <
>dougfoster.emailstandards@gmail.com> wrote:
>
>> My testing was done more than a year ago.   My recollection is that I
>> discovered it based on something in the wild, and then confirmed it with a
>> locally-configured experiment.   This time I am having trouble finding
>> examples.
>>
>> The only one I can verify is from a previous email exchange on this forum:
>>
>> mail.foodnetwork.com
>> returns NXDOMAIN
>>
>> but
>> _dmarc.mail.foodnetwork.com
>> returns DATA for type=TXT
>>
>
>Thank you for the further information.
>
>In regards to RFC 8020, rev -10 of DMARCbis currently reads as follows:
>
>7.8.  <#section-7.8>Domain Existence Test <#name-domain-existence-test>
>
>RFC 7489 used the test specified in [RFC5321 <#RFC5321>] to determine a
>domain's existence. This test requires up to three DNS lookups for the MX,
>A, and AAAA RRs for the name in question.ΒΆ <#section-7.8-1>
>
>This version of the protocol relies solely on the test for existence as
>defined in [RFC8020 <#RFC8020>]. If a query for a name returns NXDOMAIN,
>then the name does not exist.
>
><#section-7.8-2>
>But I'm not sure that this is correct, especially not the first sentence,
>because here's what RFC 7489 has to say on the topic:
>
>
...

The first sentence is from RFC 9091 and should be deleted.  At some point in the DMARCbis work we did decide to go with the RFC 8020 approach, but it looks like the document update was incomplete.


>used the test specified in RFC 5321 to determine a domain's
>existence."  This would argue for the text of "Domain Existence
>
>Test" in DMARCbis to be reworded.
>
>
>The "np" tag didn't exist in RFC 7489, and it's not clear to me that
>RFC 7489 cared all that much about whether a domain existed.
>
>In DMARCbis, however, the "np" tag does exist, and so it seems we must
>settle on a way to determine whether or not a domain exists,
>
>and RFC 8020 seems to be the more efficient method than RFC 5321, as
>it requires just one query, not three.

I think that's what we wanted, but only updated things incompletely.

Scott K

P.S. Sorry if I butchered the snipping.  Soooooo many words to sort out on my phone.