]>

DE aprl@sakamoto.pl

Internet Engineering Task Force This document specifies a mechanism for serving content, such as HTML or JSON, directly via DNS TXT records. This feature is intended as a fallback mechanism when a primary service (A/AAAA record) is unreachable, or as a lightweight hosting solution for parked domains to display landing pages without requiring active HTTP servers or individual SSL certificates. Trust is established via DNSSEC, allowing browsers to treat the content as secure.

Introduction Managing HTTP servers and HTTPS certificates for a large number of parked domains or "placeholder" sites can be resource-intensive and operationally complex. Additionally, when a web server fails (connection refused or timeout), users are typically presented with a generic browser error page. This specification defines the "DNS Content" (DNSC) protocol, which allows User Agents (UAs) to retrieve content directly from the DNS system using structured TXT records. This feature is intended as a fallback mechanism when a primary service (A/AAAA record) is unreachable, or as a lightweight hosting solution for parked domains to display landing pages without requiring active HTTP servers or individual SSL certificates.

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. This document makes use of terminology for record types (TXT), and other technical terms that are specific to the DNS. Since these terms have specific meanings in the DNS, they are not expanded upon first use in this document. For definitions of these and other terms, see [RFC8499].

The _dnscontent Resource Record Content is published using DNS TXT records located at a specific prefix indicating the content type.

Naming Convention The TXT record MUST be located at a label constructed as follows: ._dnscontent. ]]>

• media-subtype corresponds to the IANA media type subtype (e.g., html for text/html, json for application/json).
• domain corresponds to the FQDN of the service (e.g., example.com).

Examples:

• _html._dnscontent.example.com implies Content-Type: text/html
• _json._dnscontent.api.example.com implies Content-Type: application/json

Record Syntax (Root Record) The TXT record content is a semi-colon separated list of key-value pairs. The keys are case-insensitive. ;] [id=;] [tot=;] c= ]]> Parameters

Parameter	Name	Description
v	Version	REQUIRED. Must be DNSC1.
e	Encoding	OPTIONAL. Specifies the compression algorithm applied to the content before Base64 encoding.
id	Stream ID	OPTIONAL (REQUIRED if tot > 1). A unique alphanumeric identifier (e.g., a short hash) for this version of the content. Used to correlate chunks.
tot	Total Chunks	OPTIONAL. Integer indicating the total number of records (chunks) required to reconstruct the content. Default is 1.
c	Content	REQUIRED. The payload data encoded in Base64. If chunking is used, this field contains the first chunk (Sequence 0).

The parameter e (Encoding) can have following the values:

• raw (Default): No compression.
• gzip: GZIP compression [RFC1952].
• br: Brotli compression [RFC7932].

Chunking Mechanism DNS messages have size constraints. To support content larger than a single TXT record's safe limit, the content MAY be split across multiple records.

Chunk Discovery If tot > 1 in the Root Record, the UA MUST fetch additional records. Subsequent chunks are located at subdomains prefixed with the sequence number (1-based index). ._._dnscontent. ]]>

Example If Root is _html._dnscontent.example.com, then:

• Chunk 1 is at _1._html._dnscontent.example.com
• Chunk 2 is at _2._html._dnscontent.example.com
• ...up to tot - 1.

Chunk Record Syntax ; c= ]]>

• v: Must be DNSC1.
• id: MUST match the id provided in the Root Record. UAs MUST discard chunks with mismatched IDs to prevent mixing versions during updates.
• c: The Base64 encoded payload for this segment.

Client Behavior

Trigger Conditions A UA SHOULD initiate a DNSC lookup under the following conditions:

1. The UA fails to fetch A or AAAA records for a specified domain (NXDOMAIN or NOERROR/NODATA).
2. The UA fails to establish a TCP connection to the IP addresses resolved from A/AAAA records (e.g., Connection Refused, Timed Out).
3. A mechanism (e.g., a specific URI scheme) explicitly requests a DNSC request.

Processing Logic

1. The UA constructs the query name based on the desired content type (_html for web navigation).
2. Query TXT for _<media-subtype>._dnscontent.<domain>.
3. Parse the TXT record. If v is not DNSC1, ignore.
4. Fetch Chunks (if needed):
   • If tot > 1, loop from i = 1 to tot - 1.
   • Query TXT for _<i>._<media-subtype>._dnscontent.<domain>.
   • Validate id.
   • Concatenate the Base64 strings from Root then _1, _2, etc.
5. Decode:
   • Base64 Decode the assembled string.
   • Decompress based on the e parameter (gzip, br, or none).
6. Display the content with the implied Content-Type.

Security Considerations

Trust & Origin Since DNSC does not use TLS certificates (X.509), trust is established via DNSSEC.

• If the domain is signed with DNSSEC and the chain of trust is validated by the UA (or the recursive resolver trusted by the UA), the content MUST be treated as a secure Context.
  • UAs MAY display a specific indicator (e.g., "Verified by DNSSEC").
• If DNSSEC validation fails or the zone is unsigned, the content MUST be treated as an insecure Context (similar to plain HTTP).
  • Powerful features (Geolocation, Service Workers, etc.) MUST be disabled.

Mixed Content & Subresources

• Relative Links should be resolved relative to the domain root.
• External Resources:
  • In a secure Context (DNSSEC), resources (JS, CSS, Images) SHOULD be loaded over HTTPS or verified DNSC.
  • In an insecure Context, standard Mixed Content blocking rules apply.

Denial of Service To prevent loops or excessive DNS traffic:

• UAs SHOULD enforce a limit on the maximum number of chunks (tot). A recommended limit is 16 chunks.
• UAs SHOULD implement caching for DNSC records respecting the TTL.

Examples

Simple Landing Page (No Chunking) Decodes to <h1>Welcome</h1>

Compressed & Chunked Content Root Record: Chunk 1: The UA fetches both, verifies id=req89 matches, concatenates the Base64 payloads, decodes, decompresses using Brotli, and renders.