DNS-Published Content Security Policy Reporting Policy

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.¶

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

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.¶

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;¶

• 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.¶

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 [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.¶

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.¶

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.¶

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.¶

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.¶

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.¶

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

_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" )

_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" )

_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" )

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.¶

• Whether tag should be included in report payloads, reporting envelopes, or only used by reporting processors as local metadata.¶

20. References

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