Hi Joe -
Your email gave me a laugh - and I'm pretty sure it wasn't intended to.
Here's why:
Imagine how a 9.6KB or 56KB or even a T1 internet fall apart under that
load? Remember when DNS first came out. It was designed to solve one
very pressing problem - the cost of updating and copying the host table
to all existing hosts on an almost daily basis as the number of hosts on
the internet grew exponentially. Most of the links the phone company
was willing to sell to that early internet were 9.6 or 56kb. Eventually,
T1, T3 and faster schemes came along (along with a few detours like ATM)
and we fixed a lot of things by throwing bandwidth at it.
A lot of the traffic on the early internet was character at a time
Telnet for remote access.
HTTP was barely a gleam in anyone's eye until Mosaic came along in 1993.
TLS wasn't even SSL.
SNI wasn't anything anyone had thought of.
In maybe 1994-5 while I was at DARPA I rejected a proposal suggesting
that browsers should prospectively pull the data for all of a pages
links before someone clicked on them. The network at that point in time
was still taking a while to load fairly simple graphics. We were still
trying to get to the point where a video chat of ASL could be understood
(e.g. bandwidth and low latency codecs).
About 20 years ago, I suggested to DNSEXT that we consider building a
second DNS transport protocol - basically another way to retrieve data
from the DNS distributed database that gave us a few more options than
the current protocol. The idea was shot down.
So its fun to imagine what might have been - but consider the realities
of the times.
Mike
ps - we're always going to have to worry about response (total) size.
Don't hand wave the bandwith/latency problem while concentrating on
stateful transport.
pps - Don't hand wave the "turtles all the way down" problem of
transport (privacy) security vs data (integrity) security.
Asymmetrically signed data by its nature is a one-to-many conversation
that at least has a working model and works somewhat with DNS. The
"encrypted and private" query/transport model has little to do with
stateless transport and a lot more to do with cryptographic association
and key management - transport state and crypto state do not necessarily
have to be linked.
ppps - TCP had its own issues with DOS and other attacks early on.
On 10/2/2026 08:09, Joe Abley wrote:
Hi all,
I am evidently not very good at meetecho (or meetecho has it in for me) but
since I couldn't manage to raise my hand and join the queue...
If we had invested as much time on DNS transport protocols that are not
challenged by large responses as we have in trying to work around response size
concerns we would be in a much better place today. Topics like session reuse,
pipelining and simply understanding the full performance picture of
session-based transports are not well-understood and it seems to me there is a
lot to gain by improving the state of the art.
Think back to the delays in including AAAA glue in the root zone for related
reasons, or the long precautionary DURZ we rolled out in anticipation of
falling skies when we signed the root zone.
Imagine how much simplier the PQ DNSSEC conversation would be if we didn't have
to worry about response size.
Imagine how much simpler DOS mitigation would be if UDP transport was rare.
Imagine how much DNS traffic could be encrypted and private if we were not
fixated on stateless transport.
Joe
_______________________________________________
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]
