Similarly, subdomainNEL policies are limited, and can only be used to generate reports about subdomains of the policy origin during the DNS resolution phase of a request. During this phase, there is no server to verify ownership of, and the fact that the policy was received from a superdomain of the request's origin is enough to establish ownership of the error. This allows the owners of a particular portion of the domain namespace tree to use NEL to detect 7.3 DNS misconfiguration errors, while preventing them from using malicious DNS entries to collect information about servers they don't control.
And this is supposed to be enforced by step 8 of Generate a Network Error Report:
If origin is not equal to policy's origin, policy's subdomains flag is include, and report body's phase property is not dns, return null.
However, the preceding step 7 could turn any request's report, including success reports, into DNS failure reports, if the server IP is different than the original IP the policy was received from. In that case, the success would be masked as a DNS failure, but would then pass through the filter of step 8 and be sent anyway.
This should probably be fixed. Either steps 7 and 8 should be swapped, or else step 8 should begin with an "Else" to ensure that both steps don't apply to the same report.
The privacy section of the spec reads:
And this is supposed to be enforced by step 8 of Generate a Network Error Report:
However, the preceding step 7 could turn any request's report, including success reports, into DNS failure reports, if the server IP is different than the original IP the policy was received from. In that case, the success would be masked as a DNS failure, but would then pass through the filter of step 8 and be sent anyway.
This should probably be fixed. Either steps 7 and 8 should be swapped, or else step 8 should begin with an "Else" to ensure that both steps don't apply to the same report.