Subject: [dmarc-ietf] inheritance and public suffix list

From: Tomki Camp <[email-masked]>
Date: Tue, 3 Apr 2018 12:02:58 -0700

Currently defined policy discovery https://tools.ietf.org/html/
rfc7489#section-6.6.3

This begs the question (for which a real example now exists): what if a
listed suffix (TLD?) itself has a DMARC record?  Is the intent and expected
behaviour that the TLD entry override all instances where a record is not
explicitly defined?  Or should there also be an Organizational level check
along the way?  Or something else?

Current use case:
qld.gov.au is in the PSL, *and* has a DMARC record of its own.  When
looking up whether company.qld.gov.au has a DMARC record, all public tools
I tried say 'no record' except MXtoolbox, which shows that the entry
inherits from qld.gov.au

---

From: Paul Rock <[email-masked]>
Date: Wed, 4 Apr 2018 12:52:53 -0400

Considering that the qld.gov.au record includes an sp tag, I'd say that
they intend and expect that the TLD entry does exactly that - puts DMARC
reporting in place for all subdomains that don't have their own record.

On Tue, Apr 3, 2018 at 3:02 PM, Tomki Camp <tki=[email-masked]>
wrote:

> Currently defined policy discovery https://tools.ietf.org/html/rf
> c7489#section-6.6.3
>
> looking up whether company.qld.gov.au has a DMARC record, all public
> tools I tried say 'no record' except MXtoolbox, which shows that the entry
> inherits from qld.gov.au
>
>
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>
>

-- 
PAUL ROCK
*Sr Software Dev Engineer* | AOL Mail
P: 703-265-5734 | C: 703-980-8380
AIM: paulsrock
22070 Broderick Dr.| Dulles, VA | 20166-9305

---

From: Paul Rock <[email-masked]>
Date: Wed, 4 Apr 2018 12:52:53 -0400

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 4 Apr 2018 10:45:15 -0700

Apologies for the top-posting, but this is exactly the scenario that has
been discussed earlier on the list:
https://www.ietf.org/mail-archive/web/dmarc/current/msg04151.html as well
as during the recent IETF101 meeting:
https://datatracker.ietf.org/doc/minutes-101-dmarc/

The problem really is (at the moment) that there is no basis in the lookup
algorithm to ever query the "last public" domain (aka "org-1"). Would the
community be open to adding a third potential lookup to the algorithm?
   1 - check the domain itself
   2 - check the org domain
   3 - check org-1

--Kurt

On Wed, Apr 4, 2018 at 9:52 AM, Paul Rock <[email-masked]> wrote:

> Considering that the qld.gov..au <http://qld.gov.au> record includes an
> sp tag, I'd say that they intend and expect that the TLD entry does exactly
> that - puts DMARC reporting in place for all subdomains that don't have
> their own record.
>
> On Tue, Apr 3, 2018 at 3:02 PM, Tomki Camp <tki=[email-masked]
> <tki=[email-masked]..org>> wrote:
>
>> looking up whether company.qld.gov.au <http://company.qld.gov..au> has a
>> DMARC record, all public tools I tried say 'no record' except MXtoolbox,
>> which shows that the entry inherits from qld.gov.au
>>
>>
>>

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 4 Apr 2018 10:45:15 -0700

--Kurt

---

From: "Peter M. Goldstein" <[email-masked]>
Date: Wed, 4 Apr 2018 11:19:20 -0700

Kurt,

As you note, this issue has been discussed on-list (and off) a few times.
And it definitely seems clear that some sort of modification to the lookup
algorithm would be required to address the issue.

As part of that discussion, there are a few scenarios that I think should
be considered:

1. *A domain which contains two public suffixes* - i.e. abc.gov.uk, which
contains the public suffixes .gov.uk, .uk.  In the proposed lookup scheme
we'd be assuming that the manager of the registry for the "last"
organizational domain represented a controlling authority that should be
able to impose DMARC policy on and view data for all subdomains.  I'm not
sure whether that's true in all cases, and that would have bearing on your
proposal.

2. *A domain which contains three or more public suffixes* - I'm not sure
given the content of the public suffix list today that you can actually
construct one of these.  But from what I can see, there's nothing
restricting a future update of the public suffix list that would allow such
a domain.  If we update the lookup algorithm, we should at least speak to
this case - even if it's just to say we ignore it.

3. *New gTLDs* - With the recent expansion of the list of TLDs, many of the
new TLDs are controlled by a single organization.  It may make sense to
allow those gTLDs to define a DMARC record on the TLD itself or on some
'default' domain - both for administrative simplification and to ensure
against abuse.  It may be possible to handle this case outside of a lookup
change with wildcarded DNS records, but I know it's something that's come
up in discussions with some of those TLD owners.

I'd suggest that if we're going to make a modification to the lookup
algorithm that we consider each of these scenarios, and ensure there's
consensus on how they should each be addressed.

To your specific question, I think it's desirable to address these cases
and it's worth discussing how the lookup algorithm can be modified to do so.

Best,

Peter

On Wed, Apr 4, 2018 at 10:45 AM, Kurt Andersen (b) <[email-masked]> wrote:

> been discussed earlier on the list: https://www.ietf...org/
> mail-archive/web/dmarc/current/msg04151.html
> <https://www.ietf.org/mail-archive/web/dmarc/current/msg04151.html> as
> well as during the recent IETF101 meeting: https://datatracker.
> ietf.org/doc/minutes-101-dmarc/
>
>> On Tue, Apr 3, 2018 at 3:02 PM, Tomki Camp <tki=[email-masked]
>> g <tki=[email-masked]..org>> wrote:
>>
>>> looking up whether company.qld.gov.au <http://company.qld.gov..au> has
>>> a DMARC record, all public tools I tried say 'no record' except MXtoolbox,

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 4 Apr 2018 11:41:48 -0700

> this case - even if it's just to say we ignore it.

This is quite easily accomplished, as are scenarios where there are public
blocks embedded "down chain" with intervening private domains in between.
See the notes from the DBOUND working group if you want to delve into these
sorts of things.

> and it's worth discussing how the lookup algorithm can be modified to do so.

My opinion is that we should strive for simplicity and attempt to craft a
proposal which would handle both scenarios 1 & 2 in a single mechanism. It
would be even better if we can solve for case #3 with the same solution :-)

--Kurt

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 5 Apr 2018 11:18:08 +0200

On Wed 04/Apr/2018 20:19:20 +0200 Peter M. Goldstein wrote: 
> able to impose DMARC policy on and view data for all subdomains.
Just to clarify, I have:

   $ psl --print-reg-domain mail.abc.gov.uk
   mail.abc.gov.uk: abc.gov.uk

and

   $ psl --print-reg-domain mail.sub.qld.gov.au
   mail.sub.qld.gov.au: sub.qld.gov.au

The method https://tools.ietf.org/html/rfc7489#section-3.2 defines just one
Organizational Domain, so using the term "last" above is pleonastic.  I reckon
psl --print-reg-domain (at least in the above cases) matches that method well.

If that's correct, I don't see how the txt record at _dmarc.qld.gov.au could
ever have a chance of being discovered.

> 3. *New gTLDs* [...]  It may make sense to allow those gTLDs to define a
> DMARC record on the TLD itself or on some 'default' domain - both for
> administrative simplification and to ensure against abuse.
I strongly disagree.  If a domain owner --the target of a delegation, i.e. the
one who controls the relevant subtree-- has to submit to a parent domain policy
which provides for yielding reports about their private mail, then the parent
domain is not a public registry, not in the commonly accepted meaning of the
term "public".  DMARC policies are not akin to abuse mailboxes, are they?

Ale
--

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 5 Apr 2018 09:07:55 -0400

Hi,

On Wed, Apr 04, 2018 at 11:19:20AM -0700, Peter M. Goldstein wrote:

> it definitely seems clear that some sort of modification to the lookup

Right.  We attempted to specify some system that would sort this all
out over in the DBOUND WG, but that WG failed because of disagreement
about whether we cared about web-type (cross-site issues, cookies,
&c.) problems or anti-spam (roughly, "parent's policy wins") issues.

> 1. A domain which contains two public suffixes - i.e. abc.gov.uk, which
> contains the public suffixes .gov.uk, .uk.

> 2. A domain which contains three or more public suffixes - I'm not sure given
> the content of the public suffix list today that you can actually construct one
> of these.

These are both a species of the same problem, yes.  The solution so
far has been to say that you're supposed to match the longest of the
candidate set.  There is a possible hitch because of non-terminals,
which never have any real records in them but that might have
subordinate things that are also public suffixes.  Except for .jp (and
I'm not sure there), I think nobody is doing that any more.  Some of
us argued that the system ought to accommodate such uses anyway, and
others argued that we shouldn't solve any problem nobody has today
(and tell people who later invent this problem, "Don't do that").

> 3. New gTLDs - With the recent expansion of the list of TLDs, many of the new
> TLDs are controlled by a single organization.  It may make sense to allow those
> gTLDs to define a DMARC record on the TLD itself or on some 'default' domain -
> both for administrative simplification and to ensure against abuse.

Do you mean this _across_ TLDs (e.g. the "variants" case such as
differnet spellings of China depending on the writing system) or do
you just mean that the top most label and everything flowing down from
there is all under the same policy?

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Peter M. Goldstein" <[email-masked]>
Date: Thu, 5 Apr 2018 07:22:37 -0700

Hi,

> candidate set...

Right.  And the suggestion that Kurt made was to modify this to:

1. Check the domain itself
2. Check the longest of the organizational domain candidate set
3. Check the shortest of the organizational domain candidate set

Which covers the case where that candidate set has cardinality 2 or less,
but leaves some question about cases where the cardinality is 3 or more.  I
don't know how common the latter is - not sure if we have stats on that.

> there is all under the same policy?

The latter.

To be more clear, there are now a significant number of TLDs that are
managed exclusively by one entity (e.g. .microsoft, .google) as well as
other TLDs that make specific guarantees around DMARC (e.g. .bank). In
those cases it may make sense to give the registry owners some defined
mechanism for imposing global DMARC policy across the TLD.  This is
especially important for organizational domain names that don't resolve for
that TLD.

So, for example, let's consider an email seemingly sent from
[email-masked] .  A query to the domain iamareal.bank returns an
NXDOMAIN, as does the a TXT query to the corresponding DMARC record
_dmarc.iamareal.bank domain.  So there's no DMARC policy in place.  So a
receiver may wind up delivering this email to the inbox, especially if it
passes SPF and DKIM in an unaligned fashion.

But to an end user it looks like this is an email from a '.bank' domain,
which undermines the .bank TLDs goal of providing a higher trust set of
domains.  And it is therefore attractive to bad actors as a possible
channel of abuse.

The question is whether the DMARC lookup scheme should somehow address this
issue.  Alternately, we could simply say that this is a case that DMARC
itself doesn't handle, and that the registry owner may choose to modify
their DNS responses to ensure they always return a DMARC record for any
organizational domain on that TLD.

Best,

Peter

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Thu, 5 Apr 2018 08:19:10 -0700

> 3. Check the shortest of the organizational domain candidate set

Not quite. Steps 2 & 3 would be (adapted from the language of the DMARC
spec itself):

2.  (from 3.2 step 3) "search the PSL for the name that matches the largest
number of labels found in the subject DNS domain. Let that number be "x". /
(step 4) Construct a new DNS domain name using the name matched form the
PSL and prefixing to it the "x+1"th label"...[this] is the org domain.

3. Check the name created from the "x" labels determined in step 2 (hence
my designation as "org-1").

These are not the same as "longest" and "shortest" names from the org
domain candidate set unless the psl code follows that specified
construction algorithm.

> don't know how common the latter is - not sure if we have stats on that.

I still don't know why the cardinality matters with the approach I've
proposed.

> support@iamareal..bank .  A query to the domain iamareal.bank returns an

If .bank, i.e. "1", is the largest number of labels found in the PSL (step
2), why would this approach not protect NXDOMAINs under .bank?

--Kurt

---

From: "Peter M. Goldstein" <[email-masked]>
Date: Thu, 5 Apr 2018 08:46:06 -0700

Kurt,

> spec itself):
> 2.  (from 3.2 step 3) "search the PSL for the name that matches the
> largest number of labels found in the subject DNS domain. Let that number
> be "x". / (step 4) Construct a new DNS domain name using the name matched
> form the PSL and prefixing to it the "x+1"th label"...[this] is the org
> domain.

Ah, I misunderstood the proposal.  I viewed your '-1' as subtracting an
index against the PSL set, not subtracting an actual label from the
organizational domain.

I'm also a little confused by terminology - "org-1" above is just the
largest number of labels entry on the PSL, isn't it?

In that case, yes it would address point #3, but would also potentially
introduce problems for the county code TLDs (does a country-level registrar
have the right to dictate policy for all domains in the country?) and some
of the non-sponsored generics (.com, .edu, .org, etc.)

The cardinality is still a potential issue, because you may want the DMARC
management to devolve to the most general authority in the tree.  But as I
said, it's easy enough to state "DMARC doesn't handle that case" if it's
not an effective abuse vector or a significant management problem.

Best,

Peter

On Thu, Apr 5, 2018 at 8:19 AM, Kurt Andersen (b) <[email-masked]> wrote:

> 2.  (from 3.2 step 3) "search the PSL for the name that matches the
> largest number of labels found in the subject DNS domain. Let that number
> be "x". / (step 4) Construct a new DNS domain name using the name matched
> form the PSL and prefixing to it the "x+1"th label"...[this] is the org
> domain.
>

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 5 Apr 2018 19:35:24 +0200

On Thu 05/Apr/2018 17:19:10 +0200 Kurt Andersen (b) wrote: 
> On Thu, Apr 5, 2018 at 7:22 AM, Peter M. Goldstein wrote:
> 
>>> Hi,
>>>

FWIW, here's the wording of the PSL(1) man page:

       --print-unreg-domain
              Returned data: the longest public suffix part for each domain.

       --print-reg-domain
              Returned data: the shortest private suffix part for each domain.

[...]
COPYRIGHT
       libpsl and `psl' are copyright © 2014-2016 Tim Ruehsen  under  an  MIT-
       style License.
       This  documentation  was  written by Daniel Kahn Gillmor for the Debian
       project, but may be used by others under the  same  license  as  libpsl
       itself.

psl 0.13.0                         July 2016                            PSL(1)

--

---

From: "Luis E. Muñoz" <[email-masked]>
Date: Thu, 05 Apr 2018 10:51:18 -0700

> up in discussions with some of those TLD owners.

Keep in mind that gTLD operators are restricted in the records they can 
include in their respective DNS zones. This would require the use of a 
well known name specifically for this purpose.

Best regards

Luis Muñoz
Director, Registry Operations
____________________________

http://www.uniregistry.link/
2161 San Joaquin Hills Road
Newport Beach, CA 92660
[email-masked]

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 5 Apr 2018 20:04:55 +0000

I think _dmarc as a TXT record is fairly well known. Is there anything that would specifically prohibit this?

Mike

From: dmarc [mailto:[email-masked]] On Behalf Of Luis E. Muñoz
Sent: Thursday, April 05, 2018 1:51 PM
To: Peter M. Goldstein
Cc: dmarc; Kurt Andersen
Subject: Re: [dmarc-ietf] inheritance and public suffix list

Keep in mind that gTLD operators are restricted in the records they can include in their respective DNS zones. This would require the use of a well known name specifically for this purpose.

Best regards

Luis Muñoz

________________________________

http://www.uniregistry.link/<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.uniregistry.link_&d=DwMFaQ&c=x7B6bjj-lbW7-A5duSwtVZBwdPVsIEJbxl96ul0HiXQ&r=Jb3AiMhkpw4bVAHnghD5VA&m=-tBem26AjT5N4-O1DbHfhq51zJqAv0EDsKdUwHbm7LQ&s=j88Q0-8mw50P1w-IenC0ZYww-HjK1CcHxKlYPvMeI2I&e=>
2161 San Joaquin Hills Road
Newport Beach, CA 92660
[email-masked]<mailto:[email-masked]>

---

From: "Luis E. Muñoz" <[email-masked]>
Date: Thu, 05 Apr 2018 13:06:30 -0700

> that would specifically prohibit this?

gTLDs are not permitted to place TXT records in their zones.

Luis Muñoz

Office +1 949 706 2300 x 4242
[email-masked]

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Thu, 5 Apr 2018 13:58:48 -0700

> gTLDs are not permitted to place TXT records in their zones.
That seems like a regrettable limitation. Would we need further definition
around the "well known" aspect from IETF to fix this or would it require
ICANN-level changes to contractual terms?

--Kurt

---

From: "Luis E. Muñoz" <[email-masked]>
Date: Thu, 05 Apr 2018 14:03:59 -0700

> ICANN-level changes to contractual terms?

Contractual changes. This is the relevant text from 
https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html

		1.1.   For the “Internet” (IN) Class:

		1.1.1.   Apex SOA record

		1.1.2.   Apex NS records and in-bailiwick glue for the TLD’s DNS 
servers

		1.1.3.   NS records and in-bailiwick glue for DNS servers of 
registered names in the TLD

		1.1.4.   DS records for registered names in the TLD

		1.1.5.   Records associated with signing the TLD zone (e.g., RRSIG, 
DNSKEY, NSEC, NSEC3PARAM and NSEC3)

		1.1.6.   Apex TXT record for zone versioning purposes

		1.1.7.   Apex TYPE65534 record for automatic dnssec signing signaling

		1.2.   For the “Chaos” (CH) Class:

		1.2.1.   TXT records for server version/identification (e.g., TXT 
records for “version.bind.”, “id.server.”, “authors.bind” 
and/or “hostname.bind.”)

Luis Muñoz

---

From: Zeke Hendrickson <[email-masked]>
Date: Thu, 5 Apr 2018 22:54:05 +0000

> organizational domain on that TLD.
 
My initial thought was that handling this in DMARC would be
unnecessary, since mail from nonexistent domains can be rejected
without needing an opt-in compliance record. However, that
thought completely neglected the "R" portion of DMARC, and I can
certainly see how including attempts from nonexistent domains in
aggregate reports would be useful. Further, while the requirement
that RFC5321.MailFrom domains be resolvable is codified in
section 2.3.5 of that RFC, a similar explicit requirement for the
RFC5322.From address was deliberately removed from the DMARC spec (see
https://tools.ietf.org/html/rfc7489#appendix-A.4).

Absent a better way to determine domain ownership boundaries than the
current heuristic, I don't think the resolution for domains that exist
should be altered. Domains should retain the ability to opt out of
DMARC by not publishing a DMARC record, rather than being unexpectedly
affected by one that their TLD or other public suffix has chosen to
publish. Requiring that pseudo-public suffixes like .google publish
DMARC records for their valid Organizational Domains doesn't seem
onerous.

I would suggest that if there's no policy found for the two domains
that are currently checked, the receiver should attempt to resolve
those domains (checking for MX or address records, or a CNAME that
points to a name with MX or address records), and only if they cannot
be resolved move on to querying the name that matched from the public
suffix list. This represents a significant increase in the number of
DNS queries required to process a nonexistent domain, but I think it's
the best balance between retaining the opt-in nature of DMARC and
allowing public suffixes to publish DMARC policies for nonexistent
domains in their namespace.

-- 
Zeke Hendrickson ([email-masked])
University of Michigan | Information and Technology Services 
Infrastructure | Application Operations | Application Delivery Support

---

From: "John Levine" <[email-masked]>
Date: 10 Apr 2018 12:19:31 -0400

>gTLDs are not permitted to place TXT records in their zones.

That's mostly right.  There is detailed language in the registry contracts about
what's allowed in the TLD zones, dating back to the sitefinder fiasco
when Verisign put a *.com wildcard in the .com zone.  

See Exhibit A in the Base Registry Agreement:

https://www.icann.org/resources/pages/registries/registries-agreements-en

TLDs are allowed to put in txt records for zone status.  See, for example,
the TXT records at __zone_status.sharp or at total.

I doubt that anyone would object to a _dmarc.<tld> TXT record, but
it's debatable whether it would qualify as zone status.  Otherwise the
registry would have to make an RSEP request to ICANN for permission to
do so, which is expensive and slow.

https://www.icann.org/resources/pages/rsep-2014-02-19-en

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 10 Apr 2018 16:44:17 -0400

In article <[email-masked]> you write:
>Contractual changes.

Not really.

 This is the relevant text from 
>https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html

But the paragraph at the end of that section, Exhibit A, says:

 If Registry Operator wishes to place any DNS resource record type or
 class into its TLD DNS service (other than those listed in Sections
 1.1 or 1.2 above), it must describe in detail its proposal and submit
 a Registry Services Evaluation Process (RSEP) request.  This will be
 evaluated per RSEP to determine whether the service would create a
 risk of a meaningful adverse impact on security or stability of the
 DNS.  Registry Operator recognizes and acknowledges that a service
 based on the use of less-common DNS resource records and/or classes in
 the TLD zone, even if approved, might not work as intended for all
 users due to lack of software support.

Registries make RSEP requests all the time.  They're tedious and fairly
expensive, but the process is straightforward.

R's,
John

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 10 Apr 2018 13:54:50 -0700

On Tue, Apr 10, 2018 at 1:44 PM, John Levine <[email-masked]> wrote:

> >https://newgtlds.icann.org/sites/default/files/
> agreements/agreement-approved-31jul17-en.html
>

Is this something that could be within the remit of the dmarc-wg if we
wanted to pave the way with ICANN across the board?

--Kurt

---

From: "John R Levine" <[email-masked]>
Date: 10 Apr 2018 18:44:14 -0400

> wanted to pave the way with ICANN across the board?

I believe that RSEPs have to be one registry at a time.  The registry 
can apply for all of its domains.  If we wanted it to apply to everyone, 
that would be a contract change.

On the other hand, few of the private TLDs are used much, and I see very 
little mail from any of them, real or otherwise, so it doesn't seem super 
urgent.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly