when they go down resolved prints
```
Event source mdns-ipv4 (type io) returned error, disabling
```
instead of
```
Event source n/a (type io) returned error, disabling
```
If the query get CNAME or DNAME, then the query will be restarted.
Even in that case, previously, the event source was freed and allocated
again. Let's slightly optimize it.
Fortunately, unlike the issue fixed in the previous commit, the memleak
should be superficial and not become apparent, as the queries handled
here are managed by the stub stream, and will be freed when the stream
is closed.
Just for safety, and slightly reducing the runtime memory usage by the
stub stream.
When stub stream is closed early, then queries associated to the stream
are freed. Previously, the timer event source for queries may not be
disabled, hence may be triggered with already freed query.
See also dns_stub_stream_complete().
Note that we usually not set NULL or zero when freeing simple objects.
But, here DnsQuery is large and complicated object, and the element may
be referenced in subsequent freeing process in the future. Hence, for
safety, let's set NULL to the pointer.
Since test-resolved-stream brings up a simple DNS server on 127.0.0.1:12345,
only one instance could run at a time, so it would fail when run like
`meson test -C build test-resolved-stream --repeat=1000`.
Similarly, if by chance something is up on port 12345, the test would fail.
To make the test more reliable, run it in an isolated user + network namespace.
If this fails (some distributions disable user namespaces), just run as before.
In commit 2aaf6bb6e9, an issue was fixed where
systemd-resolved could get stuck for multiple seconds waiting for incoming data,
since GnuTLS/OpenSSL can buffer a TLS record, so data could be available, but
no EPOLLIN event would be generated.
To fix this, a somewhat elaborate logic consisting on asking the TLS library
whether it had buffered data, then "faking" an EPOLLIN event was implemented.
However, there is a much simpler solution: Always read as much data as available
(i.e. until we get an event like EAGAIN when trying to read) from the stream
when we get an EPOLLIN event, instead of at most a single packet per event.
This approach does not require asking the TLS library whether it has buffered
data, and the logic is exactly the same for both the TCP and TLS case.
test-resolved-stream is fixed to avoid a latent double free bug.
Since when handling a DNS over TLS stream, the TLS library can override the
requested events through dnstls_events for handshake/shutdown purposes,
obtaining the event flags through sd_event_source_get_io_events and checking
for EPOLLIN or EPOLLOUT does not really tell us whether we want to read/write
a packet. Instead, it could just be OpenSSL/GnuTLS doing something else.
To make the logic more robust (and simpler), save the flags that tell us
whether we want to read/write a packet, and check them instead of the IO flags.
(& use uint32_t for the flags like in sd_event_source_set_io_events prototype)
Previously, the condition in on_stream_io_impl() never hit, as the
read packet is always taken from the stream in the few lines above.
Instead of the dns_stream_complete() under the condition, the stream
is unref()ed in the on_packet callback for LLMNR stream, unlike the
other on_packet callbacks.
That's quite tricky. Also, potentially, the stream may still have
queued packets to write.
This fix the condition, and drops the unref() in the on_packet callback.
C.f. https://github.com/systemd/systemd/pull/22274#issuecomment-1023708449.
Closes#22266.
Tests DnsStream event handling, both for plain TCP DNS and DNS over TLS.
The DoT test requires the "openssl s_server" command line tool to mock a simple
TLS server. Thus the test's TLS part is skipped if openssl it not available.
The test works for both DNS_OVER_TLS_USE_GNUTLS and DNS_OVER_TLS_USE_OPENSSL.
The DoT case fails due to a bug, which is fixed on the next commit.
When sending multiple DNS questions to a DNS-over-TLS server (e.g. a question
for A and AAAA records, as is typical) on the same session, the server may
answer to each question in a separate TLS record, but it may also aggregate
multiple answers in a single TLS record.
(Some servers do this very often (e.g. Cloudflare 1.0.0.1), some do it sometimes
(e.g. Google 8.8.8.8) and some seem to never do it (e.g. Quad9 9.9.9.10)).
Both cases should be handled equivalently, as the byte stream is the same, but
when multiple answers came in a single TLS record, usually the first answer was
processed, but the second answer was entirely ignored, which caused a 10s delay
until the resolution timed out and the missing question was retried.
This can be reproduced by configuring one of the offending server and running
`resolvectl query google.com --cache=no` a few times.
To be notified of incoming data, systemd-resolved listens to `EPOLLIN` events
on the underlying socket. However, when DNS-over-TLS is used, the TLS library
(OpenSSL or GnuTLS) may read and buffer the entire TLS record when reading the
first answer, so usually no further `EPOLLIN` events will be generated, and the
second answer will never be processed.
To avoid this, if there's buffered TLS data, generate a "fake" EPOLLIN event.
This is hacky, but it makes this case transparent to the rest of the IO code.
Previously, varlink or dbus methods return
io.systemd.Resolve.NoNameServers or BUS_ERROR_NO_NAME_SERVERS if an
empty hostname is provided, and thus nss-resolve returns NSS_STATUS_TRYAGAIN.
That causes getaddrinfo() returns 'Temporary failure in name resolution'
instead of 'Name or service not known'.
This makes calling varlink or dbus method with an empty hostname result
-EINVAL, and hence nss-resolve returns NSS_STATUS_NOTFOUND.
Fixes RHBZ#2039854 (https://bugzilla.redhat.com/show_bug.cgi?id=2039854).
The function `link_relevant()` is called repeatedly in `link_allocate_scopes()`.
Let's not read networkd's link file in `link_relevant()`.
Closes#22190.
In `manager_process_link()`, the function `link_update()` is called just
after `link_process_rtnl()`, and `link_update()` also calls
`link_allocate_scopes()` and `link_add_rrs()`. Hence, the calls in
`link_process_rtnl()` are redundant.
Previously, when -Ddns-over-tls=false, libopenssl was missing in the
dependency of resolved.
Also, this drops libgpg_error when it is not necessary.
Replaces #21878.
The meson default for static_library() are:
build_by_default=true, install=false. We never interact with the
static libraries, and we only care about them as a stepping-stone towards
the installable executables or libraries. Thus let's only build them if
they are a dependency of something else we are building.
While at it, let's drop install:false, since this appears to be the default.
This change would have fixed the issue with lib_import_common failing
to build too: we wouldn't attempt to build it.
In practice this changes very little, because we generally only declare static
libraries where there's something in the default target that will make use of
them. But it seems to be a better pattern to set build_by_default to false.
The variable is not useful outside of the loop (it'll always be null
after the loop is finished), so we can declare it inline in the loop.
This saves one variable declaration and reduces the chances that somebody
tries to use the variable outside of the loop.
For consistency, 'de' is used everywhere for the var name.
We get "upstream" dns server config from ~three places: /etc/resolv.conf,
config files, and runtime config via dbus. With this commit, we'll filter out
our own stub listeners if they are configured in either of the first two
sources. For /etc/resolv.conf this is done quitely, and for our own config
files, a LOG_INFO message is emitted, since this is a small inconsistency in
the config.
Setting loops like this over dbus is still allowed. The reason is that in the
past we didn't treat this as an error, and if we were to start responding with
an error, we could break a scenario that worked previously. E.g. NM sends us a
list of servers, and one happens to be the our own. We would just not use that
stub server before, but it'd still be shown in the dbus properties and such.
We would have to return error for the whole message, also rejecting the other
valid servers. I think it's easier to just keep that part unchanged.
Test case:
$ ls -l /etc/resolv.conf
-rw-r--r-- 1 root root 57 Dec 15 10:26 /etc/resolv.conf
$ cat /etc/resolv.conf
nameserver 192.168.150.1
options edns0 trust-ad
search .
$ cat /etc/systemd/resolved.conf.d/stub.conf
[Resolve]
DNSStubListenerExtra=192.168.150.1
$ resolvectl
...
Global
resolv.conf mode: foreign
DNS Servers: 192.168.150.1
Fallback DNS Servers: ...
(with the patch):
Global
resolv.conf mode: foreign
Fallback DNS Servers: ...
Commit 49ef064c8d attempts to handle
"stub loop" by switching to the next server *after the query has
been made*.
The approach may be good enough for link scopes. However, for the
manager / global scope, it is not. First of all, there are more than
one types (SYSTEM and FALLBACK) of servers it can use. Also, whether
those of type FALLBACK should be used depends.
Besides, dns_scope_good_domain() determines whether things should
be routed to a scope by checking whether the scope has a server.
The decision made would be incorrect if stubs were not filtered
beforehand.
Therefore, to avoid failing query unnecessarily, and to make sure
that extra stub listeners will not trigger unexpected and/or
inconsistent behavior, make manager_get_dns_server() do what it
should have done.
We get warnings for RSA_free(), EC_KEY_free(), EC_KEY_new(), etc. Those
functions are now deprecated and we're supposed to use the new "EVP API" that
is all the rage in openssl 3.0.
With some effort I converted dnssec_rsa_verify_raw() to use the new API. The
code is significantly longer and, if anything, less readable. The EC code is
more complicated and I assume that the EVP API version will be even more
complex. It is possiblet that I'm missing some way to call the new functions in
a better way, but the documentation is abysmal, so it's really hard to figure
out the best way. Of course there are almost no examples, and the ones that are
there are not terribly useful and are also stubs that don't do interesting
things, don't implement error handling, or memory cleanup. I'll submit my
conversion draft as a separate PR. Maybe somebody who knows openssl better
will pick it up and write a proper solution.
For now, let's just use the existing code, but suppress the warnings. The
new version just came out, so it's unlikely that the deprecated functions will
be removed any time soon.
Fixes#21666.
Follow-up for pull request #21170.
I hoped that we would drop libgcrypt fully and drop all references to the
library in meson, but this doesn't seem feasible (because of the use in
sd-journal). But let's remove it here, all the resolved code has been switched
to work either of the two libraries.