trust-dns

If you don't know what is Trust-DNS / Hickory DNS, this seems to be the repo: https://github.com/bluejekyll/trust-dns

IO is not a part of the async runtime contract (I don't know if this is good or bad), and Tokio & futures famously have different `Async{Read,Write}` traits. I once had to do this [0] to adapt between them. This means that any crate that uses IO will be bound to a limited number of Runtimes. Everything being Tokio-only is pretty bad (though Tokio itself is great), but here we are... [0] https://github.com/bluejekyll/trust-dns/pull/1373#issuecomme...

Hey, HN. I thought you might be interested in a tool I wrote over a few days. As part of a recent IETF hackathon event demonstrating dynamic DNS updates over a private and secure channel (DoT, DoH, DoQ) I needed something to demonstrate the that the software was capable of performing the tasks. This was relatively straightforward with the what I think of as excellent CLI capabilities in the Rust ecosystem with Clap, https://docs.rs/clap/latest/clap/. Anyway, I thought I'd share it with the HN community in case folks find it useful. The tool is vaguely like `dig`, I called it `dns`. It's similar in that it allows a single DNS message to be sent and await a response. This is by no means as comprehensive as `dig`, yet, but might be suitable as a simpler and easier to use command. For example, issuing a DoH query can be done with: `dns -p htt

You could run a local DNS server using something like https://github.com/bluejekyll/trust-dns . Or, you could install an NSS module to resolve names via the innernet client.

One of the great things about Rust is you can write platform-specific code for each platform and then package it all up into one interface so anyone can trivially use it. They get the simplicity of one interface and the performance of platform-specific code. Though I haven't used it personally, it seems like the trust-dns project is one such example: https://github.com/bluejekyll/trust-dns

I actually love this type. Specifically because you can build ranges over complex key types. For example, two keys in a BTreeMap can be used to define a range selector to collect items out of the map, it made me very happy to be able to do this: https://github.com/bluejekyll/trust-dns/blob/main/crates/ser...

> There is really no good reason for DNS servers to be written in C anymore. I’m a little behind on docs, but we have a pretty decent start on one in Rust: https://github.com/bluejekyll/trust-dns We still need an AXFR, IXFR, or replication solution. Also, I haven’t had time to fuzz the zone parsers, so I can’t guarantee we’re resilient to the above yet, but the packet parsers are getting pretty widely used across multiple Rust projects now through the trust-dns-resolver library.

I chose to write my own: https://github.com/bluejekyll/trust-dns And, it in theory can be used in other languages via C FFI as well, since it’s in Rust.

dnsmasq's last CVE was in October 2017 https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=dnsmasq despite that "safety record", I am probably going to switch to https://github.com/bluejekyll/trust-dns

Well, basically because there are TLS libraries available in nearly every language. DNSCrypt is a custom protocol. For example here is my implementation over rustls in TRust-DNS: https://github.com/bluejekyll/trust-dns/blob/master/rustls/s... Basically that’s a thin wrapper over the TLS library, and I was able to do three different libraries. DNSCrypt on the other hand was a much larger project, and I gave up on implementing it when I saw the DNS-over-TLS RFC complete.

People may be interested in a discussion we had about the trust-dns-resolver and some preventative measures in this area: https://github.com/bluejekyll/trust-dns/issues/347 The thing I’m most disappointed with is that because we’ve been so lax about 127.0.0.1 and it’s usage, it’s become a means of different applications to blackhole requests suchas ad-blocking networks. Better than that though, are the applications that are using localhost resolution from public names to communicate with local versions of their applications from the browser. The sad thing, is that because of these we can’t just make a simple resolution policy. The one I would like to be true is that only localhost names can resolve to localhost (this doesn’t require any remote resolution), and that you must whitelist private domains for private address spaces (e.g. 10/8).

Apart from the difference in programming language, how does this compare to https://github.com/bluejekyll/trust-dns ?

For reference, what I have used that makes me claim this without being misleading (not necessarily all at the same time): https://rocket.rs/, https://rusoto.github.io/rusoto/rusoto_core/index.html, https://docs.rs/postgres/0.15.1/postgres/, https://docs.rs/kafka/0.7.0/kafka/, https://docs.rs/reqwest/0.8.1/reqwest/, as well as many other supporting libraries. I've not run into many things where there isn't already support. Also, in terms of networking, if your doing blocking IO, the stdlib is fine. Otherwise, from my experience, I really like https://tokio.rs/ for non-blocking (I know people are torn on this one) and have used it in my DNS impl, https://github.com/bluejekyll/trust-dns For more info on web and Rust, this is a great page: http://www.arewewebyet.org/

I’ve been working on https://github.com/bluejekyll/trust-dns for a bit over two years now. About a year ago a new contributor added Windows build support and testing with AppVeyor, which was awesome. Originally I started this project more for server side stuff, but recently have been very focused on a full resolver which could be used as a replacement for the OS system resolver. A question for HN, what would you like to see in this context that would make a replacement resolver on Windows something you’d use? To be clear, it’s not something you could use dropin right now, it can only be used as an internal library to Rust at-the-moment, but I’ve been planning to start working on a daemon that could act as a caching system resolver in the next little bit.