Deprecation notice

[Mygod]

I’ve decided to stop actively maintaining slipstream-rust.

The main reason is architectural. After spending more time working on Slipstream, I no longer think proxying traffic over QUIC over DNS is the right architecture to keep investing in.

The original idea behind Slipstream is quite reasonable: instead of designing yet another reliable transport for DNS tunneling, use QUIC and get streams, reliability, congestion control, encryption, and multipath more or less for free. When implementing all of those things yourself is expensive, that is a very attractive tradeoff.

But in practice, DNS is a rather unusual substrate for QUIC. It is a constrained request/response protocol, with asymmetric upstream and downstream behavior, resolver-specific rate limits and loss characteristics, and a requirement that downstream traffic effectively be pulled by client queries.

As a result, Slipstream cannot simply put ordinary QUIC packets inside DNS and leave the rest to QUIC. It has accumulated a substantial compatibility layer: custom poll frames, special ACK and loss behavior, changes to congestion control, altered path handling, DNS-specific pacing, and application-level resolver management. Some normal QUIC semantics, such as path validation and migration, do not really make sense in the same way and have to be bypassed or adapted.

Multipath is a particularly good example. What we actually care about is using multiple DNS resolvers intelligently—accounting for their individual rate limits, loss, latency, health, and failures. Multipath QUIC gives us some machinery for multiple paths, but it does not give us that resolver policy. We still have to build it ourselves.

At some point, this starts to defeat the reason for using QUIC in the first place.

I now think of QUIC here as a means, not an end. It was a way to avoid the engineering cost of implementing a transport protocol from scratch. But if we have to maintain a custom QUIC implementation and substantially adapt its congestion control, loss recovery, polling, multipath behavior, and flow control anyway, the abstraction is not buying us nearly as much as it appears to.

There is also an ongoing maintenance cost. QUIC 1.0 itself is standardized, but the multipath extension Slipstream depends on has continued to evolve, and practical multipath implementations are still not something I have found particularly satisfactory. Maintaining our own picoquic fork on top of that makes the problem worse.

Finally, the economics of software development have changed. AI-assisted coding certainly does not make protocol design or correctness free, but it has lowered the implementation cost enough that the original build-vs-reuse tradeoff looks different to me now. A smaller transport designed specifically around the peculiarities of DNS—polling, asymmetric capacity, resolver-aware scheduling, retransmission, failover, etc.—now seems both more feasible and ultimately cleaner than continuing to bend QUIC into that shape.

So this isn’t really a conclusion that slipstream-rust “failed.” The Rust implementation works, performs well, and taught me quite a bit about the problem. I just no longer think this is the architecture on which the next round of engineering effort should be spent.

For people looking for a maintained solution today, MasterDnsVPN seems like a good alternative. It takes a more purpose-built approach, with its own lightweight protocol and ARQ rather than putting QUIC underneath the DNS tunnel, which is much closer to the direction I now think makes sense.

I’ll leave slipstream-rust available, but I don’t plan to actively maintain it going forward.