-
Notifications
You must be signed in to change notification settings - Fork 484
Open
Description
Description
When broadcasting an mDNS A question, it is possible that some clients not following the specs reply with a Standard Query Response, containing no answers but only additional records. This makes the querying return with GetQueryResultError::Fail
immediately, instead of continuing to wait for a response.
Expected behaviour
- Continue waiting until either:
- a matching answer (owner name == queried name, rrtype ==
A
, qclass match) is received, or - a valid authoritative negative (NSEC) for that name/type arrives, or
- the retransmit/backoff window completes without an answer.
- a matching answer (owner name == queried name, rrtype ==
- RFC 6762 §5.2 Continuous Multicast DNS Querying states that receiving one response is not necessarily an indication that there will be no more relevant responses, and describes the required backoff/retransmit behavior. In other words, don’t stop the operation until you’ve actually satisfied it (i.e., received a matching answer or decided you no longer need more).
- For unicast-only acceptance, §5.4 is explicit: a querier MUST only accept unicast responses if they answer a recently sent query that explicitly requested unicast; otherwise, silently ignore them.
Steps to reproduce
- Start resolver; issue
A some-host.local
on mDNS. - Other hosts emit answers-empty / additionals-only replies.
- Resolver stops listening immediately and returns
GetQueryResultError::Fail
. - Legitimate owner responds shortly afterward with a valid
A
, but the resolver has already given up.
MightySCollins