Hi Paul,
Thank you for the incredibly candid and detailed feedback. You have
opened on the "purity vs. pragmatism" debate and I appreciate you taking
the time to poke holes in the proposal.
The "cute as a hack" label is one I’ll wear with pride :D, but I’d like
to address your concerns regarding the "real world" viability of DNSC
and specifically how it differentiates itself from a DNS-tunneling-style
(ab-)use of the protocol.
You make a valid point that if a massive web property fails, shifting
that traffic to DNS would be catastrophic. However, the intent of the
"fallback" is not to serve the original site, but rather a more
beautiful "Static Outage Page", which, through caching, should not be
more of an issue than serving a AAA record is, already, to larger DNS
operators. While a modern webpage might be several megabytes, a DNSC
fallback would likely be a 2KB compressed HTML snippet. Most DNS
infrastructure is significantly more over-provisioned and distributed
(via Anycast) than the application-layer web servers it points to.
Serving a tiny "We are under maintenance" TXT record is often less
resource-intensive than maintaining a full TCP/TLS handshake and HTTP
stack for a 503 error page.
On Vhosting and Parked Domains
While vhosting exists, it still requires the management of an IP
address, a listening web server, and, crucially, a valid SSL/TLS
certificate.
For providers managing millions of parked domains, the overhead of
maintaining and renewing certificates is non-trivial. DNSC shifts the
"trust" anchor from the X.509 PKI to DNSSEC. If a domain is already
signed, you get "secure" content delivery for free without a separate
certificate authority.
On Bulk Data and The "DNS VPN" Problem
I completely agree that DNS is not for images or bulk data. The draft
recommends a strict limit (e.g., 16 chunks) to prevent the "bulk data"
scenario you described. You mentioned that resolvers might block this as
a DNS tunnel. However, unlike tunnels that use randomized subdomains to
bypass caches, DNSC uses structured, cacheable labels
(_html._dnscontent.example.com). Since these records respect TTLs and
are highly cacheable by recursives (like Quad9 or Google), they
shouldn't trigger the same "cache-busting" alarms as a DNS VPN. Appart
from that, am I a supporter of things like iodine that allow people to
access the internet more liberally, especially for people in countries
with limited internet access, which is also why I don't see an issue
here, but I can see where people that are against that come from, and
accept their position with open arms, but I do not think that those
critiques apply here. :)
Would you be open to perhabs look over a -01 revision of this draft with
changes the WG and others recommend?
Best regards,
April Faye John
Am 2026-03-27 14:32, schrieb Paul Wouters:
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]
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
