dns VS steed

The heavylifting is done by this package: https://github.com/miekg/dns.

Apart from `dig`, clients like https://github.com/miekg/dns show the same behavior.

For the DNS i wrote a PiHole clone, which on the core it uses github.com/miekg/dns, to upstream queries and also to handle the custom entries, i've been wanting to publish that project but haven't done so cause the code is a bit messy since i did it as a PoC mostly, when comparing it to pihole it has the advantage that its really resource light mostly on the admin features, the dns resolving performs pretty much the same.

coredns uses github.com/miekg/dns under the hood

You can do the same with net.Resolver, either by just setting it's Dial function (and PreferGo=true). You can use https://pkg.go.dev/golang.org/x/net/dns/dnsmessage or https://github.com/miekg/dns to implement an in-process server, either over TCP/UDP or skipping real networking completely, just like you can do with https://golang.org/pkg/net/http/httptest

Had a similar problem a couple years ago where I needed to use alternative DNS libraries to troubleshoot issues in a company's infrastructure.

Golang's rules for what implementation to use are found here: https://golang.org/pkg/net/#hdr-Name_Resolution

A really solid alternative DNS client implementation can be found here: https://github.com/miekg/dns. Real easy to read and vet compared to a few other libraries I ran into when working on this problem.

The steed project (https://github.com/japaric/steed) attempted to create a pure Rust implementation of std and follow up projects like mustang attempt the same, so this is not as absurd as it might sound.

I really hope that we will get a libc-free Linux target. Mustang/rsix looks like a great step in this direction, similarly to steed (https://github.com/japaric/steed) before it. But I think that ideally it should be done properly in Rust proper, not in outside projects. Here a relevant issue, but there is not much progress on it: https://github.com/rust-lang/rfcs/issues/2610

At least for rust, a librs would be hard to create due to the lack of a stable ABI. So even if you did a pure rust libstd (like the now defunct Steed[0]), you'd still need to either manually link that libc (breaking the mitigation), or rebuild your program each time the distro updates either libstd or the rust compiler.

I'm not sure what the situation for Go is. Assuming Go has proper support for dynamic loading and a stable ABI, it would be doable.

[0]: https://github.com/japaric/steed