| Age | Commit message (Collapse) | Author |
|---|
|
This fixes formatting of root domain in debug messages:
Old:
systemd-resolved[10049]: Requesting DS to validate transaction 19313 (., DNSKEY with key tag: 19036).
New:
systemd-resolved[10049]: Requesting DS to validate transaction 19313 (, DNSKEY with key tag: 19036).
|
|
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)
|
|
This should be handled fine now by .dir-locals.el, so need to carry that
stuff in every file.
|
|
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.
|
|
Since we honour the edns rcode extension we need more than 4 bits to format it. To avoid further confusion, derive the
right length from the type.
|
|
Also, don't consider RRs that aren't primary to the lookups we do as relevant to the lookups.
|
|
DNS_ANSWER_FOREACH() can deal with NULL answers anyway, let's simplify our code here.
|
|
the network is down
|
|
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.
|
|
The link objects expose as properties the current settings made with SetLinkDNS() and related calls, plus some more
information.
|
|
various configuration files
|
|
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.
|
|
This should be generally useful information, hence show it.
|
|
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.
|
|
|
|
Given how fragile DNS servers are with some DNS types, and given that we really should avoid confusing them with
known-weird lookups, refuse doing lookups for known-obsolete RR types.
|
|
|
|
supporting them
If we already degraded the feature level below DO don't bother with sending requests for DS, DNSKEY, RRSIG, NSEC, NSEC3
or NSEC3PARAM RRs. After all, we cannot do DNSSEC validation then anyway, and we better not press a legacy server like
this with such modern concepts.
This also has the benefit that when we try to validate a response we received using DNSSEC, and we detect a limited
server support level while doing so, all further auxiliary DNSSEC queries will fail right-away.
|
|
Previously, when we couldn't connect to a DNS server via TCP we'd abort the whole transaction using a
"connection-failure" state. This change removes that, and counts failed connections as "lost packet" events, so that
we switch back to the UDP protocol again.
|
|
|
|
This ensures we properly resolve the CNAME chain as far as we can, rather
than only CNAME chains of length one.
|
|
Since we honour RFC5011 revoked keys it might happen we end up with an
empty trust anchor, or one where there's no entry for the root left.
With this patch the logic is changed what to do in this case.
Before this patch we'd end up requesting the root DS, which returns with
NODATA but a signed NSEC we cannot verify, since the trust anchor is
empty after all. Thus we'd return a DNSSEC result of "missing-key", as
we lack a verified version of the key.
With this patch in place, look-ups for the root DS are explicitly
recognized, and not passed on to the DNS servers. Instead, if
downgrade-ok mode is on an unsigned NODATA response is synthesized, so
that the validator code continues under the assumption the root zone was
unsigned. If downgrade-ok mode is off a new transaction failure is
generated, that makes this case recognizable.
|
|
|
|
|
|
via TCP
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.
|
|
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.
|
|
the the bus client
It's useful to generate useful errors, so let's do that.
|
|
We have many types of failure for a transaction, and
DNS_TRANSACTION_FAILURE was just one specific one of them, if the server
responded with a non-zero RCODE. Hence let's rename this, to indicate
which kind of failure this actually refers to.
|
|
Check the validity of RR types as we parse or receive data from IPC
clients, and use the same code for all of them.
|
|
This adds initial support for validating RRSIG/DNSKEY/DS chains when
doing lookups. Proof-of-non-existance, or proof-of-unsigned-zones is not
implemented yet.
With this change DnsTransaction objects will generate additional
DnsTransaction objects when looking for DNSKEY or DS RRs to validate an
RRSIG on a response. DnsTransaction objects are thus created for three
reasons now:
1) Because a user asked for something to be resolved, i.e. requested by
a DnsQuery/DnsQueryCandidate object.
2) As result of LLMNR RR probing, requested by a DnsZoneItem.
3) Because another DnsTransaction requires the requested RRs for
validation of its own response.
DnsTransactions are shared between all these users, and are GC
automatically as soon as all of these users don't need a specific
transaction anymore.
To unify the handling of these three reasons for existance for a
DnsTransaction, a new common naming is introduced: each DnsTransaction
now tracks its "owners" via a Set* object named "notify_xyz", containing
all owners to notify on completion.
A new DnsTransaction state is introduced called "VALIDATING" that is
entered after a response has been receieved which needs to be validated,
as long as we are still waiting for the DNSKEY/DS RRs from other
DnsTransactions.
This patch will request the DNSKEY/DS RRs bottom-up, and then validate
them top-down.
Caching of RRs is now only done after verification, so that the cache is
not poisoned with known invalid data.
The "DnsAnswer" object gained a substantial number of new calls, since
we need to add/remove RRs to it dynamically now.
|
|
This adds a new SD_RESOLVED_AUTHENTICATED flag for responses we return
on the bus. When set, then the data has been authenticated. For now this
mostly reflects the DNSSEC AD bit, if DNSSEC=trust is set. As soon as
the client-side validation is complete it will be hooked up to this flag
too.
We also set this bit whenver we generated the data ourselves, for
example, because it originates in our local LLMNR zone, or from the
built-in trust anchor database.
The "systemd-resolve-host" tool has been updated to show the flag state
for the data it shows.
|
|
dns_resource_record_to_wire_format()
Now that we have dns_resource_record_to_wire_format() we can generate
the RR serialization we return to bus clients in ResolveRecord() with
it. We pass the RR data along in the original form, not the DNSSEC
canonical form, since that would mean we'd lose RR name casing, which is
however important to keep for DNS-SD services and similar.
|
|
GLIB has recently started to officially support the gcc cleanup
attribute in its public API, hence let's do the same for our APIs.
With this patch we'll define an xyz_unrefp() call for each public
xyz_unref() call, to make it easy to use inside a
__attribute__((cleanup())) expression. Then, all code is ported over to
make use of this.
The new calls are also documented in the man pages, with examples how to
use them (well, I only added docs where the _unref() call itself already
had docs, and the examples, only cover sd_bus_unrefp() and
sd_event_unrefp()).
This also renames sd_lldp_free() to sd_lldp_unref(), since that's how we
tend to call our destructors these days.
Note that this defines no public macro that wraps gcc's attribute and
makes it easier to use. While I think it's our duty in the library to
make our stuff easy to use, I figure it's not our duty to make gcc's own
features easy to use on its own. Most likely, client code which wants to
make use of this should define its own:
#define _cleanup_(function) __attribute__((cleanup(function)))
Or similar, to make the gcc feature easier to use.
Making this logic public has the benefit that we can remove three header
files whose only purpose was to define these functions internally.
See #2008.
|
|
|
|
resolved. Fully implement search domains for single-label names
|
|
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.
|
|
For similar reasons as dns_name_is_root() got changed in the previous
commit.
|
|
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.
|
|
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.
|
|
|
|
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.
|
|
|
|
CNAME records are special in the way they are treated by DNS servers,
and our cache should mimic that behavior: In case a domain name has an
alias, its CNAME record is returned in place of any other.
Our cache was not doing this despite caching the CNAME records, this
entailed needless lookups to re-resolve the CNAME.
|
