Tom Gundersen [Mon, 6 Jul 2015 14:48:24 +0000 (16:48 +0200)]
resolved: announce support for large UDP packets
This is often needed for proper DNSSEC support, and even to handle AAAA records
without falling back to TCP.
If the path between the client and server is fully compliant, this should always
work, however, that is not the case, and overlarge packets will get mysteriously
lost in some cases.
For that reason, we use a similar fallback mechanism as we do for palin EDNS0,
EDNS0+DO, etc.:
The large UDP size feature is different from the other supported feature, as we
cannot simply verify that it works based on receiving a reply (as the server
will usually send us much smaller packets than what we claim to support, so
simply receiving a reply does not mean much).
For that reason, we keep track of the largest UDP packet we ever received, as this
is the smallest known good size (defaulting to the standard 512 bytes). If
announcing the default large size of 4096 fails (in the same way as the other
features), we fall back to the known good size. The same logic of retrying after a
grace-period applies.
Tom Gundersen [Wed, 24 Jun 2015 13:08:40 +0000 (15:08 +0200)]
resolved: set the DNSSEC OK (DO) flag
This indicates that we can handle DNSSEC records (per RFC3225), even if
all we do is silently drop them. This feature requires EDNS0 support.
As we do not yet support larger UDP packets, this feature increases the
risk of getting truncated packets.
Similarly to how we fall back to plain UDP if EDNS0 fails, we will fall
back to plain EDNS0 if EDNS0+DO fails (with the same logic of remembering
success and retrying after a grace period after failure).
Tom Gundersen [Tue, 23 Jun 2015 21:06:09 +0000 (23:06 +0200)]
resolved: implement minimal EDNS0 support
This is a minimal implementation of RFC6891. Only default values
are used, so in reality this will be a noop.
EDNS0 support is dependent on the current server's feature level,
so appending the OPT pseudo RR is done when the packet is emitted,
rather than when it is assembled. To handle different feature
levels on retransmission, we strip off the OPT RR again after
sending the packet.
Similarly, to how we fall back to TCP if UDP fails, we fall back
to plain UDP if EDNS0 fails (but if EDNS0 ever succeeded we never
fall back again, and after a timeout we will retry EDNS0).
Tom Gundersen [Thu, 16 Jul 2015 12:39:55 +0000 (14:39 +0200)]
resolved: degrade the feature level on explicit failure
Previously, we would only degrade on packet loss, but when adding EDNS0 support,
we also have to handle the case where the server replies with an explicit error.
Tom Gundersen [Mon, 6 Jul 2015 06:15:25 +0000 (08:15 +0200)]
resolved: fallback to TCP if UDP fails
This is inspired by the logic in BIND [0], follow-up patches
will implement the reset of that scheme.
If we get a server error back, or if after several attempts we don't
get a reply at all, we switch from UDP to TCP for the given
server for the current and all subsequent requests. However, if
we ever successfully received a reply over UDP, we never fall
back to TCP, and once a grace-period has passed, we try to upgrade
again to using UDP. The grace-period starts off at five minutes
after the current feature level was verified and then grows
exponentially to six hours. This is to mitigate problems due
to temporary lack of network connectivity, but at the same time
avoid flooding the network with retries when the feature attempted
feature level genuinely does not work.
Note that UDP is likely much more commonly supported than TCP,
but depending on the path between the client and the server, we
may have more luck with TCP in case something is wrong. We really
do prefer UDP though, as that is much more lightweight, that is
why TCP is only the last resort.
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.
resolved: don't follow the global search list on local scopes
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.
resolved: handle properly if there are multiple transactions for the same key per scope
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.
resolved: for a transaction, keep track where the answer data came from
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.
resolved: store just the DnsAnswer instead of a DnsPacket as answer in DnsTransaction objects
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)
Tom Gundersen [Thu, 26 Nov 2015 02:58:08 +0000 (03:58 +0100)]
resolved: bus - follow CNAME chains when resolving addresses
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.
Tom Gundersen [Wed, 25 Nov 2015 21:22:38 +0000 (22:22 +0100)]
resolved: do not reject NSEC records with empty bitmaps
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.
dns-domain: rework dns_label_escape() to not imply memory allocation
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.
dns-domain: simplify dns_name_is_root() and dns_name_is_single_label()
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=.
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.
resolved: unify DnsServer handling code between Link and Manager
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.
resolved: make sure order of dns servers is stable
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.
Previously, there was a chance of memory corruption, because when
switching to the next DNS server we didn't care whether they linked list
of DNS servers was still valid.
Clean up lifecycle of the dns server logic:
- When a DnsServer object is still in the linked list of DnsServers for
a link or the manager, indicate so with a "linked" boolean field, and
never follow the linked list if that boolean is not set.
- When picking a DnsServer to use for a link ot manager, always
explicitly take a reference.
This also rearranges some logic, to make the tracking of dns servers by
link and globally more alike.
man: fix documentation how /etc/resolv.conf is read
/etc/resolv.conf is only read when the DNS= setting does not appear at
all in resolved.conf, regardless if set to the empty list or anything
else. Correct that in the man page.
resolved: don't claim DnsQuestion have to have the same names
Wen DnsQuestion objects are used for DnsQuery objects all contained keys
have to share the same name, but otherwise they generally don't have to,
and this can actually happen in real-life because DnsPacket objects for
mDNS use DnsQuestion for the question section.
Hence, rename:
dns_question_is_valid() to dns_question_is_valid_for_query(), since the
name uniqueness check it does is only relevant when used for a query.
Similar, rename dns_question_name() to dns_question_first_name(),
to be more accurate, as this difference matters if we keys don#t have to
share the same name.
Christian Hesse [Wed, 25 Nov 2015 07:46:43 +0000 (08:46 +0100)]
networkd: link - do not drop config for loopback device
Commit 5e5b137a (networkd: link - drop foreign config when configuring
link) introduced a regression where addresses (including 127.0.0.1) are
removed from loopback device.
Do not handle loopback device when removing foreign configs.
resolved: add ResolveService() bus call for resolving SRV and DNS-SD services
This also adds client-side support for this to systemd-resolve-host.
Note that the ResolveService() API can deal both with DNS-SD service
(consisting of service name, type and domain), as well as classic SRV
services (consisting just of a type and a domain), all exposed in the
same call.
This patch also reworks CNAME handling in order to reuse it between
hostname, RR and service lookups.
In contrast to Avahi and Bonjour, this new API will actually reolve the
A/AAAA RRs the SRV RRs point to in one go (unless this is explicitly
disabled). This normally comes for free, as these RRs are sent along
the SRV responses anyway, hence let's make use of that. This makes the
API considerably easier to use, as a single ResolveService() invocation
will return all necessary data to pick a server and connect() to it.
Note that this only implements the DNS-SD resolving step, it does not
implement DNS-SD browsing, as that makes sense primarily on mDNS, due to
its continuous nature.
dns-domain: add calls to join/split SRV/DNS-SD service domains
This adds dns_service_join() and dns_service_split() which may be used
to concatenate a DNS-SD service name, am SRV service type string, and a
domain name into a full resolvable DNS domain name string. If the
service name is specified as NULL, only the type and domain are
appended, to implement classic, non-DNS-SD SRV lookups.
The reverse is dns_service_split() which takes the full name, and split
it into the three components again.
resolved: accept TXT records with non-UTF8 strings
RFC 6763 is very clear that TXT RRs should allow arbitrary binary
content, hence let's actually accept that. This also means accepting NUL
bytes in the middle of strings.
Franck Bui [Mon, 23 Nov 2015 10:14:10 +0000 (11:14 +0100)]
make sure all swap units are ordered before the swap target
When shutting down the system, the swap devices can be disabled long
time before the swap target is stopped. They're actually the first
units systemd turns off on my system.
This is incorrect and due to swap devices having multiple associated
swap unit files. The main one is usually created by the fstab
generator and is used to start the swap device.
Once done, systemd creates some 'alias' units for the same swap
device, one for each swap dev link. But those units are missing an
ordering dependencies which was created by the fstab generator for the
main swap unit.
Therefore during shutdown those 'alias' units can be stopped at
anytime before unmount.target target.
This patch makes sure that all swap units are stopped after the
swap.target target.
man: include the target name when linking to man pages in html output
Links like http://www.freedesktop.org/software/systemd/man/systemd.socket.html
are changed to http://www.freedesktop.org/software/systemd/man/systemd.socket.html#Accept=.
This implementation is quick & dirty, and misses various corner
cases. A fairly important one is that when a few directives share the
same anchor (which happens when multiple directives are described in
the same paragraph), generated links for everything except the first
one link to an invalid anchor. Another shortcoming is that the
formatting does not use the proper generateID machinery, so the anchor
name could be wrong in some cases. But it seems to work for a large
percentage of links, so seems to be an improvement in usability. When
the anchor is missing, we land at the top of the page, which is the
same as before. If the anchor were to point to different spot, this
would be more confusing... Not sure if that ever happens. Anyway, the
user should be able to recover from landing on the wrong place in the
page.
projects / thirdparty / systemd.git / log
