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

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.



On Wed, Apr 4, 2018 at 10:45 AM, Kurt Andersen (b) <kb...@drkurt.com> wrote:

> 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
> <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 <paul.r...@teamaol.com> 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=40tomki....@dmarc.ietf.or
>> g <tki=40tomki....@dmarc.ietf..org>> wrote:
>>> Currently defined policy discovery https://tools.ietf.org/html/rf
>>> c7489#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 <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
>>> _______________________________________________
>>> dmarc mailing list
>>> dmarc@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dmarc
>> --
>> *Sr Software Dev Engineer* | AOL Mail
>> P: 703-265-5734 | C: 703-980-8380
>> AIM: paulsrock
>> 22070 Broderick Dr.| Dulles, VA | 20166-9305
>> _______________________________________________
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
dmarc mailing list

Reply via email to