On 2 Oct 2026, at 20:01, Michael Richardson <[email protected]> wrote:
> Anyway, I'd like to know what direction Joe Abley would suggest. > What direction(s) do you think might be fruitful? I imagine that there might > be avenues that wound up as dead-ends in 2006, but which might result in > fresh fruit. I am awake on an overnight, eastbound plane between Canada and Europe and as a result this reply got a little long, sorry about that, I do actually try to answer your question at the bottom, feel free to skip to the end. We have transport protocols for DNS that are defined, implemented and used and which don't suffer from response size sensitivity; we have TCP, DoT, DoH and DoQ. (If we are going to do some of the work that follows, I don't know why we would stop at TCP and not take the opportunity to improve privacy at the same time with DoX.) DoX is (are?) quite widely used between stub and resolver (some deployed resolvers, at least) and so we have a starting point for understanding the performance and capacity impact of state and more session setup. People who do this kind of thing at scale could talk about it. We lack experience, guidance and maybe signalling that would allow DoX to become ubiquitous. We don't know how many messages it's reasonable to exchange over a single session, or when to adjust bundle sizes or how long it's reasonable for idle sessions to remain open. Clients can be aggressive and servers can be defensive and we don't know how to make them play nicely with each other and protect such a system from abuse. We know some stuff from the use of DoX between stubs and their configured recursive servers but it feels like there are more things to understand between a recursive server and a much larger number of dynamically-discovered authority servers. We have RFC9539 but few authority servers seem to have picked it up. DELEG promises a way to signal availability of stream-based transport protocols in zone data for particular zones. Johan Stenstam and friends' OOTS provides a way to publish the same kind of thing for particular nameservers. We have experience from HTTP and the now near-complete transition to HTTPS that could surely be helpful, but as DNS people we are often curiously deaf to such things because really, who cares about the web anyway? We should perhaps get over ourselves. (We surely have all kinds of other stuff too that has slipped my mind, and maybe some of the gaps I identified are less empty than I think. But we still have an overwhelmingly unencrypted DNS with response size problems so I think it's fair to say that significant gaps exist even if they're not precisely the ones I mentioned.) So, to answer your question, I think we have parts of the puzzle but we lack the coordinated effort to finish the jigsaw and achieve a new default, perhaps because we haven't said out loud that we want one. Joe _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
