This ensures that configured NTAs exclude not only the listed domain but
also all domains below it from DNSSEC validation -- except if a positive
trust anchor is defined below (as suggested by RFC7647, section 1.1)
Fixes: #5048
Drop the TEST_DATA_DIR macro as this was using alloca() within a
function call which is allegedly unsafe. So add a "suffix" argument to
get_testdata_dir() instead and call that directly.
Embedding sd_id128_t's in constant strings was rather cumbersome. We had
SD_ID128_CONST_STR which returned a const char[], but it had two problems:
- it wasn't possible to statically concatanate this array with a normal string
- gcc wasn't really able to optimize this, and generated code to perform the
"conversion" at runtime.
Because of this, even our own code in coredumpctl wasn't using
SD_ID128_CONST_STR.
Add a new macro to generate a constant string: SD_ID128_MAKE_STR.
It is not as elegant as SD_ID128_CONST_STR, because it requires a repetition
of the numbers, but in practice it is more convenient to use, and allows gcc
to generate smarter code:
$ size .libs/systemd{,-logind,-journald}{.old,}
text data bss dec hex filename
1265204 149564 4808 1419576 15a938 .libs/systemd.old
1260268 149564 4808 1414640 1595f0 .libs/systemd
246805 13852 209 260866 3fb02 .libs/systemd-logind.old
240973 13852 209 255034 3e43a .libs/systemd-logind
146839 4984 34 151857 25131 .libs/systemd-journald.old
146391 4984 34 151409 24f71 .libs/systemd-journald
It is also much easier to check if a certain binary uses a certain MESSAGE_ID:
$ strings .libs/systemd.old|grep MESSAGE_ID
MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x
MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x
MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x
MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x
$ strings .libs/systemd|grep MESSAGE_ID
MESSAGE_ID=c7a787079b354eaaa9e77b371893cd27
MESSAGE_ID=b07a249cd024414a82dd00cd181378ff
MESSAGE_ID=641257651c1b4ec9a8624d7a40a9e1e7
MESSAGE_ID=de5b426a63be47a7b6ac3eaac82e2f6f
MESSAGE_ID=d34d037fff1847e6ae669a370e694725
MESSAGE_ID=7d4958e842da4a758f6c1cdc7b36dcc5
MESSAGE_ID=1dee0369c7fc4736b7099b38ecb46ee7
MESSAGE_ID=39f53479d3a045ac8e11786248231fbf
MESSAGE_ID=be02cf6855d2428ba40df7e9d022f03d
MESSAGE_ID=7b05ebc668384222baa8881179cfda54
MESSAGE_ID=9d1aaa27d60140bd96365438aad20286
This restores behaviour of 53fda2bb933694c9bdb1bbf1f5583e39673b74b2: for
mDNS (and mDNS only) we'll match replies to transactions honouring ANY
matches.
The array doesn't grow dynamically, hence pick the right size at the
moment of allocation. Let's simply multiply the number of addresses of
this link by 2, as that's how many RRs we maintain for it.
It is useful to package test-* binaries and run them as root under
autopkgtest or manually on particular machines. They currently have a
built-in hardcoded absolute path to their test data, which does not work
when running the test programs from any other path than the original
build directory.
By default, make the tests look for their data in
<test_exe_directory>/testdata/ so that they can be called from any
directory (provided that the corresponding test data is installed
correctly). As we don't have a fixed static path in the build tree (as
build and source tree are independent), set $TEST_DIR with "make check"
to point to <srcdir>/test/, as we previously did with an automake
variable.
Moe test-resolve's test data from src/resolve/test-data to
test/test-resolve/ to be consistent with test/test-{execute,path}/. This
will make it easier to make the tests relocatable.
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().
This reverts a part of 53fda2bb933694c9bdb1bbf1f5583e39673b74b2:
On classic DNS and LLMNR ANY requests may be replied to with any kind of
RR, and the reply does not have to be comprehensive: these protocols
simply define that if there's an RRset that can answer the question,
then at least one should be sent as reply, but not necessarily all. This
means it's not safe to "merge" transactions for arbitrary RR types into
ANY requests, as the reply might not answer the specific question.
As the merging is primarily an optimization, let's undo this for now.
This logic may be readded later, in a way that only applies to mDNS.
Also, there's an OOM problem with this chunk: dns_resource_key_new()
might fail due to OOM and this is not handled. (This is easily removed
though, by using DNS_RESOURCE_KEY_CONST()).
Previously, we'd only synthesize RRs for the LLMNR and mDNS versions of
the hostnames (i.e. the first label of the kernel hostname, as well as
the first label of the kernel hostname suffixed with .local). With this
change, we also synthesize an RR for the full hostname, which is
relevant in case it has more than one label.
Fixes: #5041
Clients expect us to follow CNAMEs for them, hence do so. On the first
iteration start putting together a packet, and then keep adding data we
acquire through CNAMEs to it, until we finally send it off.
Fixes: #3826
And then show it, to make things a bit friendlier to the user if we fail
acquiring some props.
In fact, this fixes a number of actual bugs, where we used an error
structure for output that we actually never got an error in.
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>
gperf-3.1 generates lookup functions that take a size_t length
parameter instead of unsigned int. Test for this at configure time.
Fixes: https://github.com/systemd/systemd/issues/5039
Fix wrong condition test in manager_etc_hosts_lookup(), which caused it to
return an IPv4 answer when an IPv6 question was asked, and vice versa.
Also only return success if we actually found any A or AAAA record.
In systemd-resolved.service(8), point out that /etc/hosts mappings only
affect address-type lookups, not other types.
The test case currently disables DNSSEC in resolved, as there is a bug
where "-t MX" fails due to "DNSSEC validation failed" even after
"downgrading to non-DNSSEC mode". This should be dropped once that bug
gets fixed.
Fixes#4801
r was not initialized and would be used if "tcp" was the only option
used for the stub. We should initialize it to 0 to indicate that no
error happened in the udp case.
When running in a user namespace without private networking, resolved would
fail to start. There isn't much difference between EADDRINUSE and EPERM,
so treat them the same, except for the warning message text.
Make sure an error is always printed… When systemd-resolved is started in a
user namespace without private network, it would fail on setsockopt, but the
error wouldn't be particularly informative:
"Failed to start manager: permission denied."
