Individual Submission S. Jackson Internet-Draft Alltime Technologies Ltd Intended status: Experimental June 2026 Expires: 24 December 2026 DNS-Published Content Security Policy Reporting Policy draft-jackson-csp-reporting-policy-00 Abstract This document specifies a mechanism by which a domain operator can publish a Content Security Policy reporting endpoint policy in the Domain Name System. The mechanism allows user agents and reporting processors to discover one or more domain-authorised endpoints for receiving Content Security Policy violation reports, independently of the HTTP response that triggered the report. The mechanism is intended to improve administrative consistency across distributed web estates where the domain operator controls DNS but does not consistently control every web server, content management system, proxy, application stack, or hosting platform serving content beneath the domain. This document does not define DNS-based CSP enforcement. It defines only DNS-published reporting endpoint policy. User agents MUST NOT treat this mechanism as a replacement for the Content-Security-Policy or Content-Security-Policy-Report-Only HTTP response header fields. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 3 December 2026. Jackson Expires 24 December 2026 [Page 1] Internet-Draft CSP Reporting Policy June 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Policy Publication Model . . . . . . . . . . . . . . . . . . 5 7. Owner Name . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. Record Format . . . . . . . . . . . . . . . . . . . . . . . . 6 9. Policy Processing . . . . . . . . . . . . . . . . . . . . . . 8 10. Interaction with HTTP CSP Reporting . . . . . . . . . . . . . 8 11. Endpoint Authorisation . . . . . . . . . . . . . . . . . . . 9 12. Caching and Freshness . . . . . . . . . . . . . . . . . . . . 10 13. Failure Handling . . . . . . . . . . . . . . . . . . . . . . 10 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 15. Security Considerations . . . . . . . . . . . . . . . . . . . 11 16. Operational Considerations . . . . . . . . . . . . . . . . . 12 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13 18.1. Fallback Reporting for a Domain . . . . . . . . . . . . 13 18.2. Augmented Reporting for a Managed Single Website . . . . 13 18.3. Reporting Policy Applying Only to the Policy Domain . . 14 19. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 14 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 20.1. Normative References . . . . . . . . . . . . . . . . . . 15 20.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Rationale . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 Jackson Expires 24 December 2026 [Page 2] Internet-Draft CSP Reporting Policy June 2026 1. Introduction Content Security Policy [CSP] allows an origin to declare restrictions on the resources that a user agent may load and execute. CSP also defines reporting mechanisms by which user agents can send violation reports to an endpoint controlled by the site operator. In many operational environments, the entity responsible for domain security governance is not the same entity that controls every HTTP application server. A single registrable domain may be served by a mixture of content management systems, marketing platforms, SaaS providers, reverse proxies, legacy applications, and third-party hosting environments. Some of these systems may support CSP headers correctly. Others may not. Some may support CSP enforcement but not reporting. Others may overwrite or suppress reporting directives. This creates a governance gap. A domain operator may be responsible for detecting CSP violations across the domain but lack a uniform method to declare the reporting endpoint across all web properties. This document specifies a DNS-published reporting endpoint policy that allows a domain operator to publish a domain-authorised CSP reporting endpoint. The mechanism is intended to complement HTTP CSP headers, not replace them. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Domain Operator: The administrative entity responsible for the DNS zone in which the policy is published. Origin: A tuple of scheme, host, and port as defined by the web platform. Policy Domain: The domain name for which a CSP reporting endpoint policy is published. Reporting Endpoint: An HTTPS URI reference to which CSP violation reports may be sent. HTTP-declared Reporting Endpoint: A reporting endpoint declared by HTTP response metadata, including CSP report-uri, CSP report-to, or the Reporting API [REPORTING] Reporting-Endpoints header field. Jackson Expires 24 December 2026 [Page 3] Internet-Draft CSP Reporting Policy June 2026 User Agent: Software acting on behalf of a user, normally a web browser, that processes CSP policies and generates CSP violation reports. CSP Reporting Endpoint Policy: The DNS-published policy defined by this document. Authoritative Reporting Endpoint: A reporting endpoint that is authorised by the Domain Operator through the mechanism defined by this document. 3. Problem Statement CSP reporting depends on policy material delivered by HTTP response header fields. This creates operational problems where the domain security owner does not control all HTTP responders. Common deployment patterns include: * decentralised web estates with multiple application owners; * legacy web servers that cannot be modified safely; * SaaS platforms that do not expose all response header controls; * reverse proxies and CDNs with inconsistent policy injection; * migration projects where interim reporting is required before full CSP enforcement can be deployed; * acquired domains where DNS has been consolidated but application hosting remains fragmented. In these cases, CSP reporting may be incomplete even when the domain operator has a legitimate security need to collect reports. A DNS-published reporting endpoint policy gives the domain operator a single administrative control plane for declaring where CSP violation reports for the domain may be sent. 4. Design Goals The mechanism specified by this document has the following goals: * allow a domain operator to publish one or more CSP reporting endpoints in DNS; * avoid changing CSP enforcement semantics; Jackson Expires 24 December 2026 [Page 4] Internet-Draft CSP Reporting Policy June 2026 * avoid requiring changes to every web server beneath a domain; * allow gradual deployment by user agents, reporting collectors, and security tools; * support DNS caching behaviour; * support explicit policy expiry and versioning; * provide a clear failure model; * minimise privacy leakage; * avoid creating an unauthenticated channel that weakens existing CSP or reporting behaviour; * align tag names with existing CSP terminology where practical. 5. Non-Goals This document does not define: * CSP enforcement directives in DNS; * a mechanism for DNS to override an HTTP Content-Security-Policy header field; * a mechanism for DNS to weaken an HTTP Content-Security-Policy header field; * a mechanism for DNS to grant script, style, frame, image, connect, or worker permissions; * a replacement for Reporting-Endpoints, report-to, or report-uri; * a telemetry system unrelated to CSP violation reporting; * a mechanism that requires unauthenticated DNS data to be trusted more strongly than authenticated HTTPS response metadata. 6. Policy Publication Model A Domain Operator publishes a CSP Reporting Endpoint Policy at a well-known owner name below the Policy Domain. A conforming user agent MAY query for the CSP Reporting Endpoint Policy when it processes a CSP policy for an origin whose host is at or beneath the Policy Domain. Jackson Expires 24 December 2026 [Page 5] Internet-Draft CSP Reporting Policy June 2026 A conforming user agent MUST use the DNS-published policy only to add or select reporting endpoints. It MUST NOT use the DNS-published policy to add, remove, or modify CSP enforcement directives. A conforming user agent MUST NOT send reports to a DNS-published endpoint unless the endpoint is HTTPS. 7. Owner Name The owner name is: _csp. For example, for the Policy Domain example.com, the owner name is: _csp.example.com A user agent evaluating an origin at https://www.example.com MAY query _csp.example.com if it determines that example.com is the applicable Policy Domain. 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. 8. Record Format Version 00 of this specification defines publication using TXT records. A future version MAY define a dedicated DNS resource record type if operational experience justifies it. The TXT record value is a sequence of semicolon-delimited key-value pairs. The first key-value pair MUST be: v=CSP1 The key in each key-value pair is a tag. Tags are case-sensitive. Consumers MUST ignore unrecognised tags. The following tags are defined: v: Policy format version. The value MUST be CSP1. report-uri: One or more HTTPS reporting endpoint URI references Jackson Expires 24 December 2026 [Page 6] Internet-Draft CSP Reporting Policy June 2026 [RFC3986]. The value syntax is intentionally aligned with the CSP report-uri directive. Multiple URI references are separated by ASCII whitespace. At least one reporting endpoint is required. mode: Optional reporting behaviour. The value MUST be one of augment or fallback. If absent, the default value is fallback. max_age: Optional maximum policy lifetime in seconds. If absent, the default value is 86400. sp: Optional subdomain policy. The value MUST be either 0 or 1. When 1, the policy applies to subordinate hostnames beneath the Policy Domain. If absent, the default value is 1. format: Optional report serialisation preference. The value MUST be one of csp-report, application/reports+json, or both. The value csp-report denotes the legacy CSP report body used with report- uri. The value application/reports+json denotes the W3C Reporting API serialisation. If absent, the default value is both. tag: Optional opaque operator-defined string used to identify the policy when processing browser-submitted CSP reports. contact: Optional contact URI for operational enquiries. A mailto: URI MAY be used. If absent, operators SHOULD fall back to established administrative contacts such as webmaster or DNS administrative contacts for the Policy Domain. Example: _csp.example.com. 3600 IN TXT ( "v=CSP1; report-uri=https://reports.example.com/csp;" " mode=augment; max_age=86400; sp=1;" " format=both; tag=2026-06-production" ) Example with multiple reporting endpoints: _csp.example.com. 3600 IN TXT ( "v=CSP1;" " report-uri=https://r1.example.com/csp" " https://r2.example.com/csp;" " mode=fallback; max_age=86400; sp=1;" " format=csp-report; tag=fallback-2026-06" ) TXT character-string splitting follows normal DNS TXT processing. Consumers MUST concatenate TXT character-strings belonging to the same TXT RR before parsing. Jackson Expires 24 December 2026 [Page 7] Internet-Draft CSP Reporting Policy June 2026 9. Policy Processing A user agent that implements this specification performs the following steps: 1. Process HTTP CSP policy according to existing CSP rules. 2. Determine whether CSP reporting is applicable. 3. Determine the applicable Policy Domain. 4. Query for TXT records at _csp.. 5. Select records whose first key-value pair is v=CSP1. 6. Reject records that contain no report-uri tag. 7. Reject records that contain no HTTPS reporting endpoint. 8. Apply the default mode value if the mode tag is absent. 9. Apply the default max_age value if the max_age tag is absent. 10. Reject records whose max_age value is invalid or greater than the implementation maximum. 11. Apply the default sp value if the sp tag is absent. 12. Apply sp according to Section 8. 13. Apply mode according to Section 10. 14. Send CSP violation reports to the selected endpoint or endpoints, subject to rate limiting, privacy constraints, delivery constraints, and failure handling. If multiple CSP1 records are present, the user agent MAY use any valid record. A user agent SHOULD prefer the record with the shortest valid max_age when deterministic selection is needed. Invalid records MUST be ignored. 10. Interaction with HTTP CSP Reporting The DNS-published policy has two modes. Jackson Expires 24 December 2026 [Page 8] Internet-Draft CSP Reporting Policy June 2026 In augment mode, the user agent SHOULD send CSP violation reports to both HTTP-declared reporting endpoints and DNS-declared reporting endpoints, subject to user-agent policy, privacy controls, rate limiting, and delivery constraints. In fallback mode, the user agent MAY send CSP violation reports to the DNS-declared reporting endpoint only when the HTTP response [RFC9110] did not declare a valid HTTP-declared reporting endpoint. A DNS-published policy MUST NOT suppress an HTTP-declared reporting endpoint. A DNS-published policy MUST NOT change the disposition of a CSP policy. For example, it MUST NOT convert a report-only policy into an enforcing policy. A DNS-published policy MUST NOT cause reports to be generated where no CSP policy was active. This document defines where CSP reports may be sent, not when CSP reports are generated. 11. Endpoint Authorisation A reporting endpoint is authorised when all of the following are true: * the endpoint URI uses the https scheme; * the endpoint URI is syntactically valid; * the CSP Reporting Endpoint Policy record is syntactically valid; * the Policy Domain is applicable to the origin being processed; * the policy has not expired according to max_age; * local user agent policy does not prohibit use of the endpoint. Implementations MAY require the endpoint host to be at or beneath the Policy Domain. Implementations MAY allow cross-domain reporting endpoints where enterprise or managed-browser policy permits this. A future version of this document MAY define an explicit endpoint authorisation challenge to allow reporting endpoints outside the Policy Domain. Jackson Expires 24 December 2026 [Page 9] Internet-Draft CSP Reporting Policy June 2026 12. Caching and Freshness User agents MAY cache CSP Reporting Endpoint Policy records. The effective cache lifetime is the lesser of: * the DNS TTL; and * the max_age value in the policy. User agents SHOULD impose an implementation maximum on policy cache lifetime. A suggested maximum is 86400 seconds. User agents MUST NOT use a cached policy after its effective cache lifetime has expired. Negative DNS responses MAY be cached according to normal DNS negative caching behaviour, subject to implementation limits. 13. Failure Handling If the DNS query fails, the user agent MUST continue processing the HTTP CSP policy normally. If the DNS-published policy is invalid, the user agent MUST ignore it. If the DNS-published reporting endpoint is unreachable, the user agent MUST NOT block page rendering or alter CSP enforcement. If DNS-published and HTTP-declared reporting endpoints both exist, failure of one reporting path MUST NOT prevent attempted delivery to the other path where the user agent supports multiple reporting destinations. User agents SHOULD apply rate limiting to avoid report storms. 14. Privacy Considerations DNS lookup for _csp. may reveal that a user has visited an origin beneath the Policy Domain. This leakage may be similar to other DNS lookups for the same site, but it is still a distinct query and must be considered. User agents SHOULD avoid unnecessary policy lookups. A user agent SHOULD query only when CSP reporting is relevant to the active response. Jackson Expires 24 December 2026 [Page 10] Internet-Draft CSP Reporting Policy June 2026 Reports may contain sensitive data, including blocked URLs, source file locations, referrers, user agent strings, and script samples. Reporting endpoints MUST treat received reports as security-sensitive telemetry. User agents SHOULD avoid including more detail than is required by the applicable CSP reporting format. User agents SHOULD respect private browsing modes, tracking protections, enterprise policy, and user privacy preferences when deciding whether to use DNS-published reporting endpoints. 15. Security Considerations DNS-published reporting endpoint policy creates a new administrative control channel. Incorrect or malicious DNS data could redirect CSP reports to an attacker-controlled endpoint. Therefore, user agents MUST restrict DNS-published endpoints to HTTPS URIs. Implementations MUST prefer DNS data obtained through authenticated or integrity-protected resolution paths, including DNSSEC-validated responses [RFC4033], DNS-over-TLS, or DNS-over-HTTPS. Where DNSSEC validation is available and returns a validation failure for the policy owner name, implementations MUST treat the DNS query as failed and MUST NOT use the policy record. A DNS-published policy MUST NOT weaken or override HTTP CSP enforcement. This constraint is central to the security model. A reporting endpoint can receive sensitive operational information. Domain Operators SHOULD ensure that reporting endpoints implement appropriate authentication, access control, retention controls, abuse handling, and data minimisation. DNS zone compromise would allow an attacker to change the reporting endpoint. This risk is comparable to other DNS-published security policies. Operators SHOULD apply strong DNS account controls, change control, DNSSEC where appropriate, and monitoring for policy changes. An attacker may attempt to induce report floods. Reporting endpoints SHOULD rate limit, deduplicate, and discard malformed reports. A malicious application owner beneath a domain may deliberately emit CSP policies that generate excessive reports. DNS-published reporting endpoint policy does not solve this governance problem. It only provides a central reporting destination. Jackson Expires 24 December 2026 [Page 11] Internet-Draft CSP Reporting Policy June 2026 User agents MUST NOT send reports to insecure transport endpoints. User agents MUST NOT treat DNS publication as evidence that a domain has enabled CSP enforcement. 16. Operational Considerations Domain Operators SHOULD begin with fallback mode before deploying augment mode. Domain Operators SHOULD use short TTL values during initial deployment. Domain Operators SHOULD publish a stable tag value and change it when policy meaning changes. Reporting endpoints SHOULD accept both legacy CSP report format and Reporting API JSON format where possible. Reporting endpoints SHOULD deduplicate reports by at least: * effective directive; * blocked URL or blocked origin; * document URL or origin; * disposition; * user agent family; * time window. Operators SHOULD provide a documented retention period for collected reports. Operators SHOULD avoid using third-party reporting endpoints unless contractual, privacy, and data processing obligations have been reviewed. Domain Operators running delegated hosting environments or multi- tenant platforms SHOULD use sp=0 when publishing mode=augment at the apex domain. Operators SHOULD NOT publish sp=1; mode=augment at the apex where subordinate hostnames are operated by independent parties who have not consented to forwarding reports to the domain operator's endpoint. Operators MAY publish separate _csp records at subdomains they fully control to extend augment coverage selectively. Jackson Expires 24 December 2026 [Page 12] Internet-Draft CSP Reporting Policy June 2026 17. IANA Considerations This document requests creation of the following registry: CSP Reporting Endpoint Policy Tags Initial registry contents: v report-uri mode max_age sp format tag contact Registration policy: Specification Required. This document does not request a new DNS resource record type in version 00. [Open Issue: A future revision may request a dedicated DNS resource record type if TXT deployment is considered insufficient.] 18. Examples 18.1. Fallback Reporting for a Domain _csp.example.com. 3600 IN TXT ( "v=CSP1; report-uri=https://reports.example.com/csp;" " mode=fallback; max_age=86400; sp=1;" " format=both; tag=fallback-2026-06" ) In this example, user agents that support this specification may send CSP violation reports to https://reports.example.com/csp when a response beneath example.com contains CSP but does not declare a valid HTTP-declared reporting endpoint. 18.2. Augmented Reporting for a Managed Single Website _csp.example.net. 300 IN TXT ( "v=CSP1; report-uri=https://csp.example.net/report;" " mode=augment; max_age=3600; sp=0;" " format=application/reports+json; tag=pilot-001" ) Jackson Expires 24 December 2026 [Page 13] Internet-Draft CSP Reporting Policy June 2026 In this example, user agents should send reports to both the HTTP- declared reporting endpoint and the DNS-published endpoint, subject to user-agent policy, privacy controls, rate limiting, and delivery constraints. 18.3. Reporting Policy Applying Only to the Policy Domain _csp.example.org. 3600 IN TXT ( "v=CSP1; report-uri=https://reports.example.org/csp;" " mode=fallback; max_age=86400; sp=0;" " format=csp-report; tag=apex-only" ) In this example, the policy applies to the Policy Domain only. It does not apply to subordinate hostnames beneath example.org. 19. Open Issues This version intentionally leaves the following issues open: * Whether TXT is sufficient or a dedicated DNS RR type is required. * Whether DNSSEC validation should be mandatory, recommended, or implementation-defined. * Whether cross-domain reporting endpoints should be permitted. * Whether endpoint ownership should be proven through an HTTPS well- known resource. * Whether policy discovery should occur only after a response declares CSP, or also when a response lacks CSP. * Whether report generation should remain strictly dependent on HTTP CSP policy presence. * Whether interaction with enterprise-managed browser policy should be specified. * Whether this work belongs primarily in IETF, W3C WebAppSec, or a joint coordination model. * Whether sp creates unacceptable risk for delegated hosting environments. * Whether this mechanism should be limited to report-only policies. * Whether a future version should support report-to and the Reporting API Reporting-Endpoints header field directly. Jackson Expires 24 December 2026 [Page 14] Internet-Draft CSP Reporting Policy June 2026 * Whether tag should be included in report payloads, reporting envelopes, or only used by reporting processors as local metadata. 20. References 20.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [CSP] W3C, "Content Security Policy Level 3", . [REPORTING] W3C, "Reporting API", . 20.2. Informative References [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . [PUBLIC-SUFFIX] Mozilla Foundation, "Public Suffix List", . Jackson Expires 24 December 2026 [Page 15] Internet-Draft CSP Reporting Policy June 2026 Appendix A. Rationale The proposal deliberately avoids DNS-based CSP enforcement. DNS is attractive as an administrative control plane, but CSP enforcement is origin-sensitive and depends on web platform behaviour, response context, page type, and browser processing rules. A DNS mechanism that overrides enforcement directives could create unsafe ambiguity. Reporting is a narrower and more practical starting point. It gives the domain operator visibility without changing whether content is allowed or blocked. The fallback mode supports conservative deployment. It only fills a gap when HTTP CSP reporting information is absent or unusable. The augment mode supports mature estates that want centralised reporting in addition to application-specific reporting. TXT publication is used in this draft to reduce deployment friction. A dedicated RR type may be technically cleaner, but TXT is easier to test operationally during the experimental phase. The owner name _csp. is intentionally broad enough to support future CSP-related DNS publication while this version remains limited to reporting endpoint policy. The report-uri tag is used because it aligns with existing CSP terminology. This document does not define DNS-based CSP enforcement and does not define a replacement for HTTP CSP reporting directives. Author's Address Simon Jackson Alltime Technologies Ltd Email: simon.jackson@alltimetech.co.uk Jackson Expires 24 December 2026 [Page 16]