mirror of
https://github.com/hickory-dns/hickory-dns.git
synced 2026-04-25 03:05:51 +03:00
[GH-ISSUE #552] Question: usage of Service Discovery feature #531
Labels
No labels
blocked
breaking-change
bug
bug:critical
bug:tests
cleanup
compliance
compliance
compliance
crate:all
crate:client
crate:native-tls
crate:proto
crate:recursor
crate:resolver
crate:resolver
crate:rustls
crate:server
crate:util
dependencies
docs
duplicate
easy
easy
enhance
enhance
enhance
feature:dns-over-https
feature:dns-over-quic
feature:dns-over-tls
feature:dnsssec
feature:global_lb
feature:mdns
feature:tsig
features:edns
has workaround
ops
perf
platform:WASM
platform:android
platform:fuchsia
platform:linux
platform:macos
platform:windows
pull-request
question
test
tools
tools
trust
unclear
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/hickory-dns#531
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @quilir on GitHub (Aug 23, 2018).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/552
I tried to use DNS-SD feature of the crate (yeah, I know that it is not completely stable). But I encountered a problem - the test case is not working.
There is the log:
https://gist.github.com/destruktiw/185c711f24da459a2400a6683a70e5a0
I do not know why list_services() methot use google DNS to resolve local services addresses.
All I need is a possibility to list services in local services via mDNS. Is it possible in the current version of trust-dns (with
mdnsfeature of course).@bluejekyll commented on GitHub (Aug 23, 2018):
Thanks for the report. This is helpful for trying to stabilize the repo. I’ll take a look a little later.
.local.Should definitely not go to remote systems. I think the configuration for the test is just using a resolver with google as the default upstream recursive resolver, anything ending in.local.should never got anywhere but to the mDNS interface.This happens here: https://github.com/bluejekyll/trust-dns/blob/master/resolver/src/name_server_pool.rs#L647
(Side note: In the future, could I ask that logs be posted as gists? Or directly in the issue? Pastebin is really annoying on the phone)
@quilir commented on GitHub (Aug 23, 2018):
I made a mistake and haven't really used
mdnsfeature. Now I run crate with following changes:#[ignore]before the testdefault = ["mdns"]in features section in Cargo.tomlNow it gives me a timeout:
https://gist.github.com/destruktiw/d139f08c12bf761294f5a609b82fcd31
@bluejekyll commented on GitHub (Aug 23, 2018):
FYI: to run ignored tests, this one, you can always do:
cargo test --package trust-dns-resolver --lib dns_sd::tests::test_list_services -- --ignoredcould you run this test in the integration-tests directory?
cargo test --features=mdns --test mdns_tests test_query_mdns_ipv4and see if that works?@quilir commented on GitHub (Aug 23, 2018):
I can't compile that package for tests even without any extra flags (it was tested on hard-reseted repo):
And thanks for the shortcut command - it will ease my life.
@bluejekyll commented on GitHub (Aug 25, 2018):
I have never seen that one before. It's definitely functioning in travis-ci, which is a 64bit linux environment.
I think I've seen similar issues like that when you have the IDE building as well as trying to run tests from the CLI. I would recommend trying to clean,
cargo cleanand then try testing again. If that doesn't work, maybecargo update.@quilir commented on GitHub (Aug 27, 2018):
@bluejekyll your instructions helped and integration test has passed successfully.
I encountered cargo bug on my PC that features does not work properly, but I used default feature walkaround (this issue is not worth to talk about in this topic).
Still, test_list_services() does not work properly. It compiles and does something, but doesn't list services that definitely are in the local network.
Eg:
avahi comand:
avahi-browse _http._tcp. -d locallists service immidetalyin test_list_services()
list_services("_http._tcp.local.")ends by reaching timeout (5-10s).@bluejekyll commented on GitHub (Aug 27, 2018):
Hm. Yes. I’m not yet sure what’s going on, and why we’re not getting a full listing. My guess is that the filter on the listener is setup slightly incorrectly, and being too restrictive.
Let’s leave this open as a tracking issue for this. I won’t have time to track this down for a little while, but I’d be happy to point you to areas of the code that would need to be debugged.
@quilir commented on GitHub (Aug 27, 2018):
If you could guide me where the bug may be hiding, I will try to find it in my spare time.
@bluejekyll commented on GitHub (Aug 28, 2018):
So I think this is going to take a bit of introspection into the what's going on with the network... tcpdump, etc. A thought I've had is that the mDNS code is being too restrictive on the messages it's receiving. This could be due to the bind call being too specific:
github.com/bluejekyll/trust-dns@6777f648df/proto/src/multicast/mdns_stream.rs (L183)or possibly something wrong with the join call:
github.com/bluejekyll/trust-dns@6777f648df/proto/src/multicast/mdns_stream.rs (L214)Yet another possibility is that the packets aren't making it to the process, b/c there's another mDNS responder that's getting the packets (this one would require us to not ask for mDNS responses in the request packets).
In the protocol layer, this is another option that could be an issue, which is that we're returning early, before we've waited long enough to get all the packets (I don't think this is it, but it would be the simplest bug if so):
github.com/bluejekyll/trust-dns@6777f648df/proto/src/xfer/dns_multiplexer.rs (L430-L433)I have an intention to remove that smallvec buffer, and change it out for a response stream that clients have a Stream into the mDNS interface (the current impl isn't very async).
Popping up the stack, currently we're using OneShot queries, and it might be that this doesn't get us enough responses, for some reason:
github.com/bluejekyll/trust-dns@6777f648df/resolver/src/name_server_pool.rs (L280)Right now I have a lot of theories, but I've not had the time to try and narrow it down. If you haven't yet, it would be helpful to read this RFC: https://tools.ietf.org/html/rfc6762
@quilir commented on GitHub (Aug 28, 2018):
I have probably found one bug in the code.
Currently, one-shot queries have "QM" (multicast) question inside their body instead of "QU" (unicast). It is defined by a bit flag inside the packet. After receiving that type of question, mDNS responders send the response via multicast (224.0.0.251:5353).
The one-shot client doesn't see anything, because he mustn't listen on 5353 port, and stops waiting when timeout is reached.
I haven't found query-building part of code yet, so I don't know if it will solve this issue :/
Well, "very-non-standard" OneShotJoin goes further in test and fails at lookup_srv().
@bluejekyll commented on GitHub (Aug 28, 2018):
Serialization occurs here:
github.com/bluejekyll/trust-dns@6777f648df/proto/src/xfer/dns_multiplexer.rs (L354-L369)We may need to revisit some choices on where serialization is ocurring to make sure individual transports are fully capable of setting flags like this. This could very well be an issue and a pretty big oversight on my part. It wouldn't be too hard to move serialization down deeper into the individual transports, but would make this a bigger change.
A less invasive change would be to crate a new DnsHandle type that would be used here:
github.com/bluejekyll/trust-dns@6777f648df/resolver/src/name_server_pool.rs (L298)and that could manipulate flags in the message before sending.
Yes, that's an attempt to get us the best of both worlds...