Split trust-dns into multiple crates about hickory-dns

[rushmorem]

How about just trust-dns/core, trust-dns/client e.t.c? I don't know but to me it looks cleaner without the repetition. The crate name can always be overridden in Cargo.toml anyway. Also what do you think about grabbing the trust-dns Github organisation name while you are at it? Having said that, thanks a lot for all your work on this. I look forward to using your DNS library in our apps.

[bluejekyll]

This is a great suggestion. I mostly opened this to capture the intention to do this. I'm working on the change right now, so seems like a good time to do it.

I might drop the core and instead just do the server and client.

As to the crate names, I'm planning on trust-dns for client and trust-dns-server, with a future trust-dns-cache

edit: updated client, it will maintain the trust-dns library name.

[rushmorem]

When I first started checking out Rust, a DNS library was one of the things I was interested in. Our apps are currently written in Go. We run a custom DNS server utilizing miekg's awesome library. We also use the same library in some of our other services that are not DNS servers, to lookup DNS records.

At first, and for quite a while at that, I thought trust-dns was just a binary. It was only recently that I realized we can use it as a library to perform DNS queries. It's still not clear to me though how we can use use it to build a custom server or extend it fetch the DNS records from other sources.

[bluejekyll]

We run a custom DNS server utilizing miekg's awesome library

I'm not familiar with that. Can you describe some of the features you like in that? I'd be happy to look at supporting some of them.

It's still not clear to me though how we can use use it to build a custom server or extend it fetch the DNS records from other sources

I'm not sure exactly what you mean by this. In the next release I'm going to have native support for futures.rs and the Tokio application framework. This should allow for easy integration into Rust libraries built on the same architecture.

Here are some examples of using that:

https://github.com/bluejekyll/trust-dns/blob/85c6b8ebe79a64407f5a97a9d40cddc4ba81cb64/src/client/client_future.rs#L788

I'm not sure when I'll get this release out at the moment, but probably in the next few weeks for the client impls.

As to the Server, I haven't started on the futures impl, for that yet, but again, I have some tests which show how to create a server, and stick stuff into the Authority:

https://github.com/bluejekyll/trust-dns/blob/85c6b8ebe79a64407f5a97a9d40cddc4ba81cb64/src/server/server.rs#L518

But expect a lot of that to change in a little bit as I move to futures. I have been thinking of building in dynamic library loading to support custom resource record evaluation or other such plugins.

[rushmorem]

I'm not familiar with that. Can you describe some of the features you like in that? I'd be happy to look at supporting some of them.

I was referring to this library. It's the go to DNS library in Go whether you are writing DNS servers or DNS clients. What I like about it is that it makes no assumptions about what you will be using it for. It just exposes an API you can use and gets out of your way.

It's modeled around Go's standard net/http library. Think of it as hyper for DNS.

I'm not sure exactly what you mean by this.

We run a cluster of servers across two datacenters. We store our DNS records in a distributed database. We also have some unique features that are not available in standard DNS servers to cater to our market's needs.

When a DNS request comes in, the library (which comes with a builtin server by the way) parses it and forwards the DNS message to our handler as a normal Go type. We then process it and pass a DNS message back.

In the next release I'm going to have native support for futures.rs and the Tokio application framework. This should allow for easy integration into Rust libraries built on the same architecture.

Yes, I noticed your work on implementing futures.rs. This is exciting to say the least. Once again, thanks for this.

[bluejekyll]

It's modeled around Go's standard net/http library. Think of it as hyper for DNS.

When I started this, it wasn't an intention of mine to create a library like this, more to write a full server implementation. I can definitely work on making portions of the library more flexible and componentized as necessary.

When a DNS request comes in, the library (which comes with a builtin server by the way) parses it and forwards the DNS message to our handler as a normal Go type

Ok, I totally understand what you want. We can file another issue for that. I do have a structure for Messages of that form (I need to clean up the docs):

https://docs.rs/trust-dns/0.7.3/trust_dns/op/message/struct.Message.html

And then you want a pluggable trait interface for the backing Catalog/Authority:

https://docs.rs/trust-dns/0.7.3/trust_dns/authority/struct.Catalog.html
https://docs.rs/trust-dns/0.7.3/trust_dns/authority/struct.Authority.html

Which you could use to read/write to the distributed db. I don't have a generic trait for those right now or a way to swap out the implementations, but it should be easy to make that possible.

[rushmorem]

When I started this, it wasn't an intention of mine to create a library like this, more to write a full server implementation.

Yes I realize this. You mostly market it as such which is what gave me my initial impression. I think something like this would roughly equate to the trust-dns/core crate that you are thinking of dropping. I hope I can persuade you to reconsider. You can always implement your full blown DNS server on top of that library as a separate crate, perhaps trust-dns/server.

The guy who made that Go library has a full blown DNS server too called CoreDNS. It's not only a DNS server, it's also a load balancer. We use it too for exactly that capability. Our custom DNS servers are actually sitting in the background as back-ends. I think this is pretty neat as there are not many load balancers for UDP out there.

[rushmorem]

I have filed a separate issue. Thanks for the pointers. I will dig into those structs and traits.

[bluejekyll]

Ok, I've gone with this strategy

trust-dns/client == trust-dns (crate)
trust-dns/server == trust-dns-server (crate)

I'm not currently planning on any others at the moment... there will probably be a resolver in not too long, but that's a separate task.