Export DNS resolver for library usage about trippy

[c-git]

Thanks for explaining that I wasn't quite following what was happening. Thought I'd have to play with it a bit to understand. Thanks for saving me the time.

[fujiapple852]

@crisidev I think we should be able to do this, i'm just not sure what the right approach is.

Trippy is intended primarily as a tool but is structured as a tool built on top of a library, such that other tools could be build using the Trippy library.

In fact there is an (out of date) pr (#640) to split Trippy into different crates which may or may not happen, i'm still unsure if it is a good idea or not. See this comment for my thoughts on the topic.

So right now the library portion of Trippy does not deal with DNS at all and so the dns module is not part of the library, but is part of the tool. Therefore it doesn't make sense to re-export it in lib.rs, even though it would be trivial to do so.

I should point out that the DNS resolver in Trippy is simply a wrapper on top of the dns-lookup and trust-dns-resolver (recently rebranded as hickory-resolver) crates which do all the heavy lifting. The only things that Trippy adds is lazy background lookups and ASN lookups, which I guess maybe useful to other projects? If not then I'd recommend using those crates directly.

Aside: I would actually like to divest hickory-resolver as it is an async only library which forces Trippy to pull in the whole tokio eco-system which bloats the final executable size by a large multiple. However I am yet to find a suitable replacement library that is cross platform, non-async and of high quality so for now we stick with what we have.

[fujiapple852]

I think that given:

• Trippy is pre-1.0 and perma-unstable at this point
• No decision has been made about how to structure it going forward (tool vs tool + library)
• This is a trivial change

Then I'm ok with it for now.

PR up: #756 and this will go into 0.9.0.

[c-git]

You said trivial and I just looked at the PR and I'm like that was a lot. It's easy for you, but it's actually not easy. Required a good understanding of what needed to move where.

[fujiapple852]

Fair point @c-git !

There was one complication that makes this look more complex than it is which may be worth explaining as it crops up from time to time.

The DnsResolveMethod enum was shared between the config and dns modules. By moving the dns module into the library (and out of the tool) I had to move the DnsResolveMethod enum into the dns module as well.

However in the dns module we do not want to have to specify attributes such as ValueEnum, Deserialize and #[serde(rename_all = "kebab-case")] which are needed in the config module to support it being read from a config file.

The solution is to duplicate the type into DnsResolveMethodConfig and DnsResolveMethod and provide a conversion from the former to the latter.

This pattern is repeated for types in the tracing/config.rs module which have the same issue.

I also improved the rustdoc comments for the dns module given it's now part of the public interface.

[fujiapple852]

@crisidev I did some further refactoring of the dns module to make it more suitable to be part of the public interface. I'll merge it now as it is, please me know if it works for you.