Re: [dmarc-ietf] org domain and dns-perimeter draft

Doug Foster <> Tue, 24 November 2020 18:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 097203A0930 for <>; Tue, 24 Nov 2020 10:18:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=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 ayzpj236S73P for <>; Tue, 24 Nov 2020 10:18:10 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BD13B3A0880 for <>; Tue, 24 Nov 2020 10:18:10 -0800 (PST)
X-ASG-Debug-ID: 1606241887-11fa313c014d030001-K2EkT1
Received: from ( []) by with ESMTP id 9zfNu4gTYEie5OrB (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for <>; Tue, 24 Nov 2020 13:18:07 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1025; h=message-id:subject:to:from; bh=fpKL18yL2No17rnHrewEaB1doFGZLn7dZTnL//Eq64w=; b=AGVsrEgIFKbN1ZK3aXNJsDwdvTGitzBQR8xys0k2EalEan5PjUUE+27HnTvojFaQA NQnNP3KtgFDyiyW8FQMw5H3C9NWjnL/4jJCKOLbdVipb0gisgh9WqRvIlSH/YPbOA iswd8SUDfSO7ZsnxoDp83r/aWV5+b1+u7raNHcuzw=
Received: from MSA189 (UnknownHost []) by with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Tue, 24 Nov 2020 13:17:58 -0500
From: "Doug Foster" <>
To: "'IETF DMARC WG'" <>
References: <>
In-Reply-To: <>
Date: Tue, 24 Nov 2020 13:17:59 -0500
X-ASG-Orig-Subj: RE: [dmarc-ietf] org domain and dns-perimeter draft
Message-ID: <00a301d6c28e$23adddf0$6b0999d0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQL2Inrsj+hkDBhutDtDqei8L1UW9aeYz32Q
Content-Language: en-us
X-Exim-Id: 00a301d6c28e$23adddf0$6b0999d0$
X-Barracuda-Start-Time: 1606241887
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Barracuda-BRTS-Status: 1
X-Virus-Scanned: by bsmtpd at
X-Barracuda-Scan-Msg-Size: 3915
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=
X-Barracuda-Spam-Report: Code version 3.2, rules version Rule breakdown below pts rule name description ---- ---------------------- --------------------------------------------------
Archived-At: <>
Subject: Re: [dmarc-ietf] org domain and dns-perimeter draft
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: Tue, 24 Nov 2020 18:18:13 -0000

I am intrigued by Dave's document.   I have not yet read John's.   John
described this topic as a battle, so I wonder if we need a crash course in
the results of those battles before revisiting the topic.

One of the issues that did not seem sufficiently addressed was split-mode
nodes, where some descendants are public suffixes and some are
organizations.    At that point, the plan becomes dependent on organizations
publishing BEGIN records.     Similarly, if we ask PSL's to put a flag into
their DNS entries, we have to assume that some will comply and some will
not, and some will do so in phases.   TThe document did not provide a
mechanism for the evaluator to assess whether data is complete or missing.
I am attempting to fix those concerns.

Nonetheless, these thoughts are an abstraction inspired from Dave's

Note:  I only know how to make this work if we assume a tree walk that goes

At each public suffix entry in the DNS hierarchy, we check for these flags:
Public suffix flag:  This is a PSL entry, it neither sends nor accepts
email.  You must look for an organization start somewhere below this point.

(Optional)  End flag:  There are no public suffixes below this point.  Every
lower entry is an organization start node.   Entries with a public suffix
flag are stating an organization preference or spoofing.

Deployment flag:   All public suffixes below this point have been tagged.   
- Once this flag is detected, if the search finds a node without the PSL
flag, it is an organization, not a public suffix 
- If this flag has not been detected and the search finds a node without the
PSL flag, use the old PSL to find the organization node.

An evaluator can walk down the tree and can always find one of these:
- an Organization entry, 
- an ambiguous ending which triggers the need to consult the old PSL, or 
- an excessive search depth which is handled as no-data-found and possible
malicious intent.

Spoofing assessment:
We cannot prevent people from mimicking a PSL flag, so we just need to limit
the risk.

As the tree is walked downward, the first entry without a PSL flag stops the
search.    The PSL flag should never be checked based on a walk up the tree.
This eliminates the opportunity for mid-tree spoofing.

I see no great risk if an organization wants the top of its DNS structure to
behave like a public suffix, so I don't know that mimicking a public suffix
is a problem.   The only caveat is that we need a maximum depth to limit
malicious DNS structures intended to waste search effort by evaluators.

Doug Foster

-----Original Message-----
From: dmarc [] On Behalf Of Dave Crocker
Sent: Wednesday, November 18, 2020 12:55 PM
Subject: [dmarc-ietf] org domain and dns-perimeter draft

Given the renewed discussion about organizational domain and alternative
boundaries, I'll suggest that this draft from last year might be relevant:

    DNS Perimeter Overlay


> Abstract
>    The Domain Name System (DNS) naming syntax provides no meta-data for
>    indicating administrative transitions through the hierarchy.  For
>    example, it does not distinguish the higher-level portions that
>    operate as public registries, versus those that operate as private
>    organizations.  This specification creates a basic overlay mechanism
>    for defining a logical Perimeter between administrative entities
>    through the naming hierarchy.  The mechanism can then be applied for
>    a variety of independent administrative indications.

Dave Crocker
Brandenburg InternetWorking

dmarc mailing list