This permits configuration of additional "delegates" which ensure that
lookups for certain DNS zones are routed to specific sets of DNS
servers, in addition to the routes we create for each network interface.
For now, this allows only static configuration, but eventually we should
open this up to IPC.
Fixes: #5573#14159#20485#21260#24532#32022
(Fixes#32022, because now redundant)
This new enum field is supposed to indicate why a DnsScope came to be.
For now it distinguishes two origins: the "global" one (which is what is
configured in resolved.conf) and "link" ones (which are synthesized for
each link).
The field as is is pretty redundant, the same information can be
determined from whether the .link field is set or not.
This is pretty much just preparation for later commits that add
statically configured additional DnsScopes whose origin shall be encoded
with this.
These glibc headers conflicts with the corresponding linux headers
(<linux/in.h> and <linux/if.h>) and impose an include order (the glibc one
has to be included before any linux header is included). This makes sorting
includes a royal pain so let's define our own versions of these headers using
various linux headers to do all the work and filling in the missing bits
ourselves.
RFC 4035 Section 4.2 requires that missing DS records are queried for in
the parent zone rather than the child zone, the old behaviour could
cause subdomains under home.arpa (RFC 8375) to fail validation.
This commit assumes that QDCOUNT = 1 as per RFC 9619
Fixes https://github.com/systemd/systemd/issues/19496
Fixes#22575, as suggested by poettering in #35514.
Intended as a workaround for some buggy routers, which refuse to send empty
replies. If systemd-resolved starts two DnsTransactions, one for A and one
for AAAA, and the domain in question has no AAAA entry, then the server will
send a reply for A and no reply for AAAA. Correct behavior for the server would
be to send an empty reply for AAAA.
systemd-resolved would previously keep retrying the AAAA transaction, and
eventually timeout the whole query, returning an error to the caller.
Now, if the server replies to one query and not another, we cut short the
timeout and return the partial result. Returning the partial result allows
the rest of the system to keep working. It matches how e.g. glibc libnss_dns
behaves.
This softens the behavior originally introduced in eded61e410 to apply
only to the fallback dns servers.
The intent is that the global FallbackDNS (instead of DNS) can now be
used in conjunction with the per-link dns, providing a fallback behavior
without introducing a scope overlap.
References: eded61e410 (resolved: demote the global unicast scope, 2024-08-19)
This commit may have been a breaking change for sd-resolved foreign
resolv.conf mode, where a legacy network management daemon directly
modifies resolv.conf and sd-resolved consumes that.
This reverts commit eded61e410.
This will greatly reduce the number of cases where the global unicast
scope overlaps with link scopes configured as default-route, making it
feasible to use the global DNS setting in conjunction with per-link dns
servers configured by the network.
This change is preferred over demoting links to default-route=no where
the user prefers to use the network provided DNS servers, and I expect
it is non-disruptive in that it should not degrade the efficacy of any
existing configuration.
This is preparation for making our Varlink API a public API. Since our
Varlink API is built on top of our JSON API we need to make that public
first (it's a nice API, but JSON APIs there are already enough, this is
purely about the Varlink angle).
I made most of the json.h APIs public, and just placed them in
sd-json.h. Sometimes I wasn't so sure however, since the underlying data
structures would have to be made public too. If in doubt I didn#t risk
it, and moved the relevant API to src/libsystemd/sd-json/json-util.h
instead (without any sd_* symbol prefixes).
This is mostly a giant search/replace patch.
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.
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
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_BINDTODEVICE was used during connect() to fix an issue where
IP_UNICAST_IF was improperly ignored for route lookups made by connect
in linux. This has since been resolved upstream [1][2], but as a result
we must apply the local socket excpetion to IP_UNICAST_IF as well.
The SO_BINDTODEVICE is no longer necessary, but left in place for 5.x
kernels.
[1] https://lore.kernel.org/all/20220829111554.GA1771@debian/
[2] https://lore.kernel.org/all/20221208145437.GA75680@debian/
By making assert_return() critical, we observe the following:
---
Program received signal SIGABRT, Aborted.
0x00007f01320b0884 in __pthread_kill_implementation () from /lib64/libc.so.6
(gdb) bt
#0 0x00007f01320b0884 in __pthread_kill_implementation ()
from /lib64/libc.so.6
#1 0x00007f013205fafe in raise () from /lib64/libc.so.6
#2 0x00007f013204887f in abort () from /lib64/libc.so.6
#3 0x00007f01338d02d6 in log_assert_failed (
text=0x7f01340009e0 "e->state != SD_EVENT_FINISHED",
file=0x7f0133fff403 "src/libsystemd/sd-event/sd-event.c", line=1399,
func=0x7f01340045a0 <__func__.148> "sd_event_add_time")
at ../src/basic/log.c:948
#4 0x00007f01338d0457 in log_assert_failed_return (
text=0x7f01340009e0 "e->state != SD_EVENT_FINISHED",
file=0x7f0133fff403 "src/libsystemd/sd-event/sd-event.c", line=1399,
func=0x7f01340045a0 <__func__.148> "sd_event_add_time")
at ../src/basic/log.c:967
#5 0x00007f0133c7ed83 in sd_event_add_time (e=0x617000022280,
ret=0x610000007e98, clock=7, usec=24054941030, accuracy=0,
callback=0x4625b4 <on_announcement_timeout>, userdata=0x610000007e40)
at ../src/libsystemd/sd-event/sd-event.c:1399
#6 0x00007f0133c7f725 in sd_event_add_time_relative (e=0x617000022280,
ret=0x610000007e98, clock=7, usec=1000000, accuracy=0,
callback=0x4625b4 <on_announcement_timeout>, userdata=0x610000007e40)
at ../src/libsystemd/sd-event/sd-event.c:1462
#7 0x0000000000464cac in dns_scope_announce (scope=0x610000007e40, goodbye=true) at ../src/resolve/resolved-dns-scope.c:1530
#8 0x0000000000504d08 in link_free (l=0x612000023d40) at ../src/resolve/resolved-link.c:83
#9 0x000000000052dbbd in manager_free (m=0x619000000a80) at ../src/resolve/resolved-manager.c:697
#10 0x0000000000562328 in manager_freep (p=0x7f012f800040) at ../src/resolve/resolved-manager.h:198
#11 0x000000000056315a in run (argc=1, argv=0x7fff22b06468) at ../src/resolve/resolved.c:25
#12 0x0000000000563284 in main (argc=1, argv=0x7fff22b06468) at ../src/resolve/resolved.c:99
---
Prompted by https://github.com/systemd/systemd/pull/30049#issuecomment-1844087965.
With ResolveUnicastSingleLabel=yes, a scope's search domains are affixed to the
query even when a routing domain matches the single-label query name,
preventing the use of dotless single-label domains entirely.
This changes dns_scope_name_wants_search_domain() to return false when the
scope contains an exact match of the single-label name in the query, allowing
lookups for dotless domains with ResolveUnicastSingleLabel enabled.
According to RFC 6762 section 8, an mDNS responder is supposed to announce its
records after probing.
Currently, there is a check in dns_scope_announce which returns if there are any
pending transactions. This prevents announcements from being sent out even if there
are pending non-probe transactions.
To fix this, return only if there are active probe transactions.
This adds a simple varlink call io.systemd.Resolve.Monitor.DumpCache to
the existing io.systemd.Resolve.Monitor service. It compiles a JSON
object containing the per-scope cache entries and returns it.
Replaces: #20053#19104Fixes: #14796
-1 was used everywhere, but -EBADF or -EBADFD started being used in various
places. Let's make things consistent in the new style.
Note that there are two candidates:
EBADF 9 Bad file descriptor
EBADFD 77 File descriptor in bad state
Since we're initializating the fd, we're just assigning a value that means
"no fd yet", so it's just a bad file descriptor, and the first errno fits
better. If instead we had a valid file descriptor that became invalid because
of some operation or state change, the other errno would fit better.
In some places, initialization is dropped if unnecessary.
The compiler should recognize that these are constant expressions, but
let's better make this explicit, so that the linker can safely share the
initializations all over the place.
Also, this makes mDNS regular queries sent without delay (except for
one caused by the default accuracy of sd-event).
Note, RFC 6762 Section 5.2 is about continuous mDNS query, which is not
implemented yet.
Let's raise our supported baseline a bit: CLOCK_BOOTTIME started to work
with timerfd in kernel 3.15 (i.e. back in 2014), let's require support
for it now.
This will raise our baseline only modestly from 3.13 → 3.15.