Files which are installed as-is (any .service and other unit files, .conf
files, .policy files, etc), are left as is. My assumption is that SPDX
identifiers are not yet that well known, so it's better to retain the
extended header to avoid any doubt.
I also kept any copyright lines. We can probably remove them, but it'd nice to
obtain explicit acks from all involved authors before doing that.
The changes both networkd and resolved to make use of the watch_bind
feature of sd-bus to connect to the system bus. This way, both daemons
can be started during early boot, and automatically and instantly
connect to the system bus as it becomes available.
This replaces prior code that used a time-based retry logic to connect
to the bus.
Let's remove a number of synchronization points from our service
startups: let's drop synchronous match installation, and let's opt for
asynchronous instead.
Also, let's use sd_bus_match_signal() instead of sd_bus_add_match()
where we can.
This adds "systemd-resolve --reset-server-features" for explicitly
forgetting what we learnt. This might be useful for debugging
purposes, and to force systemd-resolved to restart its learning logic
for all DNS servers.
https://tools.ietf.org/html/rfc5891#section-4.2.3.1 says that
> The Unicode string MUST NOT contain "--" (two consecutive hyphens) in the third
> and fourth character positions and MUST NOT start or end with a "-" (hyphen).
This means that libidn2 refuses to encode such names.
Let's just resolve them without trying to use IDN.
When we return the full RR wire data, let's make sure the TTL included in it is
adjusted by the time the RR sat in the cache.
As an optimization we do this only for ResolveRecord() and not for
ResolveHostname() and friends, since adjusting the TTL means copying the RR
object, and we don#t want to do that if there's no reason to.
(ResolveHostname() and friends don't return the TTL hence there's no reason to
in that case)
When we get a literal IP address as string that includes a zone suffix, process
this properly and return the parsed ifindex back to the client, and include it
in the canonical name in case of a link-local IP address.
Previously, we checked only for the various SetLinkXYZ() calls on the Manager
object exposed on the bus if the specified interface is managed/unmanaged by
networkd (as we don't permit overriding DNS configuration via bus calls if
networkd owns the device), but the equivalent SetXYZ() calls on the Link object
did not have such a check. Fix that by moving the appropriate check into the
latter, as the former just calls that anyway.
Make sure we can parse DNS server addresses that use the "zone id" syntax for
local link addresses, i.e. "fe80::c256:27ff:febb:12f%wlp3s0", when reading
/etc/resolv.conf.
Also make sure we spit this out correctly again when writing /etc/resolv.conf
and via the bus.
Fixes: #3359
Throughout the tree there's spurious use of spaces separating ++ and --
operators from their respective operands. Make ++ and -- operator
consistent with the majority of existing uses; discard the spaces.
Most domain names we deal with are normalized anyway (since we read them that
way from DNS packets), but some might not (because they are synthesized from
unnormalized configuration or so), hence make sure to normalize all names
before passing them out to clients, to be fully deterministic.
Note that internally we are process normalized and non-normalized names the
same way, and while comparing them ignore the differences due to unnormalized
names. However, that internal implementation detail really shouldn't spill out
the clients, hence make sure to clean it all up.
If the hostname passed to ResolveHostname() is actually an IP address that is
correctly formatted as string parse it as such, avoid any DNS traffic and
return the data in parsed form.
This is useful for clients which can simply call the bus function now without
caring about the precise formatting of specified hostnames. This mimics
getaddrinfo()'s behaviour with the AI_NUMERICHOST flag set.
Note that this logic is only implemented for ResolveHostname(), but not for
calls such as ResolveRecord(), for which only DNS domain names may be used as
input.
The "authenticated" flag is set for look-ups of this type, after all no
untrusted network traffic is involved.
Another property name fuck-up. The property contains both search and routing
domains and hence should be exposed as "Domains" rather than "SearchDomains".
The counterpart in the Link object was correctly named, and the
SetLinkDomains() and SetDomains() setter calls too, hence let's get this right,
too.
(Yepp, a minor API break actually, but given that this was so far not
documented, and only 3 days public let's fix this now)
Previously, if a hostanem is resolved with AF_UNSPEC specified, this would be used as indication to resolve both an
AF_INET and an AF_INET6 address. With this change this logic is altered: an AF_INET address is only resolved if there's
actually a routable IPv4 address on the specific interface, and similar an AF_INET6 address is only resolved if there's
a routable IPv6 address. With this in place, it's ensured that the returned data is actually connectable by
applications. This logic mimics glibc's resolver behaviour.
Note that if the client asks explicitly for AF_INET or AF_INET6 it will get what it asked for.
This also simplifies the logic how it is determined whether a specific lookup shall take place on a scope.
Specifically, the checks with dns_scope_good_key() are now moved out of the transaction code and into the query code,
so that we don't even create a transaction object on a specific scope if we cannot execute the resolution on it anyway.
Following the changes to expose the "routing" and "search" domain concepts in networkd, actually make resolved use
them. It will now use routing domains exclusively for making DNS routing decisions, and use search domains additionally
for extending single-label names.
Whenever we encounter an OS error we did not expect, we so far put the transaction into DNS_TRANSACTION_RESOURCES
state. Rename this state to DNS_TRANSACTION_ERRNO, and save + propagate the actual system error to the caller. This
should make error messages triggered by system errors much more readable by the user.
The LLMNR spec suggests to do do reverse address lookups by doing direct LLMNR/TCP connections to the indicated
address, instead of doing any LLMNR multicast queries. When we do this and the peer doesn't actually implement LLMNR
this will result in a TCP connection error, which we need to handle. In contrast to most LLMNR lookups this will give
us a quick response on whether we can find a suitable name. Report this as new transaction state, since this should
mostly be treated like an NXDOMAIN rcode, except that it's not one.
Not only report whether the server actually supports DNSSEC, but also first check whether DNSSEC is actually enabled
for it in our local configuration.
Also, export a per-link DNSSECSupported property in addition to the existing manager-wide property.
So far, we exposed SetLinkXYZ() on the Manager interface, to set a couple of link properties. This adds similar calls
SetXYZ() on the Link interface, and makes sure the former is little more than a shortcut to the latter.
SetLinkXYZ() has the benefit of not requiring a GetLink() round trip for setting these properties, while the method
actually belongs to the Link objects, and this change corrects that.
This is useful for alternative network management solutions (such as NetworkManager) to push DNS configuration data
into resolved.
The calls will fail should networkd already have taken possesion of a link, so that the bus API is only available if
we don't get the data from networkd.
Move IDNA logic out of the normal domain name processing, and into the bus frontend calls. Previously whenever
comparing two domain names we'd implicitly do IDNA conversion so that "pöttering.de" and "xn--pttering-n4a.de" would be
considered equal. This is problematic not only for DNSSEC, but actually also against he IDNA specs.
Moreover it creates problems when encoding DNS-SD services in classic DNS. There, the specification suggests using
UTF8 encoding for the actual service name, but apply IDNA encoding to the domain suffix.
With this change IDNA conversion is done only:
- When the user passes a non-ASCII hostname when resolving a host name using ResolveHostname()
- When the user passes a non-ASCII domain suffix when resolving a service using ResolveService()
No IDNA encoding is done anymore:
- When the user does raw ResolveRecord() RR resolving
- On the service part of a DNS-SD service name
Previously, IDNA encoding was done when serializing names into packets, at a point where information whether something
is a label that needs IDNA encoding or not was not available, but at a point whether it was known whether to generate a
classic DNS packet (where IDNA applies), or an mDNS/LLMNR packet (where IDNA does not apply, and UTF8 is used instead
for all host names). With this change each DnsQuery object will now maintain two copies of the DnsQuestion to ask: one
encoded in IDNA for use with classic DNS, and one encoded in UTF8 for use with LLMNR and MulticastDNS.
Yu Watanabe