Re: [dmarc-ietf] Lookup Limitations For Public Suffix Domains

Scott Kitterman <> Fri, 30 November 2018 23:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B8189130EE0 for <>; Fri, 30 Nov 2018 15:37:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.b=3640dltS; dkim=pass (2048-bit key) header.b=tDXMUm3x
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dbTiFQDzXbzc for <>; Fri, 30 Nov 2018 15:37:30 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AB6B81274D0 for <>; Fri, 30 Nov 2018 15:37:30 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=201803e; t=1543621049; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=kI/b1jOw+EvriXTN9enAP9iH8waV0b+6MP/m4Cw0WfM=; b=3640dltS114Jwza0CiD2Z6ffCaBo7V37mZjQOcfz4o9XqmnaItaAk9Fl gssbgXe8NB+JknfZD420GHnVeM4NAg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=201803r; t=1543621049; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=kI/b1jOw+EvriXTN9enAP9iH8waV0b+6MP/m4Cw0WfM=; b=tDXMUm3xG/3no4pLkgloNdNTZj28IXMub6TrYtS4zhN4UsS8RAmF9jme R7sIgNW6+gDsIDsgYbfiQITUaKuEpxk3KVx5hJY89nRGz4bUZUrJ6+3dcx SfWKWa67HwQ17bcSQ9OKUPS057xCaUIO7p2ZP/2TmFGKEZLckTfwQBkg01 l1KPvE3UCbZnNBP0qASb+1BNH/GkK9CNYAAR2gI2IWY5/snnSYI+rw+KSP 9N1EhjHPVVO9wDoxUFW6Ld1cbqga0Cebr1w7H0gjYMe0jEf26EJqpbRYZB qVO6Tp0WxhpIH5ogARyj5ECPUpgwaOs43m0CeCJFlUVc/0j5CIf3fg==
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 14AF8C4027E; Fri, 30 Nov 2018 17:37:29 -0600 (CST)
Date: Fri, 30 Nov 2018 23:37:24 +0000
In-Reply-To: <>
References: <3881693.rR9BVk4Dlq@kitterma-e6430> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Scott Kitterman <>
Message-ID: <>
Archived-At: <>
Subject: Re: [dmarc-ietf] Lookup Limitations For Public Suffix Domains
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: Fri, 30 Nov 2018 23:37:33 -0000

On November 30, 2018 9:40:33 PM UTC, Zeke Hendrickson <> wrote:
>On Wed, Nov 21, 2018 at 02:37:19AM -0500, Scott Kitterman wrote:
>> While we were discussing making draft-kitterman-dmarc-psd a working
>> item, the main discussion point was about the use of an IANA registry
>> identify participating public suffix domains.  I think it would be
>useful to 
>> consider what problems we were trying to solve and see if there are 
>> alternative approaches that address those requirements.
>> Goals:
>> 1.  Minimize additional verifier burden for adding PSD DMARC support.
>> Currently it requires consulting a locally stored, infrequently
>changing list 
>> and one additional DNS lookup only for participating public suffixes
>> there is no organizational domain DMARC record.
>> 2.  Externalize signaling about PSD participation.  As discussed in
>> Privacy Considerations (section 4.1), we were concerned about the
>> implications of feedback on organizational domain traffic for
>> domains that don't participate in DMARC being inappropriately
>captured by 
>> public suffix operators.  In order to avoid this, we identified
>criteria for 
>> which public suffixes PSD DMARC would be appropriate for and require
>> external review to ensure those criteria are met.  No solution that's
>in DNS 
>> will address this part of the problem.
>I feel that restricting the additional PSD check to nonexistent
>organizational domains is the best approach, as it preserves the
>opt-in nature of DMARC, limits privacy concerns, remains very
>straightforward to implement as a verifier, and does not rely on an
>additional list.

RFC 7489 (DMARC) Appendix A.4 mentions that a domain existence test was tried and abandoned as unreliable.  Before reconsidering that kind of approach, it would be important to understand the limitations that caused it to be discarded before.

As Kurt mentioned, I don't think it solves the registry problem in any case because I don't think wide open TLDs like .com ought to be stimulating feedback on any lower level elements of the DNS tree.

>draft-ietf-dmarc-psd-00 addresses a slightly broader problem space,
>but I feel that adding the ability to get feedback on abuse of
>nonexistent domains is the most needed aspect; treating branded PSDs
>as organizational domains would be better addressed by improving the
>way organizational boundaries are determined.

Currently we have no mechanism at all for that, so I'd be reluctant to abandon the use case in favor of a non-existent solution.

Also, I think a formal non-existence test would require additional DNS lookups and might not even be simpler to implement.

Scott K