Hi everyone, I’m working on a multiplatform DNS li...

# ktor

[Amir Golmoradi]

Hi everyone, I’m working on a multiplatform DNS library in pure Kotlin (targeting JVM, linuxX64, linuxArm64 and Android). I’ve been looking at ktor-network for the UDP and TCP side and overall it works well, but I’ve run into a few limitations that matter for a performance-sensitive use case.
On the UDP side it doesn’t seem possible to receive into a buffer that I fully control — every receive ends up going through the internal pool and producing a new Datagram/Source. I’d like to avoid per-packet allocations as much as possible. Connected UDP sockets and the basic socket options (buffer sizes, reuse address/port, etc.) are available and work, which is great, but the lack of a zero-copy or caller-owned buffer path is the main pain point.

I’m also interested in DNS over TLS. ktor-network-tls works on the JVM, but on Native it currently throws “TLS sessions are not supported on Native platform”. Is there any plan to support raw TLS sockets on the Native targets, or is the expectation that people should use platform TLS (OpenSSL, etc.) on top of a plain TCP socket?
I’m trying to decide whether ktor-network gives enough low-level control for this library or whether I should write a thin networking layer myself. Any guidance from people who have used these APIs on Native, or from the maintainers, would be really helpful. Thanks!

[jessewilson]

Off topic, but whatcha doin with DNS? We recently started doing a ton more DNS stuff in OkHttp and it was fun

[Aleksei Tirman [JB]]

Thank you for filing the feature request KTOR-10134. A comment has been left there to clarify your use case.
Unfortunately, we don’t have plans to support TLS on native targets.

[Amir Golmoradi]

Thanks, @Aleksei Tirman [JB]! Good to know about TLS on Native. That’s a bit of a bummer, but I’ll figure out another approach for DoT.
Right now I’m mostly focused on UDP, especially getting more control over receive buffers and avoiding unnecessary allocations.
I’ll follow up on the YouTrack issue with more details. Appreciate you taking a look!

[Amir Golmoradi]

Hey @jessewilson! I’m working on Knet-dns, a DNS client, resolver, and server written from scratch in Kotlin, with a particular focus on Kotlin/Native.
Still early days. Right now I’m working through the DNS protocol and figuring out the networking side, especially UDP and buffer management.
What have you guys been working on in OkHttp?

[jessewilson]

We recently did Encrypted Client Hello (ECH) which required us to do a whole DNS client

[jessewilson]

We're not on native though

[jessewilson]

And we also don't do a UDP implementation cause that's not necessary!

[jessewilson]

We do the parsing and caching and concurrent lookups

[Amir Golmoradi]

Oh, that’s interesting! I hadn’t realized ECH required that much DNS work.
Curious, are you using the platform’s DNS resolver for the actual lookups and handling parsing, caching, and concurrency on top of that?

[jessewilson]

For DoH we're doing pretty much everything

[jessewilson]

For DNS on UDP, Android offers an API that accepts queries and returns results, doing the UDP (or anything else) behind the scenes

[Amir Golmoradi]

Oh, that’s pretty neat! I haven’t dug into OkHttp’s DNS implementation yet,
But I’ll definitely take a look.Sounds like there’s a lot of interesting stuff going on there.

[jessewilson]

It’s straightforward enough. Probably the trickiest thing we’re doing is we have a separate query model for the public API vs. the transport implementation

github.com/lysine-dev/okhttp/blob/…/Dns.kt
github.com/lysine-dev/okhttp/blob/…/DnsQuery.kt

[jessewilson]

The public API one is processed a bit more

[Amir Golmoradi]

Ah, I see what you mean now. Keeping the public API separate from the transport-level queries makes a lot of sense.
Is there anything on the DNS side I could help out with?