Internet Engineering Task Force A. John Internet-Draft 26 March 2026 Intended status: Standards Track Expires: 27 September 2026 DNS-Based Content Delivery & Fallback Mechanism draft-dns-content-delivery-00 Abstract 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. 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 27 September 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. John Expires 27 September 2026 [Page 1] Internet-Draft DNSC March 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The _dnscontent Resource Record . . . . . . . . . . . . . . . 3 3.1. Naming Convention . . . . . . . . . . . . . . . . . . . . 3 3.2. Record Syntax (Root Record) . . . . . . . . . . . . . . . 3 3.3. Chunking Mechanism . . . . . . . . . . . . . . . . . . . 4 3.3.1. Chunk Discovery . . . . . . . . . . . . . . . . . . . 4 3.3.2. Chunk Record Syntax . . . . . . . . . . . . . . . . . 5 4. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Trigger Conditions . . . . . . . . . . . . . . . . . . . 5 4.2. Processing Logic . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5.1. Trust & Origin . . . . . . . . . . . . . . . . . . . . . 6 5.2. Mixed Content & Subresources . . . . . . . . . . . . . . 6 5.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 7 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 7 A.1. Simple Landing Page (No Chunking) . . . . . . . . . . . . 7 A.2. Compressed & Chunked Content . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. 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. John Expires 27 September 2026 [Page 2] Internet-Draft DNSC March 2026 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. 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]. 3. The _dnscontent Resource Record Content is published using DNS TXT records located at a specific prefix indicating the content type. 3.1. 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 3.2. Record Syntax (Root Record) The TXT record content is a semi-colon separated list of key-value pairs. The keys are case-insensitive. v=DNSC1; [e=;] [id=;] [tot=;] c= John Expires 27 September 2026 [Page 3] Internet-Draft DNSC March 2026 +===========+==========+=======================================+ | 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 | OPTIONAL (REQUIRED if tot > 1). A | | | ID | unique alphanumeric identifier (e.g., | | | | a short hash) for this version of the | | | | content. Used to correlate chunks. | +-----------+----------+---------------------------------------+ | tot | Total | OPTIONAL. Integer indicating the | | | Chunks | 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). | +-----------+----------+---------------------------------------+ Table 1: Parameters The parameter e (Encoding) can have following the values: * raw (Default): No compression. * gzip: GZIP compression [RFC1952]. * br: Brotli compression [RFC7932]. 3.3. 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. 3.3.1. 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. John Expires 27 September 2026 [Page 4] Internet-Draft DNSC March 2026 3.3.1.1. 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. 3.3.2. Chunk Record Syntax v=DNSC1; id=; 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. 4. Client Behavior 4.1. 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. 4.2. Processing Logic 1. The UA constructs the query name based on the desired content type (_html for web navigation). 2. Query TXT for _._dnscontent.. 3. Parse the TXT record. If v is not DNSC1, ignore. 4. Fetch Chunks (if needed): John Expires 27 September 2026 [Page 5] Internet-Draft DNSC March 2026 * If tot > 1, loop from i = 1 to tot - 1. * Query TXT for _._._dnscontent.. * 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. 5. Security Considerations 5.1. 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. 5.2. 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. John Expires 27 September 2026 [Page 6] Internet-Draft DNSC March 2026 5.3. 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. Appendix A. Examples A.1. Simple Landing Page (No Chunking) _html._dnscontent.example.com. IN TXT "v=DNSC1; e=raw; c=PGgxPldlbGNvbWU8L2gxPg==" Decodes to

Welcome

A.2. Compressed & Chunked Content Root Record: _html._dnscontent.domain.com. IN TXT "v=DNSC1; e=br; id=req89; tot=2; c=G873..." Chunk 1: _1._html._dnscontent.domain.com. IN TXT "v=DNSC1; id=req89; c=...B729" The UA fetches both, verifies id=req89 matches, concatenates the Base64 payloads, decodes, decompresses using Brotli, and renders. Author's Address April Faye John Germany Email: aprl@sakamoto.pl John Expires 27 September 2026 [Page 7]