DNS-Published Content Security Policy Reporting Policy
draft-jackson-csp-reporting-policy-00

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.<Policy-Domain>

   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.<Policy-Domain>.

   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.<Policy-Domain> 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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [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,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Semantics", STD 97, RFC 9110,
              DOI 10.17487/RFC9110, June 2022,
              <https://www.rfc-editor.org/info/rfc9110>.

   [CSP]      W3C, "Content Security Policy Level 3",
              <https://www.w3.org/TR/CSP3/>.

   [REPORTING]
              W3C, "Reporting API", <https://www.w3.org/TR/reporting/>.

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,
              <https://www.rfc-editor.org/info/rfc4033>.

   [PUBLIC-SUFFIX]
              Mozilla Foundation, "Public Suffix List",
              <https://publicsuffix.org/>.

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.<Policy-Domain> 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]