starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 19:25:56 +03:00

[GH-ISSUE #43] Split trust-dns into multiple crates #29

New issue

Closed

opened 2026-03-07 22:18:07 +03:00 by kerem · 9 comments

kerem commented

2026-03-07 22:18:07 +03:00

Owner

Originally created by @bluejekyll on GitHub (Sep 1, 2016).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/43

move the repo into this format over time:

trust-dns/trust-dns-core/ - record serialization, no networking, etc.
trust-dns/trust-dns-client/ - futures impl of all lookup logic, optionally compile in DNSSec, etc.
trust-dns/trust-dns-server/ - authority implementations, dependency on SQLLite here, etc.
trust-dns/trust-dns-cache/ - LRU caching layer that can wrap the client, aka resolver?

edit: I realized that changing the trust-dns crate name would orphan the existing library in crates.io. My plan right now is to maintain that name for the client library, but fork out the server library.

Originally created by @bluejekyll on GitHub (Sep 1, 2016). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/43 move the repo into this format over time: `trust-dns/trust-dns-core/` - record serialization, no networking, etc. `trust-dns/trust-dns-client/` - futures impl of all lookup logic, optionally compile in DNSSec, etc. `trust-dns/trust-dns-server/` - authority implementations, dependency on SQLLite here, etc. `trust-dns/trust-dns-cache/` - LRU caching layer that can wrap the client, aka resolver? edit: I realized that changing the `trust-dns` crate name would orphan the existing library in crates.io. My plan right now is to maintain that name for the client library, but fork out the server library.

kerem

2026-03-07 22:18:07 +03:00

closed this issue
added the
enhance
label

kerem commented

2026-03-07 22:18:09 +03:00

Author

Owner

@rushmorem commented on GitHub (Oct 5, 2016):

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.

@rushmorem commented on GitHub (Oct 5, 2016): 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.

kerem commented

2026-03-07 22:18:09 +03:00

Author

Owner

@bluejekyll commented on GitHub (Oct 5, 2016):

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.

@bluejekyll commented on GitHub (Oct 5, 2016): 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.

kerem commented

2026-03-07 22:18:09 +03:00

Author

Owner

@rushmorem commented on GitHub (Oct 5, 2016):

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.

@rushmorem commented on GitHub (Oct 5, 2016): 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.

kerem commented

2026-03-07 22:18:09 +03:00

Author

Owner

@bluejekyll commented on GitHub (Oct 5, 2016):

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:

github.com/bluejekyll/trust-dns@85c6b8ebe7/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:

github.com/bluejekyll/trust-dns@85c6b8ebe7/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.

@bluejekyll commented on GitHub (Oct 5, 2016): > 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.

kerem commented

2026-03-07 22:18:09 +03:00

Author

Owner

@rushmorem commented on GitHub (Oct 5, 2016):

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.

@rushmorem commented on GitHub (Oct 5, 2016): > 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](https://github.com/miekg/dns). It's the go to [DNS library](https://godoc.org/github.com/miekg/dns) 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](http://hyper.rs) 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](https://godoc.org/github.com/miekg/dns#Msg). 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.

kerem commented

2026-03-07 22:18:09 +03:00

Author

Owner

@bluejekyll commented on GitHub (Oct 5, 2016):

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.

@bluejekyll commented on GitHub (Oct 5, 2016): > 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.

kerem commented

2026-03-07 22:18:09 +03:00

Author

Owner

@rushmorem commented on GitHub (Oct 5, 2016):

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 commented on GitHub (Oct 5, 2016): > 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](https://github.com/miekg/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.

kerem commented

2026-03-07 22:18:09 +03:00

Author

Owner

@rushmorem commented on GitHub (Oct 5, 2016):

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

@rushmorem commented on GitHub (Oct 5, 2016): I have filed a separate issue. Thanks for the pointers. I will dig into those structs and traits.

kerem commented

2026-03-07 22:18:09 +03:00

Author

Owner

@bluejekyll commented on GitHub (Nov 6, 2016):

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.

@bluejekyll commented on GitHub (Nov 6, 2016): 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.

kerem referenced this issue

2026-03-16 01:53:28 +03:00

[PR #29] [MERGED] fixes #27: remove implicit case conversion of labels #1196