Martin Hoffmann

There isn’t anything yet. But I have enabled Discussions on the repository. We can give that a try and see if that works.

Will do! As a hint for now: `Resolver` (and subsequently `StubResolver`) has a method `query` that takes a question and returns a `Query` which is just a future for the...

It doesn’t fit too well at this point. If your updates are reasonably simple, you can probably do the sending using UDP sockets yourself taking inspiration from [domain-resolv/src/stub/net/udp.rs](https://github.com/NLnetLabs/domain/blob/master/domain-resolv/src/stub/net/udp.rs). If you...

I feel like UPDATE support would be a good feature for a separate module. It may also be a good reason to factor out the networking code into its own...

I’ve added an example in #65 and, incidentally, also found an issue with starting the runtime. I’ll release a new version of `domain-resolv` soon.

@pemensik Sorry, I somehow missed your question (or maybe thought you would start a discussion as suggested in #133.) The issue with `Dname::root` is that is generic over the octets...

@sigh-gone If you don’t care about any specific configuration, `StubResolver::new()` should work. The examples directory in the repository has a few examples on how to do actual lookups with it.

I’m closing the issue for now. Feel free to reopen it if you have a follow-up question.

I am not really happy with the current zonefile parser either. It is rather convoluted and, worse, slow. Plus, it only works with `Bytes` right now which isn’t ideal in...

> Are you opposed to the idea of introducing an intermediary trait to allow record data types to be built from binary strings without any zone file parser? I’d love...