I agree with Paul, this is not a good use for DNS. The intended role for the DNS is to serve as a control plane mechanism, not data plane transport.
While it is a creative idea, we don’t need to come up with additional use cases to put further demands on DNS infrastructure to serve content. People have been sending application traffic over DNS for years, and it is generally considered a misuse of the DNS. As Paul said, please don’t do this. Thanks, Ross On Fri, Mar 27, 2026 at 2:32 PM Paul Wouters <paul= [email protected]> wrote: > 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]
