[Strong opinion follows] IMO [from April], determination of a DMARC authority boundary (registrar, PSD+1, private registry (+1), or internal subdomain boundary) should really be done outside of the DMARC standard altogether – a separate DNS lookup not dependent or centered around DMARC, and one flexible enough to respond with indications of various levels of authority. It is useful for decentralizing other queries beyond just DMARC (e.g. determining an appropriate WHOIS TLD for lookup). Unfortunately, here we are at draft 8 of the new DMARC standard and we have nothing to use as a sidecar mechanism.
Is there a driving need to have this in the standard NOW? If PSL is going to be a widely-used fallback for some time, does it give someone time to drive a new tree authority DNS lookup standard? Adding in a specific mechanism to DMARC as essentially a work-around to some edge-case shortcomings with PSLs seems less than efficient or complete. (And feel free to tell me I’m missing something big here…) Failing that, I agree with Doug that the nature of the boundary is somewhat important, that some additional level of detail might be desirable, and that absconding with ‘psd’ to mean something other than an actual PSD will end in tears. ==== On Wednesday, June 8, 2022, Doug Foster wrote: Todd, as you prepare for the next draft, I want to restate my significant concerns with the previous draft and subsequent discussions: 1) Private Registres Private registries are a significant design consideration because they cause a single DNS path to have two organizational boundaries instead of one. This was perhaps minimally important for the PSL-based determination of the organization usedby RFC 7489, but it is certainly very important for the tree walk algorithm. Private Registry or Private Registrar needs to be defined in the initial material. 2) psd=y The PSD acronym only has meaning to those who study this document, and the document defines a PSD as a domain controlled by an ICANN-sanctioned registrar. It is therefore inappropriate and misleading to take this carefully defined term and broadly apply it to both public and private registrars. The term "registrar" is a well understood English term and should be the starting point for implementing this information element. 3) psd=n The use of psd=n implies that "psd" has two states which are mutually exclusive. This is untrue and misleading. In some cases, possibly most, the private registry is a single layer, so that one domain is both the organization domain underneath the PSO registration, and the registration domain above the privately registered clients. Nothing about "psd=n" communicates "organization domain", nor does it expose the complexity of a dual-role domain. The token used to identify an organizational domain should be meaningful to the novice reader. 4) psd=u DMARC policies can play three roles: organization domain policy, single-domain policy, or registrar policy. The problem with documenting a single-domain policy is that if it is true, the tree walk needs to proceed upward as if no information had been provided. However, if it is false and believed, the tree walk could incorrectly proceed into the registrar domain, causing relaxed alignment to incorrectly produce PASS. Consequently, single-domain policies cannot be documented in a way which is trusted and useful, so they must not be tagged at all. I cannot imagine how we can gain respect for our document if it has language which says, "the term psd=u is useless and MUST be ignored, but it is defined so that you can use it anyway." Since the surviving token values are not mutually exclusive, the token definition needs to reflect that situation. A token of the form: role=(registrar,organizationaldomain) will convey the correct information much more effectively than psd=(y|n|u). I recognize that this is wordy and therefore prone to typing errors, so I believe it can and should be shortened. Whatever the choice, the syntax chosen should not mislead. 5) Boundary verification The evaluator needs certainty that the tree walk has not walked across a private registry boundary. For this to happen, the evaluator needs feedback at the stopping point to verify that the organizational domain chosen is the correct one for the domain from which he started. This requires an entry in the organizational domain policy to assert whether the selected organization contains private registrars or not. In most cases, the answer will be "No", but the evaluator cannot be certain unless that "No" is explicit. In the exception case, the selected policy needs to provide information about where the contained private registry boundary occurs, so that the evaluator can correctly distinguish between PASS/FIAL and NO POLICY FOUND. I have proposed solutions to this problem but they have been disparaged without an alternative being offered. We cannot produce a trusted result of PASS using unverifiable assumptions. Doug Foster -- Les
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
