starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-24 18:55:55 +03:00

[GH-ISSUE #1065] Unable to resolve using MDNS. multithreaded_runtime example hangs. #595

New issue

Open

opened 2026-03-15 23:21:09 +03:00 by kerem · 4 comments

kerem commented

2026-03-15 23:21:09 +03:00

Owner

Originally created by @dawid-nowak on GitHub (Apr 7, 2020).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1065

Unable to resolve using MDNS. multithreaded_runtime example hangs :

[2020-04-07T15:48:11Z DEBUG trust_dns_proto::xfer::dns_handle] querying: ginger.local A
[2020-04-07T15:48:11Z DEBUG trust_dns_resolver::name_server::name_server] reconnecting: NameServerConfig { socket_addr: V4(224.0.0.251:5353), protocol: Mdns, tls_dns_name: None }
[2020-04-07T15:48:11Z DEBUG trust_dns_resolver::name_server::connection_provider] connection-provider for mdns NameServerConfig { socket_addr: V4(224.0.0.251:5353), protocol: Mdns, tls_dns_name: None }
[2020-04-07T15:48:11Z DEBUG trust_dns_proto::multicast::mdns_stream] binding sending stream 2 to 0.0.0.0:11078
[2020-04-07T15:48:11Z DEBUG trust_dns_proto::multicast::mdns_stream] preparing sender 2 on: 0.0.0.0:11078
[2020-04-07T15:48:11Z DEBUG trust_dns_proto::xfer] enqueueing message: [Query { name: Name { is_fqdn: false, labels: [ginger, local] }, query_type: A, query_class: IN }]

and nothing shows in Wireshark network traces

To Reproduce
change:
let names = &["www.google.com", "www.reddit.com", "www.wikipedia.org","ginger.local"];
execute:
trust-dns/crates/resolver$ export RUST_LOG=debug; cargo run --features mdns --example multithreaded_runtime

Expected behavior
I would at least expect that i will see MDNS request in wireshark traces.
ping gigner.local
and
resolvectl ginger.local
do show up in wireshark traces

System:

OS: Ubuntu 19.10
Architecture: x86_64

Version:
Crate: resolver
Version: master

Originally created by @dawid-nowak on GitHub (Apr 7, 2020). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1065 **Unable to resolve using MDNS. multithreaded_runtime example hangs :** [2020-04-07T15:48:11Z DEBUG trust_dns_proto::xfer::dns_handle] querying: ginger.local A [2020-04-07T15:48:11Z DEBUG trust_dns_resolver::name_server::name_server] reconnecting: NameServerConfig { socket_addr: V4(224.0.0.251:5353), protocol: Mdns, tls_dns_name: None } [2020-04-07T15:48:11Z DEBUG trust_dns_resolver::name_server::connection_provider] connection-provider for mdns NameServerConfig { socket_addr: V4(224.0.0.251:5353), protocol: Mdns, tls_dns_name: None } [2020-04-07T15:48:11Z DEBUG trust_dns_proto::multicast::mdns_stream] binding sending stream 2 to 0.0.0.0:11078 [2020-04-07T15:48:11Z DEBUG trust_dns_proto::multicast::mdns_stream] preparing sender 2 on: 0.0.0.0:11078 **[2020-04-07T15:48:11Z DEBUG trust_dns_proto::xfer] enqueueing message: [Query { name: Name { is_fqdn: false, labels: [ginger, local] }, query_type: A, query_class: IN }]** and nothing shows in Wireshark network traces **To Reproduce** change: **let names = &["www.google.com", "www.reddit.com", "www.wikipedia.org","ginger.local"];** execute: trust-dns/crates/resolver$ export RUST_LOG=debug; cargo run --features mdns --example multithreaded_runtime **Expected behavior** I would at least expect that i will see MDNS request in wireshark traces. ping gigner.local and resolvectl ginger.local do show up in wireshark traces **System:** - OS: Ubuntu 19.10 - Architecture: x86_64 **Version:** Crate: resolver Version: master

kerem added the

bug

feature:mdns

labels

2026-03-15 23:21:09 +03:00

kerem commented

2026-03-15 23:21:20 +03:00

Author

Owner

@bluejekyll commented on GitHub (Apr 7, 2020):

mDNS is highly experimental, and has a bunch of known issues in trust-dns today.

@bluejekyll commented on GitHub (Apr 7, 2020): mDNS is highly experimental, and has a bunch of known issues in trust-dns today.

kerem commented

2026-03-15 23:21:25 +03:00

Author

Owner

@bluejekyll commented on GitHub (Apr 7, 2020):

See https://github.com/bluejekyll/trust-dns/labels/feature%3Amdns

@bluejekyll commented on GitHub (Apr 7, 2020): See https://github.com/bluejekyll/trust-dns/labels/feature%3Amdns

kerem commented

2026-03-15 23:21:30 +03:00

Author

Owner

@dawid-nowak commented on GitHub (Apr 7, 2020):

understood;
i was digging into it further but i am getting lost in channels :)
i think the problem is in udp_stream.rs

impl<S: UdpSocket + Send + 'static> Stream for UdpStream<S> {
    type Item = Result<SerialMessage, io::Error>;

    fn poll_next(mut self: Pin<&mut Self>, cx: &mut Context) -> Poll<Option<Self::Item>> {
...
**        while let Poll::Ready(Some(message)) = outbound_messages.as_mut().poll_peek(cx) {**

the poll result is always Pending and the code never sends a packet out, then it tries to receive a packet that never arrives.

So i suppose two questions?

where is the other side of outbound_messages channel ?
is it possible to set a timeout on a socket for mdns ? where is that socket created ?

@dawid-nowak commented on GitHub (Apr 7, 2020): understood; i was digging into it further but i am getting lost in channels :) i think the problem is in udp_stream.rs ``` impl<S: UdpSocket + Send + 'static> Stream for UdpStream<S> { type Item = Result<SerialMessage, io::Error>; fn poll_next(mut self: Pin<&mut Self>, cx: &mut Context) -> Poll<Option<Self::Item>> { ... ** while let Poll::Ready(Some(message)) = outbound_messages.as_mut().poll_peek(cx) {** ``` the poll result is always Pending and the code never sends a packet out, then it tries to receive a packet that never arrives. So i suppose two questions? 1. where is the other side of outbound_messages channel ? 2. is it possible to set a timeout on a socket for mdns ? where is that socket created ?

kerem commented

2026-03-15 23:21:35 +03:00

Author

Owner

@bluejekyll commented on GitHub (Apr 7, 2020):

It makes me happy that you want to look into this! I'll give you a brain dump as best as I can, it's been a while since I worked on that code (and make sure to review the other issues in this area).

The main implementation for the socket management happens in this module: https://github.com/bluejekyll/trust-dns/tree/master/crates/proto/src/multicast

For the resolver, the mDNS initial request happens here: https://github.com/bluejekyll/trust-dns/blob/master/crates/resolver/src/name_server/name_server_pool.rs#L305

The streams are constructed here, which is where the initial channel is created: https://github.com/bluejekyll/trust-dns/blob/master/crates/resolver/src/name_server/connection_provider.rs#L179-L195

As to why the query isn't being issued on the network, I'm not really sure why that would happen. There are some issues with this implementation. One such thing is that many systems have a mDNSresponder running locally, the multicast configuration for those don't easily allow for more than one on a system to be running. This is why I've picked the OneShot configuration for the mDNS configuration in the Resolver, since spawning something competing with the system mDNSResponder is tricky.

I hope this helps.

@bluejekyll commented on GitHub (Apr 7, 2020): It makes me happy that you want to look into this! I'll give you a brain dump as best as I can, it's been a while since I worked on that code (and make sure to review the other issues in this area). The main implementation for the socket management happens in this module: https://github.com/bluejekyll/trust-dns/tree/master/crates/proto/src/multicast For the resolver, the mDNS initial request happens here: https://github.com/bluejekyll/trust-dns/blob/master/crates/resolver/src/name_server/name_server_pool.rs#L305 The streams are constructed here, which is where the initial channel is created: https://github.com/bluejekyll/trust-dns/blob/master/crates/resolver/src/name_server/connection_provider.rs#L179-L195 As to why the query isn't being issued on the network, I'm not really sure why that would happen. There are some issues with this implementation. One such thing is that many systems have a mDNSresponder running locally, the multicast configuration for those don't easily allow for more than one on a system to be running. This is why I've picked the OneShot configuration for the mDNS configuration in the Resolver, since spawning something competing with the system mDNSResponder is tricky. I hope this helps.

kerem referenced this issue

2026-03-16 02:12:11 +03:00

[PR #595] [MERGED] Don't require DnsExchange in ClientFuture usage #1542