Add support for RFC 6762 legacy unicast responses

[luqs1]

Hi, thanks for your package. I just wanted to contribute some code that my clanker wrote up. It helped me get mdns working when hosted on my macbook from my pixel 8. The rest of this PR is AI generated but hopefully still useful to read haha.

Browsers on Android can't resolve .local names published by mdns-sd. They resolve names published by Apple's mDNSResponder fine, and an NsdManager-based app on the same phone sees the records mdns-sd is publishing — so the records are reaching the phone, the browser just isn't getting them.

The reason is that Android's getaddrinfo (Mainline DnsResolver, since November 2021) issues mDNS queries from an ephemeral source port and waits for a unicast reply on that port. This is the "legacy/one-shot" case described in RFC 6762 §6.7. mdns-sd today always replies via multicast from port 5353 — so the answer goes to 224.0.0.251:5353, which the ephemeral getaddrinfo socket isn't listening on, and the lookup times out. The author's own comment at service_daemon.rs:790 flags this:

// Here we set the TTL to 255 for multicast as we don't support unicast yet.

Same shape on the wire. Before this patch, with my Mac publishing knock-knock.local:

phone fe80::bc35:….50742 > ff02::fb.5353: A (QM)? knock-knock.local.
mac   fe80::186a:….5353  > ff02::fb.5353: 4/0/0 knock-knock.local. AAAA …  ← phone never sees this

After:

mac   fe80::186a:….5353  > fe80::bc35:….50742: 1/0/0 A 192.168.1.247  ← unicast back to the ephemeral port

Chrome, Firefox, and DuckDuckGo on Android 16 all load http://knock-knock.local:8000/ immediately after the patch. macOS and iOS were never broken — their resolvers go through Bonjour, not the legacy unicast path.

What's in the diff

Three logically-distinct changes, all in service_daemon.rs plus a small helper in dns_parser.rs. Happy to split into separate PRs if you'd rather land them independently — they're somewhat orthogonal but all needed for the Android case.

Routing the response unicast for legacy queriers. pktinfo.addr_src already had the full SocketAddr of the querier; we were calling .ip() on it and dropping the port. Plumb the full address through handle_query, and when the source port isn't 5353, send the response unicast to it instead of multicasting. New unicast_on_intf helper mirrors multicast_on_intf for the unicast path. All other callers of send_dns_outgoing* pass None for the new parameter and behave exactly as before.

Echoing the question and clearing the cache-flush bit on legacy responses. §6.7 plus §10.2 — strict legacy resolvers can drop responses that omit the original question section or set the unique bit. Added DnsOutgoing::clear_cache_flush_bits() to walk answers, additionals, and authorities and reset.

Picking the address set by question type, not socket family. Independent bug found while debugging the above. Today the address set is selected from is_ipv4 = querier_ip.is_ipv4() — i.e. based on which socket received the question. So an A question received over IPv6 transport gets answered with AAAA records (correctly tagged by ip_address_rr_type, but the wrong record type for the question that was asked). Android's getaddrinfo happily sends both A and AAAA queries over its preferred IPv6 mDNS socket, so this was the second reason resolution didn't complete after the unicast fix landed. Now RRType::A returns IPv4 addresses, RRType::AAAA returns IPv6 addresses, RRType::ANY returns both, regardless of which socket the question came in on.

While I was in there I also flipped a return to continue on the empty-addrs branch — the previous code bailed out of the entire handle_query if any single A/AAAA question on the interface had no matching addresses, which silently dropped answers for sibling questions in the same query.

What I didn't change

• The response TTL is unchanged. RFC §6.7 recommends ≤10s for legacy unicast; in practice modern resolvers don't seem to care, and Android accepts the existing default fine. Easy enough to add later behind the same unicast_dest.is_some() branch.
• The QU bit on questions is still being masked away in dns_parser.rs:281-284 as cache-flush. Honoring QU is a stricter form of the same problem and is orthogonal — it only matters for queriers sourcing from port 5353 that explicitly request unicast (see also draft Implemented unicast responses to direct unicast, unicast questions and legacy unicast queries. #190, which addressed the QU case but not the legacy port case). Could be a follow-up.
• I have not added unit tests. The behavior is cleanly observable on the wire — open an ephemeral UDP socket, send a question, assert the reply arrives unicast on that socket — happy to write that if you'd like before merge.

Testing

Reproduced and verified on an Android 16 Pixel 8 against a macOS 15.x host running this branch, with a small axum HTTP server bound to 0.0.0.0:8000 whose mDNS hostname is published as knock-knock.local. via ServiceInfo::new(...).enable_addr_auto().

• Before: Chrome / Firefox / DuckDuckGo time out on http://knock-knock.local:8000/. NsdManager apps see the service. macOS dns-sd -q knock-knock.local resolves immediately.
• After: all three browsers load on first attempt. macOS and iOS unaffected. tcpdump confirms responses go unicast to the querier's source port for legacy queriers and stay multicast for proper mDNS clients.

[keepsimple1]

Thanks for your PR. Nice fixes and a real useful enhancement!

Yes please add a test and then move it out of Draft state. I'd keep all changes together instead of separated PRs as they are needed for solving the same use case.

[keepsimple1]

Nice fix! Just a note that now an ANY query received on IPv4 socket can return AAAA records as well. I think that's OK.