summaryrefslogtreecommitdiff
path: root/src/resolve/resolved-dns-server.c
Commit message (Collapse)AuthorAgeFilesLines
* basic: Use statement expressions more in list.hDaan De Meyer2023-01-081-3/+3
| | | | | Let's use statement expressions to return values instead of passing in return arguments to the LIST macros.
* resolved: when configuring 127.0.0.1 as per-interface DNS server, contact it ↵Lennart Poettering2022-11-181-0/+5
| | | | | | | | | | via "lo" always ussually if you specify a DNS server on some interface then we'll use that interface to talk to it. Let's override this for localhost addresses, as they only really make sense on "lo". Fixes: #25397
* resolved: fix typo in feature level tableYoufu Zhang2022-11-011-1/+1
|
* tree-wide: use LOG_MESSAGE() where possibleZbigniew Jędrzejewski-Szmek2022-05-111-1/+2
| | | | | | | Also break some long lines for more uniform formatting. No functional change. I went over all log_struct, log_struct_errno, log_unit_struct, log_unit_struct_errno calls, and they seem fine.
* time-util: assume CLOCK_BOOTTIME always existsLennart Poettering2022-03-281-2/+2
| | | | | | | | Let's raise our supported baseline a bit: CLOCK_BOOTTIME started to work with timerfd in kernel 3.15 (i.e. back in 2014), let's require support for it now. This will raise our baseline only modestly from 3.13 → 3.15.
* list: declare iterator of LIST_FOREACH() in the loopYu Watanabe2022-03-191-4/+0
|
* resolved: filter stub listeners in manager_get_dns_server()Tom Yan2021-12-131-1/+10
| | | | | | | | | | | | | | | | | | | | | Commit 49ef064c8dcd8ed12d98e6c705e676babade0897 attempts to handle "stub loop" by switching to the next server *after the query has been made*. The approach may be good enough for link scopes. However, for the manager / global scope, it is not. First of all, there are more than one types (SYSTEM and FALLBACK) of servers it can use. Also, whether those of type FALLBACK should be used depends. Besides, dns_scope_good_domain() determines whether things should be routed to a scope by checking whether the scope has a server. The decision made would be incorrect if stubs were not filtered beforehand. Therefore, to avoid failing query unnecessarily, and to make sure that extra stub listeners will not trigger unexpected and/or inconsistent behavior, make manager_get_dns_server() do what it should have done.
* resolve: remove server 'large' levelDan Streetman2021-12-071-40/+23
| | | | | | | | | | | | | This removes the DNS_SERVER_FEATURE_LEVEL_LARGE, and sets the EDNS0 advertised max packet size as if always in 'large' mode. Without this, we always send out EDNS0 opts that limit response sizes to 512 bytes, thus the remote server will never send anything larger and will always truncate responses larger than 512 bytes, forcing us to drop from EDNS0 down to TCP, even though one of the primary benefits of EDNS0 is larger packet sizes. Fixes: #20993
* resolved: retry on SERVFAIL before downgrading feature levelSteven Siloti2021-08-131-2/+1
| | | | | | | | | | | | | The SERVFAIL RCODE can be generated for many reasons which may not be related to lack of feature support. For example, the Stubby resolver generates SERVFAIL when a request times out. Such transient failures can cause unnecessary downgrades to both the transaction and the server's feature level. The consequences of this are especially severe if the server is in DNSSEC strict mode. In this case repeated downgrades eventually cause the server to stop resolving entirely with the error "incompatible-server". To avoid unnecessary downgrades the request should be retried once with the current level before the transaction's feature level is downgraded.
* Drop the text argument from assert_not_reached()Zbigniew Jędrzejewski-Szmek2021-08-031-3/+3
| | | | | | | | | | | | | | | | | In general we almost never hit those asserts in production code, so users see them very rarely, if ever. But either way, we just need something that users can pass to the developers. We have quite a few of those asserts, and some have fairly nice messages, but many are like "WTF?" or "???" or "unexpected something". The error that is printed includes the file location, and function name. In almost all functions there's at most one assert, so the function name alone is enough to identify the failure for a developer. So we don't get much extra from the message, and we might just as well drop them. Dropping them makes our code a tiny bit smaller, and most importantly, improves development experience by making it easy to insert such an assert in the code without thinking how to phrase the argument.
* tree-wide: "a" -> "an"Yu Watanabe2021-06-301-1/+1
|
* resolved: fix strange function recursionZbigniew Jędrzejewski-Szmek2021-06-081-18/+18
| | | | | | | | | | In dns_server_unlink_marked() and dns_server_mark_all() we done recursively. People might have dozens of servers defined, and it's better to avoid recursion when a simple loop suffices. dns_server_unlink_marked() would only unmark the first marked server. Fixes #19651.
* resolved: indent tables for readabilityZbigniew Jędrzejewski-Szmek2021-05-141-8/+8
| | | | | Some of the tables in resolved were already doing using this convention. This makes the rest of them do so too.
* resolved: upgrade log level to LOG_NOTICE if we switch to fallback server ↵Lennart Poettering2021-03-251-3/+4
| | | | | | | | | | (or back) This is inspired by a recent thread on fedora-devel: it's noteworthy when we switch to the fallback servers, since it might (or might not) indicate some configuration problem. Fixes: #18788
* tree-wide: fix typoYu Watanabe2021-02-191-2/+2
|
* Merge pull request #18664 from poettering/resolved-defragLennart Poettering2021-02-181-12/+71
|\ | | | | resolved: many UDP fragmentation tweaks
| * resolved: take fragment size into consideration when determining EDNS0 udp ↵Lennart Poettering2021-02-181-3/+49
| | | | | | | | packet size
| * resolved: let's track fragment sizes of servers/retry on fragmentingLennart Poettering2021-02-181-9/+22
| | | | | | | | | | | | | | | | Fragmenting sucks, let's avoid it. Thus let's start tracking the maximum fragment size we receive. Also, let's redo a transaction via TCP if we see fragmenting on UDP, as effective mitigation against DNS fragment attacks.
* | resolved: optimize change notification handling away if bus calls set the ↵Lennart Poettering2021-02-181-4/+8
|/ | | | | | | same values as were already set Prompted-by: #17577 (but doesn't fix this, since this commit only handles D-Bus-induced changes, not the ones made via networkd)
* resolved: in DNSSEC permissive mode, check if DO bit wasn't copied from ↵Lennart Poettering2021-02-171-2/+30
| | | | | | | | | request to response If the server doesn't copy the DO bit from request to response, this is a very early and easy indication that it doesn#t support DNSSEC properly. Hence, let's immediately downgrade to non-DNSSEC mode if we see this – if permissive mode is on and this is allowed.
* resolved: include NSID support to DNS stubLennart Poettering2021-02-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds minimal support for RFC5001 NSID to the stub resolver. This useful to identify systemd-resolved when talking to the stub resolver, and distuingishing the packets resolved answers itself (where NSID is now set) from those which it proxies 1:1 upstream (where NSID will not be set, or set to whatever the upstream server has it set to). The NSID chosen consist of two parts: 1. The first part is derived from /etc/machine-id and identifies the resolved instance in a stable way. 2. The second part is the fixed string ".resolved.systemd.io". This thus maybe used for a veriety of checks: a. Am I talking to a resolved stub? b. Am I talking to the same stub as last time? c. Am I talking to the local resolved? Given that the first part leaks the identity of the system in away two protections are in place: I) The NSID is only included on the main stub, not the extra stub. The main stub has with a TTL of 1 and other protections a lot of safety in place that the datagrams never leave the local system, thus the identifying info is only accessible to the local system — but /etc/machine-id is accessible to local software anyway. II) The NSID is hashed from /etc/machine-id in a non-invertable way, so that the machine ID itself isn't leaked, but only an identifier derived from it. Example dig run: ``` $ dig +nsid localhost @127.0.0.53 ; <<>> DiG 9.11.23-RedHat-9.11.23-1.fc33 <<>> +nsid localhost @127.0.0.53 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46917 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ; NSID: 35 33 64 34 61 34 66 63 32 31 32 65 34 31 61 30 39 66 30 39 65 33 32 34 63 64 64 38 30 36 32 33 2e 72 65 73 6f 6c 76 65 64 2e 73 79 73 74 65 6d 64 2e 69 6f ("53d4a4fc212e41a09f09e324cdd80623.resolved.systemd.io") ;; QUESTION SECTION: ;localhost. IN A ;; ANSWER SECTION: localhost. 0 IN A 127.0.0.1 ;; Query time: 0 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Do Nov 12 20:57:16 CET 2020 ;; MSG SIZE rcvd: 110 ```
* resolved: never go below DNSSEC feature level in DNSSEC strict modeLennart Poettering2021-02-161-24/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adjusts our feature level handling: when DNSSEC strict mode is on, let's never lower the feature level below the lowest DNSSEC mode. Also, when asking whether DNSSEC is supproted, always say yes in strict mode. This means that error reporting about transactions that fail because of missing DNSSEC RRs will not report "incompatible-server" but instead "missing-signature" or suchlike. The main difference here is that DNSSEC failures become local to a transaction, instead of propagating into the feature level we reuse for future transactions. This is beneficial with routers that implement "mostly a DNS proxy", i.e. that propagate most DNS requests 1:1 to their upstream servers, but synthesize local answers for a select few domains. For example, AVM Fritz!Boxes operate that way: they proxy most traffic 1:1 upstream in an DNSSEC-compatible fashion, but synthesize the "fritz.box" locally, so that it can be used to configure the router. This local domain cannot be DNSSEC verified, it comes without signatures. Previously this would mean once that domain was resolved feature level would be downgraded, and we'd thus fail all future DNSSEC attempts. With this change, the immediate lookup for "fritz.box" will fail validation, but for all other unrelated future ones that comes without prejudice. (While we are at it, also make a couple of other downgrade paths a bit tighter.) Fixes: #10570 #14435 #6490
* resolved: make feature level checks a bit more discriptiveLennart Poettering2021-02-161-3/+5
| | | | | | The levels have an order, but the order is sometimes a bit arbitrary. Hence add simple macros to check for specific features and use those, so that the ordering leaks a bit less into all files.
* resolved: when we can't parse a packet, downgrade feature levelLennart Poettering2021-02-161-2/+32
| | | | | | So far we didn't really handle the case where we can't parse a reply packet. Since this apparently happens in real-life though, let's add some minimal logic, to downgrade/restart if we see this.
* resolved: reduce indentation level a bitLennart Poettering2021-02-161-14/+14
|
* resolved: don't redundantly switch DNS servers because of transaction failuresLennart Poettering2021-02-151-7/+9
| | | | | | | | | | | | When a transaction fails and we decide to switch DNS servers, don#t do so unconditionally. Check if the current DNS server is still the same as when the transaction was initiated. And if not, do not do anything. That should reduce the number of redundant DNS server switches if many parallel transactions fail simultaneously (which is pretty likely if DNSSEC is on). Fixes: #17040
* resolved: insert large dgram size into EDNS0 only when in LARGE UDP modeLennart Poettering2020-12-031-1/+1
| | | | Specifically, in TLS-DO there's no reason to set the exotic dgram size.
* license: LGPL-2.1+ -> LGPL-2.1-or-laterYu Watanabe2020-11-091-1/+1
|
* resolved: don't append RFC6975 data to stub repliesLennart Poettering2020-10-101-1/+1
| | | | | | | | | | | | We previously checked the QR bit to decide whether the RFC6975 algorithm data in our packets. But that doesn't work in many cases, since we initialize the QR flags along with the other flags usually only after appending OPT (since success to do so propagates into flags). Hence, let's add an explicit parameter that controls whether to include RFC6975 data in DNS packets, and set it to false for stub reply, and on true for upstream queries. Fixes: #17217
* tree-wide: define iterator inside of the macroZbigniew Jędrzejewski-Szmek2020-09-081-2/+1
|
* tree-wide: use siphash24_compress_string() where it is applicableYu Watanabe2020-07-221-2/+1
|
* resolve: read/save port number and SNI from/into link state fileYu Watanabe2020-07-211-9/+25
|
* resolve: compare port and SNI in dns_server_hash_opsYu Watanabe2020-07-211-1/+8
|
* resolve: also compare port and SNI in dns_server_find()Yu Watanabe2020-07-211-2/+6
|
* resolve: support port specifier in DNS= settingYu Watanabe2020-07-211-0/+11
|
* resolve: ignore empty server nameYu Watanabe2020-07-211-1/+1
| | | | Just for safety.
* resolved: Log the feature level we're downgrading from as wellDaan De Meyer2020-06-131-2/+2
|
* resolved: Don't complain too much when downgrading from EDNSDaan De Meyer2020-06-121-3/+8
|
* resolved: Break include cyclesDaan De Meyer2020-05-071-0/+1
|
* Implement SNI when using DNS-over-TLSGuilhem Lettron2019-12-041-1/+11
| | | | | | | | | Some DNS providers need SNI to identify client. This can be used by adding #name to a DNS. Example: [Resolve] DNS=192.168.1.1#example.com
* resolved: emit change for CurrentDNSServerZbigniew Jędrzejewski-Szmek2019-10-251-0/+3
|
* resolve: expose dns_server_address_valid()Yu Watanabe2019-07-171-13/+0
|
* resolved: add strict mode for DNS-over-TLSIwan Timmer2019-06-191-1/+1
| | | | Add strict mode for DNS-over-TLS, which will require TLS support from the server. Closes #10755
* resolved: move TLS data shared by all servers to managerIwan Timmer2019-06-181-4/+0
| | | | Instead of having a context and/or trusted CA list per server this is now moved to the server. Ensures future TLS configuration options are global instead of per server.
* codespell: fix spelling errorsBen Boeckel2019-04-291-2/+2
|
* resolve: rename Link.name -> Link.ifnameYu Watanabe2019-04-131-1/+1
| | | | | | This also changes the type from char[IF_NAMESIZE] to char*. By changing the type, now resolved-link.h can drop the dependency to the header net/if.h.
* resolved: rework dns_server_limited_domains(), replace by ↵Lennart Poettering2018-12-211-20/+10
| | | | | | | | | | | | | | dns_scope_has_route_only_domains() The function dns_server_limited_domains() was very strange as it enumerate the domains associated with a DnsScope object to determine whether any "route-only" domains, but did so as a function associated with a DnsServer object. Let's clear this up, and replace it by a function associated with a DnsScope instead. This makes more sense philosphically and allows us to reduce the loops through which we need to jump to determine whether a scope is suitable for default routing a bit.
* resolved: take particular care when detaching DnsServer from its default streamLennart Poettering2018-12-071-1/+21
| | | | | | | | | | | | | DnsStream and DnsServer have a symbiotic relationship: one DnsStream is the current "default" stream of the server (and thus reffed by it), but each stream also refs the server it is connected to. This cyclic dependency can result in weird situations: when one is destroyed/unlinked/stopped it needs to unregister itself from the other, but doing this will trigger unregistration of the other. Hence, let's make sure we unregister the stream from the server before destroying it, to break this cycle. Most likely fixes: #10725
* resolved: use structured initialization for DnsServer allocationLennart Poettering2018-12-071-7/+9
|
* tree-wide: make hash_ops typesafeYu Watanabe2018-12-021-9/+3
|
View Lorry Controller Status