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.
This might very well happen due to races between joining multicast
groups and network configuration and such, let's not complain, but just
drop the messages at debug level.
Fixes: #7527
Previously, `SO_REUSEADDR` is set before `bind`-ing socket, Thus,
even if another mDNS stack (e.g. avahi) is running, `bind` always
success and we cannot detect the other stack.
By this commit, we first try to `bind` without `SO_REUSEADDR`,
and if it fails, show warning and retry with `SO_REUSEADDR`.
This restores behaviour of 53fda2bb933694c9bdb1bbf1f5583e39673b74b2: for
mDNS (and mDNS only) we'll match replies to transactions honouring ANY
matches.
We don't actually make use of the return value for now, but it matches
our coding style elsewhere, and it actually shortens our code quite a
bit.
Also, add a missing OOM check after dns_answer_new().
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>
networkd previously knew an enum "ResolveSupport" for configuring
per-interface LLMNR support, resolved had a similar enum just called
"Support", with the same value and similar pasers.
Unify this, call the enum ResolveSupport, and port both daemons to it.
When storing negative responses, clamp the SOA minimum TTL (as suggested
by RFC2308) to the TTL of the NSEC/NSEC3 RRs we used to prove
non-existance, if it there is any.
This is necessary since otherwise an attacker might put together a faked
negative response for one of our question including a high-ttl SOA RR
for any parent zone, and we'd use trust the TTL.
This large patch adds a couple of mechanisms to ensure we get NSEC3 and
proof-of-unsigned support into place. Specifically:
- Each item in an DnsAnswer gets two bit flags now:
DNS_ANSWER_AUTHENTICATED and DNS_ANSWER_CACHEABLE. The former is
necessary since DNS responses might contain signed as well as unsigned
RRsets in one, and we need to remember which ones are signed and which
ones aren't. The latter is necessary, since not we need to keep track
which RRsets may be cached and which ones may not be, even while
manipulating DnsAnswer objects.
- The .n_answer_cachable of DnsTransaction is dropped now (it used to
store how many of the first DnsAnswer entries are cachable), and
replaced by the DNS_ANSWER_CACHABLE flag instead.
- NSEC3 proofs are implemented now (lacking support for the wildcard
part, to be added in a later commit).
- Support for the "AD" bit has been dropped. It's unsafe, and now that
we have end-to-end authentication we don't need it anymore.
- An auxiliary DnsTransaction of a DnsTransactions is now kept around as
least as long as the latter stays around. We no longer remove the
auxiliary DnsTransaction as soon as it completed. THis is necessary,
as we now are interested not only in the RRsets it acquired but also
in its authentication status.
Add the packet dispatching routine for mDNS.
It differs to what LLMNR and DNS dispatchers do in the way it matches
incoming packets. In mDNS, we actually handle all incoming packets,
regardless whether we asked for them earlier or not.
