dns_transaction_request_dnssec_rr was already adjusted in 4001710365,
to allow for the return parameter to be passed uninitialized. However
this codepath was missed, meaning this function could sometimes return
success without having actually set the parameter.
Fixes: 4001710365 ("resolved: minor dnssec fixups")
Fixes: 47690634f1 ("resolved: don't request the SOA for every dns label")
gcrypt is used only for journal sealing operations in libsystemd, so it
can be made into a dlopen dependency that is used only on demand. This
allows to reduce the footprint of libsystemd in the most common cases.
Keep systemd-pull and systemd-resolved with normal linking, as they are
executables, and usually built with OpenSSL support anyway.
We normally expect sd-resolved only to return the validated subset of a
validated response. In some cases we give up on validating, because we
have enough information already to conclude the answer is bogus.
Let's be sure to always reply with only the validated subset in these
cases too, so that we don't return bogus answers and confuse primitive
clients that won't see the SERVFAIL rcode.
Drop connections and caches and reload config from files, to allow
for low-interruptions updates, and hook up to the usual SIGHUP and
ExecReload=. Mark servers and services configured directly via D-Bus
so that they can be kept around, and only the configuration file
settings are dropped and reloaded.
Fixes https://github.com/systemd/systemd/issues/17503
Fixes https://github.com/systemd/systemd/issues/20604
When validating, when we lookup a DNSKEY for validation we will almost
certainly need the corresponding DS to complete the chain of trust.
Let's go ahead and request it right away so that we don't have to wait
in this common case.
When validating insecure delegations we don't actually need to request
the SOA for every single dns label. We need the DS records for the zone,
and we can seek them by querying for DS directly (in case we are at a
zone cut) and then following the SOA referrals or the parent name until
we have found a chain of trust.
Extra transactions and roundtrips, especially transactions for RRs that
aren't actually needed to validate and therefore aren't likely to be in
the recursive resolver's own cache are a big slowdown during validation.
Consequently, this change results in an enourmous speed up in validating
most names from our own cold-cache (10x or more), by eliminating a large
number of superfluous dnssec transactions.
In some cases when a query completes there are still pending
transactions that are no longer useful to answer the query. But if this
query is repeated in the future and we don't have the answers cached,
we're going to ask and ignore the answer again.
Instead of purging these superfluous transactions, let's wait and see if
they produce an answer, since we already asked the question, and use it
to fill our cache.
This is a follow-up for 945a8210c7 and
makes the st_dev check generic, so that we can reuse it some other
places. It also incorporates the non-NULL check now, to be a
comprehensive one-stop solution.
The helper is static inline so that compilers can optimize the redundant
checks away in case it is combined with other checks.
In some cases we refuse a query based on the RR type, mostly old
deprecated types. Let's return NOTIMP in this case, which best
communicates why the query failed.
The name resolver.arpa is reserved for RFC9462 "Discovery of Designated
Resolvers" (DDR). This relies on regular dns queries for SVCB records at
the special use domain name _dns.resolver.arpa. Unfortunately, older
nameservers (or broken ones) won't know about this SUDN and will likely
return NXDOMAIN. If this is cached, the cache entry will become an
impediment for any clients trying to discover designated resolvers
through the stub-resolver, or potentially even sd-resolved itself, were
it to implement DDR.
The RFC recommendation is that "clients MUST NOT perform A or AAAA
queries for resolver.arpa", and "resolvers SHOULD respond to queries of
any type other than SVCB for _dns.resolver.arpa. with NODATA and queries
of any type for any domain name under resolver.arpa with NODATA." which
should help avoid potential compatibility issues. This enforces that
condition within sd-resolved, and avoids caching any such erroneous
NXDOMAIN.
The RFC also recommends requests for this domain should never be
forwarded, to prevent authentication failures. Since there isn't much
point in establishing secure communication to the local stub, we still
allow SVCB to be forwarded from the stub, in case the client cares to
implement some other authentication method and understands the
consequences of skipping the local stub. Normal clients are not
expected to implement DDR, but this change will protect sd-resolved's
own caches in case they try.
Although A and AAAA are prohibited, I think validating resolvers
might reasonably query for dnssec records, even though the resolver.arpa
zone does not exist (it is declared to be a locally served zone). For
this reason, I have also added resolver.arpa to the builtin dnssec NTA.
In some cases there is no configured server to answer a given question,
because all scopes refused the query. In this case we currently return
rcode SERVFAIL.
In dns it is customary for authoritative nameservers to return REFUSED
where the question is outside of their authority. This is better than
SERVFAIL because it informs the client that they aren't likely to get an
answer out of us anytime soon, and either the configuration, or the
query, need to change.
Similar logic invites us to use use the rcode REFUSED on the stub if we
aren't configured with any suitable scope for this question.
This means the main config file is loaded also from /run and /usr.
We should load the main config file from all the places where we load drop-ins.
I realize I had a giant blind spot: I always assumed that we load config files
from /etc, /run, /usr/local/lib, /usr/lib. But it turns out that we only used
those paths for drop-ins. For the main config file, we only looked in /etc. The
docs actually partially described this behaviour, i.e. most SYNOPSIS sections
and some parts of the text, but not others.
This is strange, because 6495361c7d was completely
bogus with the behaviour before this patch. We had a huge discussion before it
was merged, and clearly nobody noticed this. Similarly, in the previous version
of the current pull request, we had a long discussion about the appropriate
order of directories, and apparently nobody noticed that there was no order,
because only looked in one directory. So the blind spot seems to have been
shared.
Also, systemd-analyze cat-config behaved incorrectly, i.e. its behaviour matches
the new behaviour.
Possibly, in the future it'll make it easier to add support for --root.
This essentially reverts 5656cdfeea. I find it
much easier to understand what is going on when the
path-relative-to-the-search-path is passed in full, instead of being constructed
from two parts, with one of the parts being implicit in some places.
Also, we call 'systemd-analyze cat-config <path>' with <path> with the same
meaning, so this makes the internal and external APIs more consistent.
This works as expected, but coverity warns that it could be ambiguous and context
suggests the other way around. Add brackets to disambiguate.
CID#1535101
Follow-up for 6399be223b
Previously all queries to the reverse mapping domains (in-addr.arpa and
ip6.arpa) were considered to be in-scope for mdns and llmnr at the same
priority as DNS. This caused sd-resolved to ignore NXDOMAIN responses
from dns in favor of lengthy timeouts.
This narrows the scope of mdns and llmnr so they are not invariably
considered as fallbacks for these domains. Now, mdns/llmnr on a link
will only be used as a fallback when there is no suitable DNS scope, and
when that link is DefaultRoute.
RFC6762 10.1 says that queriers receiving a Multicast DNS response with a TTL
of zero SHOULD record a TTL of 1 and then delete the record one second later.
Added a timer event to trigger a callback to clean-up the cache one second after
a goodbye packet is received. The callback also checks for any cache entries
expiring within the next one second and schedules follow-up cleanup callbacks
accordingly.
This is a kinda a follow-up for ce266330fc: it
makes resolved authoritative on our local hostname, and never contacts
DNS anymore for it.
We effectively already were authoritative for it, except if the user
queried for other RR types than just A/AAAA. This closes the gap and
refuses routing other RR type queries to DNS.
Fixes: #23662
If you query for an MX RR of a host listed in /etc/hosts, let's return
an empty reply rather than NXDOMAIN, i.e. indicate that the name exists
but has no MX RR assigned, thus making ourselves authoritative.
The venerable "host" tool by default sends requests for A + AAAA + MX
and ensures we never propagate queries further on.
Fixes: #31223
Te variables indicate what kind of RRs we are looking for, but the name
so far suggests it was about what we already found. Let's rename the
variables to make the purpose clearer.
So far we only looked at the domain name when routing requests to
specific scopes. With this we'll also take the DNS RR type into account.
This takes benefit of the fact that lookups for RRs such as SOA or NS or
the various DNSSEC RR types never really make sense to be routed to
LLMNR or mDNS, since they don't have concepts there.
This hence refuses to route requests for those RR types to the
LLMNR/mDNS scopes, which hence means they'll likely be routed to classic
DNS instead.
This should improve behaviour of tools that assumes it speaks to classic
DNS only via 127.0.0.53, since it will now usually do that.
So far we disabled DNSSEC if local clients asked for it via DO flag if
DNSSEC=no is set. Let's instead switch to proxy mode in this case, and
thus treat client requested DO mode as a way to force proxy mode.
This means DNSSEC=no just controls whether resolved will do validation
for regular looups, but it has no effect anymore on lookups from clients
that indicated they want to do their own DNSSEC anyway.
Fixes: #19227#23737#25105
When we use proxy mode when propagating DNS queries to upstream DNS
servers, let's use the relaxed single label rules. This has the benefit
that tools such "delv" work on the proxy stub 127.0.0.54.
On Noble setting this ioctl fails:
1570s 819/1330 systemd:resolve / test-resolved-stream FAIL 0.14s killed by signal 6 SIGABRT
1570s Successfully forked off '(usernstest)' as PID 27737.
1570s Skipping PR_SET_MM, as we don't have privileges.
1570s (usernstest) succeeded.
1570s Assertion 'ioctl(socket_fd, SIOCSIFFLAGS, &req) >= 0' failed at src/resolve/test-resolved-stream.c:372, function try_isolate_network(). Aborting.
Ignore the result.
Evgeny Vereshchagin
Ronan Pigott
Lennart Poettering
Luca Boccassi
Yu Watanabe
Zbigniew Jędrzejewski-Szmek
Mike Yuan
Vishal Chillara Srinivas