Hi Ben, Thank you, I think the source of confusion is that the draft-00 is attempting to describe how the Policy Domain is derived rather than requiring it to be externally configured.
The intended model is not that the user agent receives a Policy Domain through an out-of-band configuration channel. Where a registrable domain boundary exists, the user agent derives the Policy Domain from that boundary and performs discovery beneath it. For example, content served from www.example.com, shop.example.com, and portal.example.com would all result in policy discovery under _csp.example.com. The objective is that a domain operator can publish a single csp reporting policy for the namespace they administer, rather than requiring separate configuration on every individual fqdn. The current wording may not make that sufficiently clear, for this, I apologise. Re-reading it back now, where the text discusses deployment-sensitive behaviour and implementation-defined considerations. I will revisit that section to make the intended discovery process more explicit. Thank you for picking up on this Ben. Regards, Simon Jackson Alltime Technologies Ltd -----Original Message----- From: Ben Schwartz <[email protected]> Sent: 31 August 2026 20:14 To: Simon Jackson <[email protected]> Cc: Simon Jackson <[email protected]>; [email protected]; [email protected] Subject: Re: [DNSOP] Re: Seeking review: draft-jackson-csp-reporting-policy-00 [You don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] 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]
