If /etc/resolv.conf is missing, this should not result in the server
list to be cleared, after all the native data from resolved.conf
shouldn't be flushed out then. Hence flush out the data only if
/etc/resolv.conf exists, but we cannot read it for some reason.
It probably doesn't make sense to mix local and global configuration.
Applying global search lists to local DNS servers appears unnecessary
and creates problems because we'll traverse the search domains
non-simultaneously on multiple scopes.
Also see:
https://github.com/systemd/systemd/pull/2031
When the zone probing code looks for a transaction to reuse it will
refuse to look at transactions that have been answered from cache or the
zone itself, but insist on the network. This has the effect that there
might be multiple transactions around for the same key on the same
scope. Previously we'd track all transactions in a hashmap, indexed by
the key, which implied that there would be only one transaction per key,
per scope. With this change the hashmap will only store the most recent
transaction per key, and a linked list will be used to track all
transactions per scope, allowing multiple per-key per-scope.
Note that the linked list fields for this actually already existed in
the DnsTransaction structure, but were previously unused.
Let's track where the data came from: from the network, the cache or the
local zone. This is not only useful for debugging purposes, but is also
useful when the zone probing wants to ensure it's not reusing
transactions that were answered from the cache or the zone itself.
Previously we'd only store the DnsPacket in the DnsTransaction, and the
DnsQuery would then take the DnsPacket's DnsAnswer and return it. With
this change we already pull the DnsAnswer out inside the transaction.
We still store the DnsPacket in the transaction, if we have it, since we
still need to determine from which peer a response originates, to
implement caching properly. However, the DnsQuery logic doesn't care
anymore for the packet, it now only looks at answers and rcodes from the
successfuly candidate.
This also has the benefit of unifying how we propagate incoming packets,
data from the local zone or the local cache.
Let's use a more useful way to write the flags. Also, leave some space
in the middle for the mDNS flags. After all, these flags are exposed on
the bus, and we should really make sure to expose flags that are going
to be stable, hence allow some room here...
(Not that the room really mattered, except to be nice to one's OCD)
The name RandomSec is too generic: "Sec" just specifies the default
unit type, and "Random" by itself is not enough. Rename to something
that should give the user general idea what the setting does without
looking at documentation.
It may be unexpected to find a CNAME record when doing a reverse lookup, as we
expect to find a PTR record directly. However, it is explicitly supported
according to <https://tools.ietf.org/html/rfc2181#section-10.2>, and there
seems to be no benefit to not supporting it.
The assumption that no NSEC bitmap could be empty due to the presence of the bit representing
the record itself turns out to be flawed. See (the admittedly experimental) RFC4956 for a
counter example.
The new dns_label_escape() call now operates on a buffer passed in,
similar to dns_label_unescape(). This should make decoding a bit faster,
and nicer.
Let's change the return value to bool. If we encounter an error while
parsing, return "false" instead of the actual parsing error, after all
the specified hostname does not qualify for what the function is
supposed to test.
Dealing with the additional error codes was always cumbersome, and
easily misused, like for example in the DHCP code.
Let's also rename the functions from dns_name_root() to
dns_name_is_root(), to indicate that this function checks something and
returns a bool. Similar for dns_name_is_signal_label().
This adds support for searching single-label hostnames in a set of
configured search domains.
A new object DnsQueryCandidate is added that links queries to scopes.
It keeps track of the search domain last used for a query on a specific
link. Whenever a host name was unsuccessfuly resolved on a scope all its
transactions are flushed out and replaced by a new set, with the next
search domain appended.
This also adds a new flag SD_RESOLVED_NO_SEARCH to disable search domain
behaviour. The "systemd-resolve-host" tool is updated to make this
configurable via --search=.
Fixes#1697
For now, let's just expose the LLMNR hostname currently in use; a
combined list of all dns servers with their interface indexes; a
combined list of all search domains with their interface indexes.
This copies concepts we introduced for the DnsSearchDomain stuff, and
reworks the operations on lists of dns servers to be reusable and
generic for use both with the Link and the Manager object.
With this change, we add a new object to resolved, "DnsSearchDomain="
which wraps a search domain. This is then used to introduce a global
search domain list, in addition to the existing per-link search domain
list which is reword to make use of this new object too.
This is preparation for implement proper unicast DNS search domain
support.
Previously, we'd keep adding new dns servers we discover to the end of
our linked list of servers. When we encountered a pre-existing server,
we'd just leave it where it was. In essence that meant that old servers
ended up at the front, and new servers at the end, but not in an order
that would reflect the configuration.
With this change we ensure that every pre-existing server we want to add
again we move to the back of the linked list, so that the order is
stable and in sync with the requested configuration.
Evgeny Vereshchagin
Lennart Poettering
Daniel Mack
David Herrmann
Martin Pitt
Mantas Mikulėnas
Zbigniew Jędrzejewski-Szmek
Tom Gundersen