DNS-Based Content Delivery & Fallback Mechanism
draft-dns-content-delivery-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | April Faye John | ||
| Last updated | 2026-03-26 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-dns-content-delivery-00
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:
_<media-subtype>._dnscontent.<domain>
* 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=<encoding>;] [id=<stream-id>;] [tot=<total-chunks>;] c=<content>
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).
_<sequence-number>._<media-subtype>._dnscontent.<domain>
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=<stream-id>; c=<content>
* *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 _<media-subtype>._dnscontent.<domain>.
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 _<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.
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 <h1>Welcome</h1>
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]