Thanks for the feedback Ben, It explains the justification in the opening brief. Domain/zone holders are not always responsible for all parts of their websites linked to that domain. Example: hubspot, wordpress, their own app, and their own api layer.
YES, a CSP reporting service is required to make use of this csp reporting policy, much the same as the host-header approach. The old way; - the zone holder will likely sign up to a csp reporting service. Then instruct the Wordpress admin, the hubspot admins, and their own developers to ‘inject this CSP reporting header’. Many will make mistakes, or apply the ‘content-security-policy’ instead of the ‘content-security-policy-report-only’.. most of them cause more issues. Before clients report back - and the cycle of continuous CSP directive improvement begins - involving many parties.. This new way: - the zone holder signs up to the same CSP reporting service, and creates one DNS record. Then they see clients report non-compliant CSP directives, right from the start. No need to involve the hubspot admins, or Wordpress admins, nor the developers. The zone holder has complete visibility of their risks. And no client browsers were affected. Zero risk. Hope that clearly explains the benefits as I see it. Simon > On 31 Aug 2026, at 17:28, Ben Schwartz <[email protected]> > wrote: > > It's not clear to me why DNS is useful for this. > > The draft specifies that the applicable Policy Domain is > implementation-defined. That means you must have an out-of-band > configuration channel capable of passing this domain name to the "user > agent". Since we are assuming the existence of such a configuration > channel, why not also assume that it can carry the contents of this > TXT record? That seems simpler and more reliable. > > --Ben > >> On Mon, Aug 31, 2026 at 11:46 AM Simon Jackson >> <[email protected]> wrote: >> >> Hello, I am seeking DNS operational review of the DNS draft publication >> model described in the following individual Internet-Draft: >> draft-jackson-csp-reporting-policy-00 DNS-Published Content Security Policy >> Reporting Policy The draft addresses >> >> Hello, >> >> I am seeking DNS operational review of the DNS draft publication model >> described in the following individual Internet-Draft: >> >> draft-jackson-csp-reporting-policy-00 >> >> DNS-Published Content Security Policy Reporting Policy >> >> The draft addresses an operational problem: in many organisations, the party >> responsible for domain security governance controls DNS, but does not >> consistently control every HTTP service deployed beneath the domain. A >> domain may include legacy applications, SaaS platforms, CMS-hosted sites, >> reverse proxies, CDN edges, and subdomains administered by different teams. >> >> The draft proposes a DNS-published mechanism for declaring one or more >> domain-authorised Content Security Policy reporting endpoints. >> >> The proposal deliberately does not attempt DNS-based CSP enforcement. It >> does not allow DNS to grant CSP permissions, weaken CSP policy, override >> HTTP headers, or alter the disposition of an enforcing or report-only CSP >> policy. It is limited to reporting endpoint discovery and selection. >> >> In environments with distributed application ownership, CSP reporting can be >> inconsistent, absent, or configured reactively. This limits the ability of >> the domain operator to receive useful CSP violation reports across the wider >> estate. >> >> The draft currently proposes publication under: >> `_csp.<Policy-Domain>` >> >> using a TXT record beginning with: >> `v=CSP1` >> >> and defines tags for: >> >> report-uri >> mode >> max_age >> sp >> format >> tag >> contact >> >> >> The two proposed modes are: >> >> fallback: use the DNS-declared reporting endpoint only where the HTTP >> response does not declare a valid reporting endpoint. >> augment: send reports to both the HTTP-declared reporting endpoint and the >> DNS-declared endpoint, subject to user-agent policy, privacy controls, rate >> limiting, and delivery constraints. >> >> I am particularly interested in operational feedback on the following points: >> >> whether DNS publication is a reasonable fit for this problem; >> whether the owner name `_csp` is appropriate, or too broad; >> whether TXT is appropriate for an initial version of the draft, or whether >> an alternative record type should be considered from the outset; >> whether the cache and freshness model is sufficiently clear; >> whether the default subdomain policy is appropriate; >> whether the security and privacy considerations are sufficient; >> whether DNSOP is a suitable venue for discussion, or whether this should be >> routed elsewhere. >> >> I am not asking DNSOP to validate CSP browser behaviour. My immediate goal >> is to determine whether the publication model is operationally sound and >> worth pursuing further. >> >> Regards, >> >> Simon Jackson >> Alltime Technologies Ltd >> _______________________________________________ >> DNSOP mailing list -- [email protected] >> To unsubscribe send an email to [email protected] > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
