Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

"Douglas E. Foster" <> Sun, 22 November 2020 01:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D8FD63A0B62 for <>; Sat, 21 Nov 2020 17:32:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DnwqGZaBZu1i for <>; Sat, 21 Nov 2020 17:32:18 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 978D23A0B60 for <>; Sat, 21 Nov 2020 17:32:18 -0800 (PST)
X-ASG-Debug-ID: 1606008733-11fa313c0128b30001-K2EkT1
Received: from ( []) by with ESMTP id wq2wEDVbCmVDx8Vm (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for <>; Sat, 21 Nov 2020 20:32:13 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1025; h=message-id:reply-to:subject:to:from; bh=8Ngply0qTZAcGBXTwNLbA5nckqTeOi6alaCeFwfnVuU=; b=SDbhn8KmiiaAlw7rbXR8NNqgbKJAK9bqSzMdbUfM74XpqEwdebHeAh+uF18Kb9y8p fBc2M6zH33kuI73/0zYJZjin+E54Tmg0b6FS58AHHDyqBB6/InYl7nfjmQjQ2Wcok qHsPo9BWAJ60V47OO0ydX2RP4bKv+sooKYGqOEe60=
From: "Douglas E. Foster" <>
To: "" <>
Date: Sat, 21 Nov 2020 20:32:06 -0500
X-ASG-Orig-Subj: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP
Message-ID: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=3e7d0500fd8543d893a1b51123d2aa24
In-Reply-To: <>
References: <> <20201120040420.B3F4727A02FB@ary.qy> <> <000001d6bf45$0f62cc30$2e286490$> <> <> <> <> <>
X-Exim-Id: 1331a357df2645b29f326783bd83a697
X-Barracuda-Start-Time: 1606008733
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Virus-Scanned: by bsmtpd at
X-Barracuda-Scan-Msg-Size: 17136
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE
X-Barracuda-Spam-Report: Code version 3.2, rules version Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message
Archived-At: <>
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 22 Nov 2020 01:32:21 -0000

I am arguing for the position that all unregistered domains are inherently invalid, because they are not registered.

PSD for DMARC proposes that non-existent domains should be blocked.    In their discussions, I remember the UK government reporting that they had registered 27,000 domains simply so they could publish SPF -ALL, in an attempt to block spammers from spoofing their government agencies.   I have a problem with the definition they chose in their document, but I fully agree that this is a problem that should be fixed.

They have also suggested that their "np" policy has general applicability, an argument which I find compelling.   By "general", I mean non-existent TLDs, non-existent public suffixes below the TLD, non-existent organizations, and non-existent subdomains of organizations.

Their experience demonstrates that an undefined domain is very difficult to protect.

On tree walk, I was working from John Levine's proposal, which assumes that a tree walk has to be distance limited for performance reasons.   He tentatively proposed four levels.   If you walk up the tree and find no DMARC entry, the walk stops with the conclusion that no policy has been issued.   This approach works if (and only if) the tree exists, so that the organization can place a policy at every fourth level.   The approach cannot work if the tree can be extended with non-existent domains.    It also conflicts with the PSD proposal which requires checking the top of the tree structure.

I had considered the top-down approach also, for the same reasons as you mentioned.   I assumed that it would be rejected because of the load placed on upper levels of the DNS hierarchy.

But when mulling the PSD problem with the tree-walk problem, I realized the unifying problem in all of these scenarios was unregistered domains.   Eventually the problem became further defined as, "Why should unregistered domains be considered acceptable by default, despite a network-wide requirement for all domains to be registered."

For the moment, it is a DMARC issue to me because DMARC has accepted the notion that unregistered domains are acceptable by default.   If that can be changed, I agree that there are other documents that need to be updated as well.



From: "Murray S. Kucherawy" <>
Sent: 11/21/20 8:05 PM
To: Doug Foster <>
Cc: "" <>
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

On Sat, Nov 21, 2020 at 5:02 PM Murray S. Kucherawy <> wrote:

On Sat, Nov 21, 2020 at 3:12 PM Douglas E. Foster <> wrote:

- If unregistered domains are tolerated, PSD for DMARC helps address the problem of a unauthorized domains underneath a public suffix, such as "".  But what DMARC policy will solve the problem of an invalid TLD, such as "example.q"?

Why is this a DMARC problem that needs solving?

- If unregistered domains are tolerated, then a limited-scope tree walk becomes unusable.   A spammer would be able to  fabricate a few levels of non-existent subdomains, and suddenly becomes a domain tree with no detectable DMARC policy.

You're going to have to give us an example of what you're imagining here.  Presumably fabricating a few levels of non-existent subdomains of would look like; a simple tree walk then would be to look for records in these places:

I would expect a policy to be present at least at "", so the walk stops there.  How is that "unusable"?

Someone in DNSOP, I think, proposed doing the tree walk in the other direction.  The reason: If you're going to get an NXDOMAIN, it is more likely to come earlier, and it's dispositive that way.  For instance, if the above sequence is reversed, you would probably get an NXDOMAIN at the second query ("") and then you know you don't need to look any further.