Enumerating DNS-SD PTR resource records are a special case and
are supposed to have non-unique keys pointing to services of the
same type running on different hosts. There's no need for them
to be checked for conflicts.
Thus don't check for conflicts such RRs.
Refcounting for a RR's key is done separately from refcounting
for the RR itself, but in dns_scope_notify_conflict() we don't
do that. This may lead to a situation when a RR key put in the
conflict_queue hash as a value's key gets freed upon
cache reduction when it's still referenced by the hash.
Thus increase refcount for the key when putting it into the hash
and unreference it upon removing from the hash.
Closes#6456
The config example contains wrong specificator for hostname.
It should be %H instead of %h as documented in the man page.
Use correct specificator for hostname.
It might happen that a DNS-SD service doesn't include local host's
name in its RR keys and still conflicts with a remote service.
In this case try to resolve the conflict by changing name for
this particular service.
As discussed in RFC 6762, Section 8.2 a race condition may
happen when two hosts are probing for the same name simultaniously.
Detect and handle such race conditions.
According to RFC 6762 Section 8.2 "Simultaneous Probe Tiebreaking"
probing queries' Authority Section is populated with proposed
resource records in order to resolve possible race conditions.
From RFC 6762, Section 10.2
"They (the rules about when to set the cache-flush bit) apply to
startup announcements as described in Section 8.3, "Announcing",
and to responses generated as a result of receiving query messages."
So, set the cache-flush bit for mDNS answers except for DNS-SD
service enumerattion PTRs described in RFC 6763, Section 4.1.
According to p5.3 of RFC6762 (Multicast DNS) one mDNS query message
can contain more than one question sections.
Generate answers for all found questions and put them to a reply
message.
Otherwise we fail an assertion down the path since t->timeout_event_source is NULL
and it's the "other" transaction that's supposed to have the event source.
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
By default all sent multicast packets are looped back to the
sending host. And since the code that adds the mDNS socket to
the mDNS multicast group is the same as for LLMNR I decided
that for now it'd be safer to filter looped back packets in the
application than to switch loopback off. Because I don't know
what would be the implications for LLMNR with loopback switched off.
I suspect that loopback can be disabled for LLMNR safely too and the
function manager_our_packet() is not really needed. But I'd
prefer to do it in another patchset.
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
Currently resolving mDNS requests doesn't work because in
dns_transaction_process_reply() no answer gets installed into
mDNS transactions.
When receiving a mDNS reply we should not check for query section
equivalence of the request and its corresponsing response. But still
we need to install answers to mDNS transactions to make it possible
to actually resolve mDNS requests.
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
Dmitry Rozhkov