The idea is that we have strvs like list of server names or addresses, where
the majority of strings is rather short, but some are long and there can
potentially be many strings. So formattting them either all on one line or all
in separate lines leads to output that is either hard to read or uses way too
many rows. We want to wrap them, but relying on the pager to do the wrapping is
not nice. Normal text has a lot of redundancy, so when the pager wraps a line
in the middle of a word the read can understand what is going on without any
trouble. But for a high-density zero-redundancy text like an IP address it is
much nicer to wrap between words. This also makes c&p easier.
This adds a variant of TABLE_STRV which is wrapped on output (with line breaks
inserted between different strv entries).
The change table_print() is quite ugly. A second pass is added to re-calculate
column widths. Since column size is now "soft", i.e. it can adjust based on
available columns, we need to two passes:
- first we figure out how much space we want
- in the second pass we figure out what the actual wrapped columns
widths will be.
To avoid unnessary work, the second pass is only done when we actually have
wrappable fields.
A test is added in test-format-table.
The status string is modeled after our --version output: +enabled -disabled equals=more-info
For example:
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=allow-downgrade/supported
We would print the whole string as a single super-long line. Let's nicely
break the text into lines that fit on the screen.
$ COLUMNS=70 build/resolvectl --no-pager nta
Global: home local intranet 23.172.in-addr.arpa lan
18.172.in-addr.arpa 16.172.in-addr.arpa 19.172.in-addr.arpa
25.172.in-addr.arpa 21.172.in-addr.arpa d.f.ip6.arpa
20.172.in-addr.arpa 30.172.in-addr.arpa 17.172.in-addr.arpa
internal 168.192.in-addr.arpa 28.172.in-addr.arpa
22.172.in-addr.arpa 24.172.in-addr.arpa 26.172.in-addr.arpa
corp 10.in-addr.arpa private 29.172.in-addr.arpa test
27.172.in-addr.arpa 31.172.in-addr.arpa
Link 2 (hub0):
Link 4 (enp0s31f6):
Link 5 (wlp4s0):
Link 7 (virbr0): adsfasdfasdfasd.com 21.172.in-addr.arpa lan j b
a.com home d.f.ip6.arpa b.com local 16.172.in-addr.arpa
19.172.in-addr.arpa 18.172.in-addr.arpa 25.172.in-addr.arpa
20.172.in-addr.arpa k i h 23.172.in-addr.arpa
168.192.in-addr.arpa d g intranet 17.172.in-addr.arpa c e.com
30.172.in-addr.arpa a f d.com e internal
Link 8 (virbr0-nic):
Link 9 (vnet0):
Link 10 (vb-rawhide):
Link 15 (wwp0s20f0u2i12):
We previously checked the QR bit to decide whether the RFC6975 algorithm
data in our packets. But that doesn't work in many cases, since we
initialize the QR flags along with the other flags usually only after
appending OPT (since success to do so propagates into flags). Hence,
let's add an explicit parameter that controls whether to include RFC6975
data in DNS packets, and set it to false for stub reply, and on true for
upstream queries.
Fixes: #17217
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.
