We have an option to set the fallback list, so we don't know what the contents
are. It may in fact be empty. Let's add some examples to make it easy for a user
stranded without any DNS to fill in something that would work. As a bonus, this
also gives names to the entries we provide by default.
(I added google and cloudflare because that's what we have currently, and quad9
because it seems to be a good privacy-concious and fast choice and was requested
in #12499. As a minimum, things we should include should be well-known global
services with a documented privacy policy and both IPv4 and IPv6 support and
decent response times.)
If the hostname of a system is set to an fqdn, glibc traditionally
derives a search domain from it if none is explicitly configured.
This is a bit weird, and we currently don't do that in our own search
path logic.
Following #17193 let's turn this behaviour off for now.
Yes, this has a slight chance of pissing people off who think this
behaviour is good. If this is indeed an issue, we can revisit the issue
but in that case if we readd the concept we should do it properly:
derive the search domain from the fqdn in our codebase too and report it
in resolvectl, and in our generated stub files. But I have the suspicion
most people who set the hostname to an fqdn aren#t even aware of this
behaviour nor want it, so let's wait until people complain.
Fixes: #17193
It can be one of "foreign", "missing", "stub", "static", "uplink",
depending on how /etc/resolv.conf is set up:
foreign → someone/something else manages /etc/resolv.conf,
systemd-resolved is just the consumer
missing → /etc/resolv.conf is missing altogether
stub/static/uplink → the file is managed by resolved, with the
well-known modes
Fixes: #17159
Let's turn off the search domain logic if a trailing dot is specified
when looking up hostnames and RRs via the Varlink + D-Bus APIs (and thus
also when doing so via nss-resolve). (This doesn't affect lookups via
the stub, since for the any search path logic is done client side
anyway)
It might make sense to force the DNS protocol in this case too (and
disable LLMR + mDNS), but we'll leave that for a different PR — if it
even makes sense. It might also make sense to disable the logic of never
routing single-label lookups to the Internet if a trailing to is
specified, but this needs more discussion too.
A variety of sockopts exist both for IPv4 and IPv6 but require a
different pair of sockopt level/option number. Let's add helpers for
these that internally determine the right sockopt to call.
This should shorten code that generically wants to support both ipv4 +
ipv6 and for the first time adds correct support for some cases where we
only called the ipv4 versions, and not the ipv6 options.
There is a minor functional change:
IPV6_FREEBIND is set of IPv6 sockets, not IP_FREEBIND. This was missed in
af8b1384, but I noticed only after the merging the two functions.
And a not-so-minor functional chagnge:
7216a3b5dc changed manager_dns_stub_tcp_fd_extra() to return the fd even
if the source was already initialized, but it didn't do the same change for
manager_dns_stub_udp_fd_extra(), so it would return 0 in that case. But
0354029bf5 uses manager_dns_stub_udp_fd_extra() when preparing to call
manager_send(), and will pass 0 as the fd in that case. For both socket types
fd is now always returned.
DnsPacket should better be a "dead" object, i.e. list facts, not track
resources. By including an fd in its fields it started tracking
resources however, without actually taking a ref to the fd (i.e. no
dup() or so was called on it).
Let's hence rework things so that we don#t have to keep track of the fd
a packet came in from. Instead, pass around the DnsStubListenerExtra
object wherever we need to.
This should be useful as soon as we start caching whole DnsPacket
objects to allow replying to DNSSEC/CO packets, i.e. where we have to
keep a copy of the original DnsPacket around for a long time in cache,
potentially much longer than the fds the packet was received on.
In various cases, we would say 'return log_warning()' or 'return log_error()'. Those
functions return 0 if no error is passed in. For log_warning or log_error this doesn't
make sense, and we generally want to propagate the error. In the few cases where
the error should be ignored, I think it's better to split it in two, and call 'return 0'
on a separate line.
We must have the error number around when completing the transaction.
Let's hence make sure we always initialize it *first* (we accidentally
did it once after).
Fixes: #11626
This allows us to later port nss-resolve to use Varlink rather than
D-Bus for resolution. This has the benefit that nss-resolve based
resoluton works even without D-Bus being up. And it's faster too.
It's strictly bus-specific, hence let's move this to resolved-bus.c like
the rest of the bus specific logic.
This is also in preparation for adding an alternative varlink transport,
which needs similar functionality, but varlink instead of bus-specific.
Let's prepare for adding a new varlink interface, and thus rename the
"request" field to "bus_request", so that we can later add a
varlink_request field too.
Zbigniew Jędrzejewski-Szmek