This renames dns_transaction_stop() to dns_transaction_stop_timeout()
and makes it only about stopping the transaction timeout. This is safe,
as in most occasions we call dns_transaction_stop() at the same time as
dns_transaction_close_connection() anyway, which does the rest of what
dns_transaction_stop() used to do. And in the one where we don't call
it, it's implicitly called by the UDP emission or TCP connection code.
This also closes the connections as we enter the validation phase of a
transaction, so that no further messages may be received then.
This removes dnssec_algorithm_supported() and simply uses the
algorithm_to_gcrypt() result as indication whether a DNSSEC algorithm is
supported.
The patch also renames "algorithm" to "md_algorithm", in a few cases, in
order to avoid confusion between DNSSEC signature algorithms and gcrypt
message digest algorithms.
Previously, we'd not allow control characters to be embedded in domain
names, even when escaped. Since cloudflare uses \000 however to
implement its synthethic minimally covering NSEC RRs, we should allow
them, as long as they are properly escaped.
The name "features" suggests an orthogonal bitmap or suchlike, but the
variables really encode only a linear set of feature levels. The type
used is already called DnsServerFeatureLevel, hence fix up the variables
accordingly, too.
This moves management of the OPT RR out of the scope management and into
the server and packet management. There are now explicit calls for
appending and truncating the OPT RR from a packet
(dns_packet_append_opt() and dns_packet_truncate_opt()) as well as a
call to do the right thing depending on a DnsServer's feature level
(dns_server_adjust_opt()).
This also unifies the code to pick a server between the TCP and UDP code
paths, and makes sure the feature level used for the transaction is
selected at the time the server is picked, and not changed until the
next time we pick a server. The server selction code is now unified in
dns_transaction_pick_server().
This all fixes problems when changing between UDP and TCP communication
for the same server, and makes sure the UDP and TCP codepaths are more
alike. It also makes sure we never keep the UDP port open when switchung
to TCP, so that we don't have to handle incoming datagrams on the latter
we don't expect.
As the new code picks the DNS server at the time we make a connection,
we don't need to invalidate the DNS server anymore when changing to the
next one, thus dns_transaction_next_dns_server() has been removed.
This new call unifies how we shut down all connection resources, such as
UDP sockets, event sources, and TCP stream objects.
This patch just adds the basic hook-up, this function will be used more
in later commits.
On LLMNR we never want to retry stream connections (since local TCP
connections should work, and we don't want to unnecessarily delay
operation), explicitly remember whether we already tried one, instead of
deriving this from a still stored stream object. This way, we can free
the stream early, without forgetting that we tried it.
All our other domain name handling functions make no destinction between
domain names that end in a dot plus a NUL, or those just ending in a
NUL. Make sure dns_name_compare_func() and dns_label_unescape_suffix()
do the same.
Previously the calls for emitting DNS UDP packets were just called
dns_{transacion|scope}_emit(), but the one to establish a DNS TCP
connection was called dns_transaction_open_tcp(). Clean this up, and
rename them dns_{transaction|scope}_emit_udp() and
dns_transaction_open_tcp().
This adds a mode that makes resolved automatically downgrade from DNSSEC
support to classic non-DNSSEC resolving if the configured DNS server is
not capable of DNSSEC. Enabling this mode increases compatibility with
crappy network equipment, but of course opens up the system to
downgrading attacks.
The new mode can be enabled by setting DNSSEC=downgrade-ok in
resolved.conf. DNSSEC=yes otoh remains a "strict" mode, where DNS
resolving rather fails then allow downgrading.
Downgrading is done:
- when the server does not support EDNS0+DO
- or when the server supports it but does not augment returned RRs with
RRSIGs. The latter is detected when requesting DS or SOA RRs for the
root domain (which is necessary to do proofs for unsigned data)
Previously, if we couldn't reach a server via UDP we'd generate an
MAX_ATTEMPTS transaction result, but if we couldn't reach it via TCP
we'd generate a RESOURCES transaction result. While it is OK to generate
two different errors I think, "RESOURCES" is certainly a misnomer.
Introduce a new transaction result "CONNECTION_FAILURE" instead.
Previously, we'd insist on an RRSIG for all DS/NSEC/NSEC3 RRs. With this
change we don't do that anymore, but also allow unsigned DS/NSEC/NSEC3
if we can prove that the zone they are located in is unsigned.
This collects statistical data about transactions, dnssec verifications
and the cache, and exposes it over the bus. The systemd-resolve-host
tool learns new options to query these statistics and reset them.
Be stricter when searching suitable NSEC3 RRs for proof: generalize the
check we use to find suitable NSEC3 RRs, in nsec3_is_good(), and add
additional checks, such as checking whether all NSEC3 RRs use the same
parameters, have the same suffix and so on.
When doing an NSEC3 proof, before detrmining whether a name is the
closest encloser we first need to figure out the longest common suffix
we have with any NSEC3 RR in the reply.
Note that this is still not complete, one additional step is still
missing: when we verified that a wildcard RRset is properly signed, we
still need to do an NSEC/NSEC3 proof that no more specific RRset exists.
Otherwise if we have an A lookup that failed DNSSEC validation, but an
AAAA lookup that succeeded, we might end up using the A data, but we
really should not.
Let's simplify usage and memory management of DnsResourceRecord's
dns_resource_record_to_string() call: cache the formatted string as
part of the object, and return it on subsequent calls, freeing it when
the DnsResourceRecord itself is freed.
If there are multiple SOA RRs, and we look for a suitable one covering
our request, then make sure to pick the one that is furthest away from
the root name, not just the first one we encounter.
