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]
