ADadamnemecek·Dec 5, 2016Submission
Trust-dns: A Rust based DNS server
1 points · Open discussionbluejekyll
trust-dns
Networking2016–2023
bluejekyll / trust-dns
trust-dns
Discover this repository through its Hacker News conversations.
11Distinct people
27Mentions
0Explicit recommenders
10GitHub stars
What to know before exploring
What it is
A public description has not been verified.
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 11:34:28 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year27 dated mentions
Observed mentions: 2016-03-19 23:51:51 UTC to 2023-10-07 02:39:37 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 7 | 2 | 5 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 9 | 0 | 9 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 2 | 0 | 2 |
What Hacker News says
7 sourcesThis is something I'm personally very interested in. I'm planning to add one or both of DNS over TLS (https://github.com/bluejekyll/trust-dns/issues/38) or DNSCrypt (https://github.com/bluejekyll/trust-dns/issues/4).
Currently I'm planning to do just DNS over TLS. I'd love feedback on this if people are interested. Both of these address this issue pretty well.
In Transparent DNS proxiesTRust-DNS: A Rust based DNS server
2 points · Open discussionI've been thinking of adding this exact feature to my DNS framework that I've been working on (if github was resolving): https://github.com/bluejekyll/trust-dns
If you have any feedback, I'd love to hear it.
In DDoS Attack Against Dyn Managed DNSI think I completely agree with you:
> the protocol should be redesigned to assume online signers, taking advantage of cryptography in every transaction.
When you say online signers, do you mean not actively storing RRSIG records for RR sets at all? Or do you mean dynamically resigning the zone after any update? I think there is a benefit to these records in validating they originate with zone from which they claim to be. The biggest concern I have right now with the protocol is that having multiple nodes being responsible for managing a zone is difficult because each has to be signed by the parent zone, though with the necessary automated support, this shouldn't be hard to overcome (i.e. makes HA harder).
> Resolver-server encrypted transactions also solve the problem of endpoint signature validation (because there's no weak link between
Read the rest
servers and clients anymore)
Do you have any thoughts on DNS over TLS vs DNSCrypt? I got halfway through implementing DNSCrypt, but I have some concerns about it being easily exploitable for DOS attacks. And am switching to DNS over TLS for now.
> Daniel Bernstein, among others, was smart enough to realize that if you encrypt the connection between a resolver and a server, you don't really even need signatures anymore...
Yes, this is true, but the concerns I've had with this are 1) ability to cache data and 2) ability to add nodes to the network. While I completely agree with this, we need to come up with a method that allows new nodes to be added to the graph, which might be cumbersome from a resolver perspective. In terms of zone authorities it should be relatively straightforward though. With the current DNSSec design, it allows for trusted data to be stored on untrusted nodes in the graph, making cached data straightforward.
If you don't mind, I'd love your feedback on a project I've been working on for the last year: https://github.com/bluejekyll/trust-dns
I want to try and deal with many of these aspects of the protocol, from the slant of making it easier to setup and operate. I currently don't have a lot of documentation around operations, as I'm still focused on implementing some things like DNS over TLS. I'd love to bake some of these concepts into the software, so if you have any feedback that would be awesome.
Sure: https://github.com/bluejekyll/trust-dns
It's a WIP, but mostly feature complete at this point. I'm working on DNSCrypt at the moment.
In The Rustonomicon: The Dark Arts of Advanced and Unsafe Rust ProgrammingI'm working on something: https://github.com/bluejekyll/trust-dns
I'm in the midst of implementing DNSSec right now, I've got RRSIG and DNSKEY validation back to the root now. I'm working on negative query validation right now, NSEC and NSEC3. Maybe a new release in a few weeks after that is supported.
In Redox – A Unix-Like Operating System Written in Rust