Barry challenged me to provide specific text needed to address my concerns
with the current draft.. The changes are significant. My first pass
appears below/ I have not yet tried to create a full XML draft yet, but
wanted to get the changes introduced.
Key changes
1) Added definitions.
2) Added an explanation of why the DNS Tree Walk is needed to replace the
PSL.
3) Made clear that the purpose of the DNS Tree Walk is to give domain
owners the ability to explicitly specify and control their domain
boundaries. Encouraged domain owners to tag their policies explicitly.
4) Defined the domain owner actions needed to make the DNS Tree Walk
accurate.
5) Defined two usage modes for the DNS Tree Walk:
- Full Transition, based on trusting that domain owner actions have been
implemented to make the Tree Walk accurate.
- Parallel Operation, based on not trusting that domain owner actions have
been implemented. This could also be called "Skeptic Mode"
6) Added the SubOrgs tag to provide all of the information needed for
Parallel Operation mode to trust the Tree Walk result, while also improving
efficiency of Full Transition mode. Values are:
SubOrgs=N (No private registries in the subtree) and
SubOrgs=Y (Private Registries exist but are tagged.)
7) Evaded the token naming discussion by using the following placeholders:
(RegistryDomain) for what has been called psd=y
(OrgDomain) for what has been called psd=n
(SingleDomain) for a modified use of what has been called psd=u
These three options are mutually exclusive
8) Structured the Tree Walk description based on process flow, to promote
consistent implementations and to ensure that discussed details are fully
documented in the appropriate context.
Doug Foster
The text:
-----------
3.2.12 Private Registry Domains
Some PSO-Registered domain owners offer the use of their subtree for
unaffiliated organizations. This has the effect of creating two
organization boundaries within ansingle DNS path, one between the Registry
provider and its clients, and another between the registry provider and its
Public Suffix Domain. This has implications for the new Tree Walk Process
3.2.13 Registry Domains
A term used to indicate Public Suffix Domains and Private Registry Domains
collectively.
3.2.14 Partitioned Domain Boundary
An organizational subunit which publishes its own organizational domain
policy record, typically to limit the scope of relaxed authentication to
within that subunit. This capability is created by the Tree Walk Process,
and will not be recognized by evaluators that operate based on RFC 7489.
4.6 DNS Tree Walk Process
The DMARC protocol defines a method for communicating information through
the publishing of records in DNS. Both the content of the records and their
location in the DNS hierarchy are used for several purposes: Alignment
method, suggested disposition on failure, Organizational Domain for relaxed
alignment, and reporting destination.
RFC 7489 relies on an externally-managed list to define all Registry
Domains, on the implied assumption that it will be authoritative and
complete. In practice, no external list can be authoritative, because any
domain owner can create a Private Registry within its subtree without
consulting an external authority. Additionally, that PSL is optimized for
a different purpose than email, and as a result some entries produce
unwanted results for DMARC. When a problem occurs, the domain owner may
have difficulty corrected and will definitely have trouble getting the
correction propagated to all evaluators. Consequently, a different
algorithm is needed, one that gives domain owners the ability to explicitly
define their organizational boundaries using DMARC policy tokens. The
replacement algorithm is the DNS Tree Walk.
Evaluators can use the DNS Tree Walk in one of two modes, Full Transitional
and Parallel Operation. These modes are described in section 4.8
The DNS Tree Walk Process involves multiple phases: Identifier
Verification (section 4.6.1), exact-match policy and identifier evaluation
(section 4.6.2), organization domain and default policy Search (section
4.6.3), and alignment verification (section 4.6.4). Evaluators using
Parallel Operation will sometimes perform the PSL Cross-Check phase.
4.6.1 Identifier verification
All SPF and DKIM identifiers are tested. Any that do not verify are
discarded. The remaining identifiers are separated into two groups:
those that match the RFC5322.From address, and those that do not.
4.6.2 Exact-match Policy and Identifier Evaluation
The DNS is queried for a DMARC TXT policy record matching the RFC5322.From
address domain. SPF and DKIM verified identifiers are also checked for an
exact match with the RFC5322.From address domain.
If an exact-match policy is found:
- If the policy contains a (RegistryDomain) token, alignment is forced to
strict and evaluation depends on the current policy record only.
- If the policy contains a (OrgDomain) token, or the current domain has
only two labels, the current domain and policy are also the organizational
domain and default policy. The Organizational Domain and Default Policy
search is omitted.
- If the policy contains the (SingleDomain) token, the domain owner
explicitly asserts that the correct Organizational Domain is at a higher
level in the hierarchy, and that when found, it will contain an explicit
(OrgDomain) token. The tree walk continues so that the correct
Organizational Domain policy can be found. If a tagged Organizational
Domain policy is not found, the result is PERMERROR and disposition is
determined by local policy. Caching of the current domain and policy is
optional.
- If an exact-match identifier is verified, the result is PASS and the
current policy is used for the reporting destination.
- If an exact-match identifier is not verified and the policy specifies
strict alignment, the result is FAIL.
- if the exact-match policy contains none of the policy-type tokens, the
current domain name and policy are cached as the candidate organizational
domain and default policy. Processing proceeds to the Organizational
Domain and Default Policy Search.relied o
If no exact-match policy is found:
- If an exact-match identifier is verified, the result is PASS, but the
Organizational Domain and Default Policy Search is used to determine the
reporting destination.
- Otherwise, the Organizational Domain and Default Policy search is used
to determine both the default policy and the Organizational Domain.
4.6.3 Organizational Domain and Default Policy Search
At each iteration, the RFC5322.From domain is shortened by removing the
left-most label, then checking for a DMARC TXT record at the _dmarc.
subdomain of that domain. Upon initiation, if the exact-match domain has
more than 6 labels, then multiple labels are removed so that the initial
search domain has only 5 labels.
- If a policy is found and it includes a (OrgDomain) token, the search
ends. The current domain is the Organizational Domain and the current
policy is the default policy.
- If a policy is found and it includes a (RegistryDomain) token, the search
ends. The previous (one label longer) domain is the Organizational Domain.
- If a DMARC policy was found on the previous domain, it is used as the
Default Policy.
- If the previous domain did not have a DMARC policy, then the Registry
Domain policy is used as the default policy, except that the alignment is
strict for both SPF and DKIM. -If no DMARC policy was found prior to
the Registry policy, the inferred Organizational Domain is tested for
existence, by performing a DNS query on the Organizational Domain name.
If the query returns NXDOMAIN, the organizational domain is not registered
with the registry domain. The recommended action is indicated by the NP
policy of the Registry Domain policy, or in its absence by local policy.
- If a policy is found and it contains a (SingleDomain) token, the domain
owner explicitly asserts that the correct Organizational Domain is at a
higher level in the hierarchy, and that when found, it will contain an
explicit (OrgDomain) token. The tree walk continues so that the correct
Organizational Domain policy can be found. If a tagged Organizational
Domain policy is not found, the result is PERMERROR and disposition is
based on local policy. Caching of the current domain name and policy is
optional.
- If a policy is found and it contains none of the policy-type tags, it
becomes the current domain and policy becomes the candidate organizational
domain and default policy, superseding any previous candidate. The
domain and the policy are cached while the tree walk continues.
- If the current domain is a top-level domain, the walk terminates. If no
candidate organizational domain and policy has been cached, then the result
is NOPOLICY. If a candidate organizational domain and policy have been
cached, then they are used.
- If an exact--match identifier was verified, the result is PASS and the
organizational domain is used for the reporting destination.
- If the default policy specifies strict alignment and an exact-match
identifier was not verified, the result is FAIL.
- If the Organizational Domain and Default Policy search terminates without
a final result, and with a policy that specifies relaxed alignment, then
the process proceeds to Alignment Verification.
4.6.4 Alignment Verification
Upon entry to the Alignment Verification phase, the Organizational Domain
is known, and the verified identifiers are known but do not include an
exact-match. The set of verified identifiers are filtered as follows:
- If either authentication method is specified to use strict alignment,
those verified identifiers are discarded.
- If any verified identifiers are not equal to, or a child of, the
organizational domain, then they cannot be aligned and are excluded.
- If the organizational domain policy explicitly specifies the (SubOrgs=N)
token, then the domain owner asserts that no additional organization
boundaries exist in its subtree, and the Alignment Verification Tree walk
can be omitted. All of the remaining identifiers satisfy relaxed alignment.
- If the organizational domain policy explicitly specifies (SubOrgs=Y),
then the domain owner asserts that its subtree may contain organzational
boundaries, but that these will all be explicitly tagged with (OrgDomain)
or (RegistryDomain) tokens. The tree walk is performed for each verified
identifier that has not been discarded.
- If the organizational domain policy does not contain a SubOrgs tag, the
Alignment Verification Tree Walk is performed. If alignment is confirmed
and the evaluator is using Parallel operation mode, the PSL is also checked
(section 4.8.2).
4.6.4.1 Alignment Verification Tree Walk
At each iteration, the Alignment Verification Tree Walk checks for a DMARC
policy that is explicitly tagged with either (OrgDomain) or
(RegistryDomain) token. If one is found, the walk terminates, the
verified identifier is not aligned, and the process moves to the next
available verified identifier. The walk begins by checking the exact-match
domain for the verified identifier. If the walk continues and the
exact-match domain is longer than 6 labels, then the domain name has
multiple labels removed until it is shortened to 5 labels. Otherwise, one
label is removed and the process repeats.
If the Organizational Domain is reached without alignment being rejected,
then alignment is confirmed. The result is PASS. Additional identifiers
do not need to be checked.
If all identifiers are tested but none are found to be in alignment, the
result is FAIL.
4.6.5 Mandatory Strict Alignment for Registry Domain policies
When a Registry Domain policy is applied to the Registry domain itself,
strict alignment is mandated for these reasons:
- PSDs are above the organizational structure, so relaxed alignment is not
applicable.
- Many Private Registry Domains are implemented on an Organizational
Domain, where one domain is both the PSO-registered name for the
organization and the registration points for clients, so relaxed alignment
is also not applicable.
- Any other Private Registry Domains are given this limitation so that
consistent tagging can be used for all Registry Domains.
When a Registry Domain policy is applied to a client organization, strict
alignment is mandated for these reasons:
- The Registry Domain generally lacks detailed information about the
administrative controls of all clients, so relaxed authentication may not
be appropriate.
- The Registry Domain generally lacks detailed information about the
presence or absence of Private Registries within each client's subtree.
4.7 Domain Owner Responsibilities
To ensure accuracy of the Tree Walk Process:
- PSDS that publish DMARC policies MUST include the (RegistryDomain) token,
and policy must be applied to PSD leaf nodes first. Otherwise, the
algorithm could choose an incorrect organizational domain for relaxed
alignment.
- Domain Owners that operate Private Registries MUST ensure that the
Private Registry Domain is tagged with a (RegistryDomain). If this is
missing, the tree walk may select a higher-level domain as the
Organizational Domain, causing relaxed alignment to use the wrong scope.
- Domain Owners MUST ensure that a DMARC policy exists on the
organizational domain, to ensure that the correct domain is used for
relaxed alignment. This configuration is expected for most organizations
that have implemented DMARC based on RFC 7489, but it was not absolutely
required, so a few domain owners made need to add a policy for compliance
with this specification.
- To improve evaluator efficiency, domain owners SHOULD explicitly tag
organization domain policies with the (OrgDomain) token and the appropriate
(SubOrgs) token.
4.8 DNS Tree Walk Usage Modes
4.8.1 Full Transition
The evaluator assumes that domain owners have complied with the
requirements of section 4.7. Based on this trust, the result of the DNS
Tree Walk Process is final.
4.8.2 Parallel Operation
The evaluator assumes that some domain owners have not complied with the
requirements of section 4.7, and therefore the DNS Tree walk may return
false PASS results in specific circumstances, which are:
- the result is PASS
- the result relies on relaxed authentication, and
- the result relies on an organizational domain policy that was not
explicitly tagged with both (OrgDomain) and (SubOrgs) tokens.
When these conditions are met, the evaluator also uses the PSL to produce a
result based on RFC 7489. If the PSL result is also PASS, the DNS Tree
Walk result is confirmed as PASS. If the PSL result is not PASS, the DMARC
result is AMBIGUOUS. There is no automated method for choosing which
result is more correct. Evaluators are encouraged to perform manual
review and then configure a local policy to override the AMBUIGUOUS result
on future messages.
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
