Hi Ben, Thank you. These are useful points to consider.
I do want to push back on the HTTPS/SVCB point. My draft is not trying to solve CSP reporting for a single well-controlled service. CSP already has service-level HTTP headers for that. The gap I am trying to address is domain-level visibility. In practice, the domain operator is often held accountable for security across the namespace, but may not have administrative control over every web service beneath it. Those services may sit across SaaS platforms, CMSs, CDNs, reverse proxies, legacy applications, and separate internal teams. Inserting or modifying CSP headers is not always straightforward, or even possible, for the domain operator; that then falls back to become a coordinated activity with the service-operator. The coordination process in the current CSP model is often disjointed. A security team, domain owner, or DNS operator asks for CSP to be addressed. A service-operator (web master) adds a CSP header, but reporting-uri is missing, headers could be inconsistent, or not aligned with the security team’s expectations. Sometimes report-only is confused with enforcement. Sometimes the site breaks for clients entirely, there are no useful reports to explain why, and there is then reluctance to attempt the work again. At small scale that may sound manageable. Across a large estate, it becomes a much harder "governance and visibility problem". The proposed draft suggests a DNS record that gives the domain or zone operator one reporting publication point. They can use a CSP reporting service of their choice, publish the record, and observe what clients are seeing through CSP violation reports. That changes the later service-owner conversation. It becomes specific, evidence-backed, and tied to the domain operator’s stated reporting expectation. That is why I am not convinced HTTPS/SVCB replaces the owner-name model. It moves the declaration back towards the individual service, which is close to the problem CSP already has today. SVCB may help where the service is already well governed, but it does not close the visibility gap across a fragmented namespace for the domain operator. There may be a future discussion around a fuller domain-wide CSP policy, including inherited directives that can be augmented by service-specific CSP headers. That is an interesting direction, but I would keep it out of scope for this draft. This draft is only about reporting endpoint publication and visibility. On the Policy Domain point, no out-of-band configuration channel is intended. If draft-00 implies that, the wording needs to change. I will look at that. On the PSL point, the intent is not to allow unsafe upward walking or to treat public suffixes as Policy Domains. The intent is to define a safe stopping point and fail closed where no safe boundary can be determined. I agree that if default browser behaviour is in scope, browser implementer and web platform input will be needed. I do not think that removes the DNS question, because the core proposal is still about domain-level visibility rather than per-service configuration. Coordinating with web developers on this... Any suggestions on how one might do that? Regards, Simon Jackson Alltime Technologies Ltd -----Original Message----- From: Ben Schwartz <[email protected]> Sent: 01 September 2026 15:32 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 ] OK, thanks. In that case, it sounds like you _do_ want this behavior in ordinary web browsers running in the default configuration. Some further thoughts on that assumption: * You should coordinate (and preferably coauthor) with web browser developers. Without their support, it is hard to imagine this specification becoming useful. * It's not clear from the draft why the PSL is not appropriate. Please clarify why "registrable domain" is the correct boundary. * Placing this information in a DNS records on the "policy domain" is convenient for the domain owner, but inconvenient for the client. Clients may be unwilling or unable to determine the appropriate policy domain, or to perform the TXT query. A better solution might be to include this information in an HTTPS record SvcParam, which the client is likely to be fetching already. --Ben On Mon, Aug 31, 2026 at 6:22 PM Simon Jackson <[email protected]> wrote: > > > > 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 > https://urldefense.com/v3/__http://www.example.com__;!!Bt8RZUm9aw!-DiYMfW-xIPsFn_B8zh0ZCiroEIEWjRfLZelozurlZgfuiCREjtQForI0t8mCSG0kn1yGQ5bv9_vWeq3BVXRHpRW2Q$ > , 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://urld/ > efense.com%2Fv3%2F__https%3A%2F%2Faka.ms%2FLearnAboutSenderIdentificat > ion__%3B!!Bt8RZUm9aw!-DiYMfW-xIPsFn_B8zh0ZCiroEIEWjRfLZelozurlZgfuiCRE > jtQForI0t8mCSG0kn1yGQ5bv9_vWeq3BVX429RogA%24&data=05%7C02%7Csimon.jack > son%40alltimetech.co.uk%7C4d66b2bf862644bc8f4408df0835d201%7C711693f6c > 5f941889bb128b7b49f5e68%7C0%7C0%7C639238699435954907%7CUnknown%7CTWFpb > GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF > OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=V1aFnh4ar0xEEcTWv4nEj > Xw3sWvgkzx1SVOn3OKG6aI%3D&reserved=0 ] > > 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]
