You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
DNS queries are currently done using the standard system resolver, which means that for each time a domain name is resolved, we use a tokio blocking thread under the hood to invoke a system call.
This works well to some extent but at some point this can become a bottleneck, especially in ActivityPub environments, where there is a lot of different domain names that have to be resolved quite often.
Describe the solution you'd like
The hickory-dns project provides a user-land async Rust implementation of the DNS protocol.
This would allow us to keep all the resolve logic in-process. And due to it being async from the ground up, we don't need to spawn any blocking threads, getting rid of the expensive inter-thread communication and thread spawning.
It would also allow us to easier support:
DNS-over-TLS and DNS-over-HTTPS
Non-system DNS resolvers (for example, the system uses the default ISP-provided DNS servers, while Kitsune uses Quad9)
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
DNS queries are currently done using the standard system resolver, which means that for each time a domain name is resolved, we use a tokio blocking thread under the hood to invoke a system call.
This works well to some extent but at some point this can become a bottleneck, especially in ActivityPub environments, where there is a lot of different domain names that have to be resolved quite often.
Describe the solution you'd like
The
hickory-dns
project provides a user-land async Rust implementation of the DNS protocol.This would allow us to keep all the resolve logic in-process. And due to it being async from the ground up, we don't need to spawn any blocking threads, getting rid of the expensive inter-thread communication and thread spawning.
It would also allow us to easier support:
The text was updated successfully, but these errors were encountered: