| Age | Commit message (Collapse) | Author |
|---|
|
DNS servers which have route-only domains should only be used for
the specified domains. Routing queries about other domains there is a privacy
violation, prone to fail (as that DNS server was not meant to be used for other
domains), and puts unnecessary load onto that server.
Introduce a new helper function dns_server_limited_domains() that checks if the
DNS server should only be used for some selected domains, i. e. has some
route-only domains without "~.". Use that when determining whether to query it
in the scope, and when writing resolv.conf.
Extend the test_route_only_dns() case to ensure that the DNS server limited to
~company does not appear in resolv.conf. Add test_route_only_dns_all_domains()
to ensure that a server that also has ~. does appear in resolv.conf as global
name server. These reproduce #3420.
Add a new test_resolved_domain_restricted_dns() test case that verifies that
domain-limited DNS servers are only being used for those domains. This
reproduces #3421.
Clarify what a "routing domain" is in the manpage.
Fixes #3420
Fixes #3421
|
|
In preparation for adding a version which takes a strv.
|
|
Fixes: #4049
|
|
make dist-check-help FTW!
|
|
|
|
|
|
Usually multiple DNS servers are configured, and it looks strange to have
singular in the heading.
|
|
|
|
With commit 6f7da49d00 route-only domains do not get put into resolv.conf's
"search" list any more. Add a comment about the tri-state, to clarify its
semantics and why we are passing a bool parameter into an int type. Also add a
test case for it.
|
|
resolved fixes for handling SERVFAIL errors from servers
|
|
In some cases, caching DNS results locally is not desirable, a it makes DNS
cache poisoning attacks a tad easier and also allows users on the system to
determine whether or not a particular domain got visited by another user. Thus
provide a new "Cache" resolved.conf option to disable it.
|
|
SERVFAIL
Some upstream DNS servers return SERVFAIL if we ask them for DNSSEC RRs, which
some forwarding DNS servers pass on to us as SERVFAIL (other though as
NOERROR...). This is should not be considered a problem, as long as the domain
in question didn't have DNSSEC enabled. Hence: when making use of auxiliary
transactions accept those that return SERVFAIL.
|
|
This way we don't log complaints about packets without SOA in case we are not
caching it anyway because the rcode is not SUCCESS or NXDOMAIN...
|
|
There might be two reasons why we get a SERVFAIL response from our selected DNS
server: because this DNS server itself is bad, or because the DNS server
actually serving the zone upstream is bad. So far we immediately downgraded our
server feature level when getting SERVFAIL, under the assumption that the first
case is the only possible case. However, this meant we'd downgrade immediately
even if we encountered the second case described above.
With this commit handling of SERVFAIL is reworked. As soon as we get a SERVFAIL
on a transaction we retry the transaction with a lower feature level, without
changing the feature level tracked for the DNS server itself. If that fails
too, we downgrade further, and so on. If during this downgrading the SERVFAIL
goes away we assume that the DNS server we are talking to is bad, but the zone
is fine and propagate the detected feature level to the information we track
about the DNS server. Should the SERVFAIL not go away this way we let the
transaction fail and accept the SERVFAIL.
|
|
In order to improve compatibility with local clients that speak DNS directly
(and do not use NSS or our bus API) listen locally on 127.0.0.53:53 and process
any queries made that way.
Note that resolved does not implement a full DNS server on this port, but
simply enough to allow normal, local clients to resolve RRs through resolved.
Specifically it does not implement queries without the RD bit set (these are
requests where recursive lookups are explicitly disabled), and neither queries
with DNSSEC DO set in combination with DNSSEC CD (i.e. DNSSEC lookups with
validation turned off). It also refuses zone transfers and obsolete RR types.
All lookups done this way will be rejected with a clean error code, so that the
client side can repeat the query with a reduced feature set.
The code will set the DNSSEC AD flag however, depending on whether the data
resolved has been validated (or comes from a local, trusted source).
Lookups made via this mechanisms are propagated to LLMNR and mDNS as necessary,
but this is only partially useful as DNS packets cannot carry IP scope data
(i.e. the ifindex), and hence link-local addresses returned cannot be used
properly (and given that LLMNR/mDNS are mostly about link-local communication
this is quite a limitation). Also, given that DNS tends to use IDNA for
non-ASCII names, while LLMNR/mDNS uses UTF-8 lookups cannot be mapped 1:1.
In general this should improve compatibility with clients bypassing NSS but
it is highly recommended for clients to instead use NSS or our native bus API.
This patch also beefs up the DnsStream logic, as it reuses the code for local
TCP listening. DnsStream now provides proper reference counting for its
objects.
In order to avoid feedback loops resolved will no silently ignore 127.0.0.53
specified as DNS server when reading configuration.
resolved listens on 127.0.0.53:53 instead of 127.0.0.1:53 in order to leave
the latter free for local, external DNS servers or forwarders.
This also changes the "etc.conf" tmpfiles snippet to create a symlink from
/etc/resolv.conf to /usr/lib/systemd/resolv.conf by default, thus making this
stub the default mode of operation if /etc is not populated.
|
|
|
|
We don't make use of this yet, but later work will.
|
|
And make use of it at a couple of places.
|
|
And make use of them at a few places.
|
|
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)
|
|
|
|
|
|
restarts
Let's make sure that all settings pushed in stay around when systemd-resolved
is restarted.
|
|
It's weird having a "negative" function link_is_unmanaged(), let's invert it
and get rid of the negation this way, by renaming it to link_is_managed().
Internally we stored this as a positive boolean already, hence let's do this
for the function too.
|
|
Let's split the code from the inner loop out, into its own function
link_update_dns_server_one(). This matches how things are already handled for
the search domain logic. Also, this is preparation for a later commit that
persists DNS server data pushed in via the bus.
|
|
|
|
After all, /etc/resolv.conf doesn't know the concept of "route-only domains",
hence the domains should really not appear there.
|
|
The new command shows the per-link and global DNS configuration currently in
effect. This is useful to quickly see the DNS settings resolved acquired from
networkd and that was pushed into it via the bus APIs.
|
|
Internally, we store the per-link DNSSEC setting as -1 (invalid) if there's no
link-specific setting configured, and the global setting should be used. When
exporting this one the bus we really should export the effective DNSSEC
setting however, i.e. return the global one if there's non set per-link.
|
|
We export them per-link, hence let's export the global NTAs too.
|
|
(#3553)
dns_transaction_maybe_restart() is supposed to return 1 if the the transaction
has been restarted and 0 otherwise. dns_transaction_process_dnssec() relies on
this behaviour. Before this change in case of restart we'd call
dns_transaction_go() when restarting the lookup, returning its return value
unmodified. This is wrong however, as that function returns 1 if the
transaction is pending, and 0 if it completed immediately, which is a very
different set of return values. Fix this, by always returning 1 on redirection.
The wrong return value resulted in all kinds of bad memory accesses as we might
continue processing a transaction that was redirected and completed immediately
(and thus freed).
This patch also adds comments to the two functions to clarify the return values
for the future.
Most likely fixes: #2942 #3475 #3484
|
|
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, after checking the local zone for a reply and finding one we'd not
initialize the answer ifindex from that. Let's fix that.
|
|
We can reuse some code here, so let's do it.
|
|
Follow-up for #3502.
|
|
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.
|
|
And expose it in "resolve-tool --flush-caches".
|
|
|
|
changed via bus calls
This also moves log message generation into manager_write_resolv_conf(), so
that it is shorter to invoke the function, given that we have to invoke it at a
couple of additional places now.
Fixes: #3225
|
|
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
|
|
Assorted stuff
|
|
Write comments about "too many search domains" and "Total length of all search
domains is too long" just once. Also put it on a separate line, as
resolv.conf(5) only specifies comments in a line by themselves.
This is ugly to do if write_resolv_conf_search() gets called once for every
search domain. So change it to receive the complete OrderedSet instead and do
the iteration by itself.
Add test cases to networkd-test.py.
https://launchpad.net/bugs/1588229
|
|
and make use of it everywhere
|
|
|
|
packet (#3323)
Fixes:
-bash-4.3# ss --udp -l -p
State Recv-Q Send-Q Local Address:Port Peer Address:Port
UNCONN 0 0 *:5355 *:* users:(("systemd-resolve",pid=601,fd=12))
UNCONN 0 0 :::5355 :::* users:(("systemd-resolve",pid=601,fd=14))
-bash-4.3# nping --udp -p 5355 --data-length 0 -c 1 localhost
-bash-4.3# journalctl -u systemd-resolved -b --no-hostname
...
May 21 14:59:22 systemd-resolved[601]: Event source llmnr-ipv4-udp (type io) returned error, disabling: Input/output error
...
-bash-4.3# nping --udp -p 5355 --data-length 1000 -c 1 localhost
-bash-4.3# ss --udp -l
State Recv-Q Send-Q Local Address:Port Peer Address:Port
UNCONN 2304 0 *:5355 *:*
UNCONN 0 0 :::5355 :::*
|
|
After a few link up/down events I got this warning:
May 17 22:05:10 laptop systemd-resolved[2983]: Failed to read DNS servers for interface wlp3s0, ignoring: Argument list too long
|
|
|
|
incapdns.net returns NXDOMAIN for the SOA of the zone itself but is not a
terminal. This is against the specs, but we really should be able to deal with
this.
Previously, when verifying whether an NXDOMAIN response for a SOA/NS lookup is
rightfully unsigned we'd issue a SOA lookup for the parent's domain, to derive
the state from that. If the parent SOA would get an NXDOMAIN, we'd continue
upwards, until we hit a signed top-level domain, which suggests that the domain
actually exists.
With this change whenver we need to authenticate an NXDOMAIN SOA reply, we'll
request the DS RR for the zone first, and use for validation, since that this
must be from the parent's zone, not the incorrect lower zone.
Fixes: #2894
|
|
|
|
The coccinelle patch didn't work in some places, I have no idea why.
|
