I'm referring to this paragraph: Determining the applicable Policy Domain is deployment-sensitive. A user agent MUST NOT automatically walk to a public suffix [PUBLIC-SUFFIX]. A user agent SHOULD use the registrable domain boundary where such a concept is available. Implementations MUST take care not to treat public suffixes as Policy Domains.
This seems to imply that the Policy Domain is a mandatory, out of band configuration input. While it is most commonly the registrable domain, the user agent cannot simply assume this. Could you clarify the intended client configuration process? --Ben On Mon, Aug 31, 2026 at 1:55 PM Simon Jackson <[email protected]> wrote: > > > > 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]
