dnsdist: Ponder DNS over QUIC support

[rgacogne]

• Program: dnsdist
• Issue type: Feature request

Short description

While DoQ is still an unfinished draft, it would be nice to evaluate how and using which library we could implement it in dnsdist. https://en.wikipedia.org/wiki/QUIC#Source_code has a list of existing libraries.

• Quicly might be an obvious choice since we are already using h2o for DoH, but I'm personally not very happy with h2o (the documentation is oriented toward the web server and does not make using the library easy, no releases in years forcing us to patch it..) ;
• ngtcp2 looks nice at first sight and might provide a migration path from h2o to nghttp2 should we choose to do so ;
• mvfst is too tied to Facebook's own libraries ;
• lsquic requires BoringSSL which might cause issues with our existing options.

There are also various options built in Rust that can be used from C++, but I'm not sure it would be worth the build pain.

[Habbie]

ngtcp2 looks nice at first sight and might provide a migration path from h2o to nghttp2 should we choose to do so ;

this is what AdGuard (Home) went with. https://github.com/AdguardTeam/DnsLibs/blob/master/.gitmodules#L41-L43

[paddg]

While DoQ is still an unfinished draft

Now it is published. RFC 9250

[johnhtodd]

See Andrew Campling's Encrypted DNS weekly call from 2022-05-30 - Andrey Meshkov gave a presentation on AdGuard's experiences with DoQ. He mentions that they will be making their DoQ-specific components of their work as a library available under a "permissive" license (though it was not described) and that will be a different license from their other code. Worth examining at a minimum. That may or may not be stacked on top of one of the existing libraries.

[rgacogne]

Thanks! I'll have a look once they release it, although my understanding is that their code is written is Golang which is likely not going to play well with C++.

[mnordhoff]

I don't know the details, but I think AdGuard has both C++ (DnsLibs) and Go (whatever libraries are used by dnsproxy) implementations.

[rgacogne]

The DoQ code in the dnslibs seems to be using ngtcp2, for what it's worth.

[rgacogne]

Oh, Peter reported that a while ago..

[johnhtodd]

DoQ and DoH/3 (https://github.com/PowerDNS/pdns/issues/8914) would be really welcome, but as usual, saying "I want a feature!" is not a way to get a feature. But also just looking to get an update on intentions since I've not kept up. I see that nghttp2 is under active development (https://github.com/PowerDNS/pdns/pull/12678) as recently as yesterday - does this mean that potentially DoQ/DoH/3 are on a closer horizon?

[rgacogne]

We are working on supporting DoQ. It's proving a bit harder than we expected but we will figure it out. We do not have plans for DoH/3 yet.

[rgacogne]

Just so we can get feedback as soon as possible, we are still working on this and we are considering using Clouflare's Quiche instead of ngtcp2 as we like the API much more. ngtcp2's pros are:

• already packaged in distributions
• written in C, so we have a lot of experience on how to integrate such a library
• work with several TLS libraries (but then you need to deal with the library yourself, which means either picking a recent enough version of GnuTLS (>= 3.7.5 so Bookworm, Kinetic and Lunar), BoringSSL (not packaged as far as I know) or the quictls fork of OpenSSL (not packaged, conflicts with the regular OpenSSL lib))

quiche's pros:

• easy to use API (especially compared to ngtcp2's callback-based one)
• the build system already provides a static/dynamic library and header, with a C-compatible interface, so easy to use
• written in a memory-safe language (Rust)
• use BoringSSL statically, so we do not need to care about it
• used by Cloudflare and Android so already seeing a lot of traffic
• easy to go from "just QUIC" for DoQ to HTTP3 for DoH

[ztheory]

For what it's worth, DoQ has very-low adoption in the wild, including client support, and whatever is in progress right now is quite slow rolling since OpenSSL is taking their time with QUIC and software like BIND seems to be waiting for that. DoH/3 is already supported by browsers using the built-in Encrypted DNS feature, so being able to additionally bring in DoH/3 support soon would be a major victory with a current, real-world use case.

+1 for memory safety of Quiche.

[zeha]

Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.

As long as boringssl claims this, it's probably going to be hard to land it in distributions...

[rgacogne]

Note that by default Quiche uses a vendored version of BoringSSL, which might make things easier, provided that distributions do not prevent vendoring.

[zeha]

provided that distributions do not prevent vendoring

that seems to be a problem, from my understanding...