On Fri, 27 Mar 2026, April John wrote:
I have just submitted a new individual Internet-Draft,
draft-dns-content-delivery-00 , titled "DNS-Based Content Delivery & Fallback
Mechanism".
This document proposes a new protocol (DNSC) that allows User Agents to
retrieve content, such as HTML or JSON, directly via DNS TXT records.
The primary goals of this mechanism are:
- Primarily, o provide a fallback mechanism for when a primary service's
A/AAAA records are unreachable or result in connection timeouts.
I'd think if your web servers are overloaded or unreachable, shifting
that load onto your DNS servers will just mean your DNS service also
goes down.
- To offer a lightweight hosting solution for parked domains or
placeholder sites.
Honestly, vhosting solved that problem a long long time ago.
Key technical aspects of the draft include:
- It allows for content delivery using entries in the DNS.
The idea is cute as a hack, but not as a real use protocol I'm afraid.
And yes, I've been having a twitter-like stream of short messages using
DNS model in my head as well, and it is cute, but like your proposal,
the real problem is storing bulk data (eg images) in DNS.
In the end, you are going to find your domain rate limited as many DNS
servers try to block DNS requests that look like some kind of DNS VPN
tunnel, or a method of using DNS queries to avoid paying the hotspot.
- It implements a chunking mechanism to support content that exceeds the
safe size limits of a single DNS message by splitting it across multiple
records.
Imagine people using this when their DNS points to:
- A small local DNS server which will fall over at the worst case, or
turns into a "nothing useful in cache for real users" at best case.
- A main DNS service (quad9, google, etc) seeing such a huge amount of
traffic they will block the entire zone.
I would greatly appreciate any feedback, reviews, or thoughts from the
working group regarding the architecture, security considerations, and
general interest in this approach.
It's cute and tempting, but unfortunately not workable in the real world.
PS: Here are some possible questions that I thought y'all might have, and my
thoughts on them:
Q: DNS is designed for low-latency name resolution, not for hosting content
like HTML or JSON. Can't large TXT records can lead to packet fragmentation
or increased load on recursive resolvers?
A: This is meant as a fallback mechanism or for parked domains only. It is
not intended to replace high-traffic web servers. See my recommendation for
caching and chunk limits (max 16 chunks) as a way to protect the
infrastructure in Security Considerations.
A fallback mechanism that can't take the original load is not a fallback
mechanism that stays up very long without additional further steps to
bring down the load (eg replace real page with outage notification page)
Q: Aren't large TXT records are a classic tool for DNS Amplification DDoS
attacks? An attacker can send a small spoofed query and cause a large
response to be sent to a victim.
A: Since these are TXT records, they are no more dangerous than existing
large TXT records (like those used for DKIM or SPF) if managed correctly.
You will get blocked for the amplication :P
In short, DNS is poorly suited for this. Don't do this :)
Paul
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
