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) <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 >>> >>> >> >> >> -- >> 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 >> >> _______________________________________________ >> 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
