summaryrefslogtreecommitdiff
path: root/src/resolve
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #19131 from keszybz/resolvectl-warn-lessLennart Poettering2021-03-305-68/+124
|\ | | | | Suppress warnings in resolvectl about --type=
| * resolvectl: suppress warning about --type for names with a dotZbigniew Jędrzejewski-Szmek2021-03-261-1/+1
| | | | | | | | | | People don't generally type the trailing dot by mistake, so let's treat this as indication that they want to resolve this particular hostname.
| * resolvectl: do not warn about single hostnames for names we synthesizeZbigniew Jędrzejewski-Szmek2021-03-261-1/+22
| | | | | | | | https://github.com/systemd/systemd/pull/17535#discussion_r534005801
| * resolved: split out function to determine the local llmnr hostnameZbigniew Jędrzejewski-Szmek2021-03-264-64/+99
| |
| * resolvectl: reword note about "raw record types"Zbigniew Jędrzejewski-Szmek2021-03-261-3/+3
| | | | | | | | | | As noted in https://github.com/systemd/systemd/pull/17535#discussion_r534129256, "raw" is misleading in this context. Let's use a more descriptive term.
* | Merge pull request #19125 from keszybz/cat-configZbigniew Jędrzejewski-Szmek2021-03-261-0/+2
|\ \ | | | | | | config files: recommend systemd-analyze cat-config
| * | config files: recommend systemd-analyze cat-configZbigniew Jędrzejewski-Szmek2021-03-261-0/+2
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | This adds the same line to most of our .conf files. Not for systemd/user.conf though, since we can't correctly display it right now: $ systemd-analyze cat-config --user systemd/user.conf Option --user is not supported for cat-config right now. For sysusers.d, tmpfiles.d, rules.d, etc, there is no single file. Maybe we should short READMEs in /usr/lib/sysusers.d, /usr/lib/tmpfiles.d, etc.? Inspired by #19118.
* | resolved: tweak how we signal authoritative answersLennart Poettering2021-03-263-5/+16
|/ | | | | | | | | | | | let's make sure we set the "aa" bit in the stub only if we answer with fully authoritative data. For this ensure: 1. Either all data is synthetic, including all CNAME/DNAME redirects 2. Or all data comes from the local trust anchor or the local zones (i.e. not the network or the cache) Follow-up for 4ad017cda57b04b9d65e7da962806cfcc50b5f0c
* resolved: rework CNAME logic a bit moreLennart Poettering2021-03-251-83/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When following CNAME/DNAME redirects in the stub we currently first iterate through the packet and pick up what we can use (in dns_stub_collect_answer_by_question() and friends), following all CNAMEs/DNAMEs, and would then issue dns_query_process_cname() to move the DnsQuery object forward too, where we'd then possibly restart the query and pick things up again, as above. There's one thought error in this though: dns_query_process_cname() tries to be smart and will internally follow not just a single CNAME/DNAME redirect, but a chain of them if they are contained inside the same packet until we reach the point where the answer is not included in the packet anymore, where we'd restart the query. This was great as long as we only focussed on the D-Bus and Varlink resolver APIs, since there the CNAME/DNAME chain in the middle doesn't actually matter, we just return information about the final name of the RR and its content, and aren't interested in the chain to it. For the DNS stub this is different however: there we need to place the full CNAME/DNAME chain (and all the appropriate metadata RRs) in the stub reply. Hence rework this so that we build on the fact that the previous commit split dns_query_process_cname() in two: 1. dns_query_process_cname_one() will do exactly one CNAME/DNAME redirect step. This will be called by the stub, so that we can pick up matching RRs for every single step along the way. 2. dns_query_process_cname_many() will follow a chain as long as that's possible within the same packet. It's thus pretty much identical to the old dns_query_process_cname() call. This is what we now use in the D-Bus and Varlink APIs. dns_query_process_cname_many() is basically just a loop around dns_query_process_cname_one(). Any logic to follow and pick up RRs manually in the stub along the CNAME/DNAME path is now dropped (i.e. dns_stub_collect_answer_by_question() becomes trivially simple again), we solely rely on dns_query_process_cname_one() to follow CNAME/DNAME now: each step followed by a full call of dns_stub_assign_sections() to copy out the RRs that matter. Net result: things are a bit simpler again, as the only place we follow CNAME/DNAME redirects is DnsQuery again, and stub answers are always complete: they contain all CNAME/DNAME RRs on the way including all their metadata we might pick up in the other sections.
* resolved: split dns_query_process_cname() into two separate functionsLennart Poettering2021-03-255-28/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This does some refactoring: the dns_query_process_cname() function becomes two: dns_query_process_cname_one() and dns_query_process_cname_many(). The former will process exactly one CNAME chain element, the latter will follow a chain for as long as possible within the current packet. dns_query_process_cname_many() is mostly identical to the old dns_query_process_cname(), and all existing code is moved over to using that. This is mostly preparation for the next commit, where we make direct use of dns_query_process_cname_one(). This also renames the DNS_QUERY_RESTARTED return value to DNS_QUERY_CNAME. That's because in the dns_query_process_cname_many() case as before if we return this we restarted the query in case we reached the end of the chain without a conclusive answer, as before. But in dns_query_process_cname_one() we'll only go one step anyway, and leave restarting if needed to the caller. Hence DNS_QUERY_RESTARTED is a bit of a misnomer in that case. This also gets rid of the weird tail recursion in dns_query_process_cname() and replaces it with an explicit loop in dns_query_process_cname_many(). The old recursion wasn't a security issue since we put a limit on the number of CNAMEs we follow anyway, but it's still icky to scale stack use by that.
* resolved: tweak sections we add answer RRs toLennart Poettering2021-03-251-8/+8
| | | | | | | | Previously we'd stick all answer sections RRs we acquired into the authoritative section if we didn't find them directly answering our question. Let's put them into additional instead. The authoritative section should hence only include what comes from the upstream authoritative section, and nothing else.
* resolved: pass mDNS reply packets to each transaction exactly onceLennart Poettering2021-03-251-17/+10
| | | | | | | | | | | | | | | | | | | | | | Previously we'd iterate through the RRs of an mDNS reply and then find exactly one matching transaction on our scope for it, and pass it as reply to that. If multiple RRs of the same packet match we'd pas the packet multiple times to the transaction even. This all doesn't really work anymore since there can be multiple open transactions for the same key (with different flags), and it's kinda ugly anywy. Hence let's turn this around: let's iterate through the transactions and check if any of the included RRs match it, and if so pass the packet to that transaction exactly once. This speeds up mDNS a bit, since previously we'd oftentimes fail to find all suitable transactions for an mDNS reply (because there can be multiple transactions for the same RR key with different flags, and we checked exactly one flag combination). Which would then mean the transaction would time out, and be retried – at which point the cache would be populated and thus it would still succeed, but only after this timeout. With this fix this is corrected: every transaction that matches will get the reply, instantly as we get it.
* 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
* resolved: don't suppress OPT if we have no OPTLennart Poettering2021-03-251-1/+1
| | | | | This is inspired by #18917. It suppresses a misleading log message about suppressing OPT where we might not actually have OPT.
* resolved: don't accept responses to query unless they completely answer our ↵Lennart Poettering2021-03-222-8/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | questions When we checking if the responses we collected for a DnsQuery are sufficient to complete it we previously only check if one of the collected response RRs matches at least one of the question RR keys. This changes the logic to require that there must be at least one response RR matched *each* of the question RR keys before considering the answer complete. Otherwise we might end up accepting an A reply as complete answer for an A/AAAA query and vice versa, but we want to make sure we wait until we get a reply on both types before returning this to the user in all cases. This has been broken for basically forever, but didn't surface until b1eea703e01da1e280e179fb119449436a0c9b8e since until then we'd basically ignore the auxiliary RRs included in CNAME/DNAME replies. Once that commit was made we'd start using the auxiliary RRs included in CNAME/DNAME replies but those typically included only A or only AAAA which we then took for complete. Fixe: #19049
* resolved: propagate correct error variableLennart Poettering2021-03-221-3/+3
|
* meson: fix build error of test-dnssec-complexYu Watanabe2021-03-211-3/+7
| | | | Fixes #19065.
* Merge pull request #19030 from dtardon/rhel9-covscanLuca Boccassi2021-03-181-25/+15
|\ | | | | a bunch of small fixes and clenups based on initial RHEL-9 covscan run
| * resolved-dns-rr: drop unneeded bracesDavid Tardon2021-03-181-2/+1
| |
| * resolved-dns-rr: use already existing variableDavid Tardon2021-03-181-13/+7
| |
| * resolved-dns-rr: avoid unnecessary reassignmentDavid Tardon2021-03-181-7/+4
| |
| * resolved-dns-rr: don't leak s if base64_append failsDavid Tardon2021-03-181-3/+3
| |
* | resolved: simplify min_ttl checkLuca Boccassi2021-03-171-3/+1
|/ | | | | | | | | rr is asserted upon a few lines above, no need to check for null. Coverity-found issue, CID 1450844 CID 1450844: Null pointer dereferences (REVERSE_INULL) Null-checking "rr" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
* resolved: don't flush answer RRs on CNAME redirect too earlyLennart Poettering2021-03-151-3/+4
| | | | | | | | | | | | | | | | | | | | | When doing a CNAME/DNAME redirect let's first check if the answer we already have fully answers the redirected question already. If so, let's use that. If not, let's properly restart things. This simply removes one call to dns_answer_reset() that was placed too early: instead of resetting when we detect a CNAME/DNAME redirect, do so only after checking if the answer we already have doesn't match the reply, and then decide to *actually* follow it. Or in other words: rely on the dns_answer_reset() call in dns_query_go() which we'll call to actually begin with the redirected question. This fixes an optimization path which was broken back in 7820b320eaa608748f66f8105621640cf80e483a. (This doesn't really matter as much as one might think, since our cache stepped in anyway and answered the questions before going back to the network. However, this adds noise if RRs with very short TTLs are cached – which some CDNs do – and is of course relavant when people turn off the local cache.)
* resolved: match CNAME replies to right questionLennart Poettering2021-03-151-1/+1
| | | | | | | | | | | | | Previously by mistake we'd always match every single reply we get in a CNAME chain to the original question from the stub client. That's broken, we need to test it against the CNAME query we are currently looking at. The effect of this incorrect matching was that we'd assign the RRs to the wrong section since we'd assume they'd be auxiliary answers instead of primary answers. Fixes: #18972
* resolved: add helper for dumping DnsQuestion, similar to what we have for ↵Lennart Poettering2021-03-152-0/+20
| | | | DnsAnswer
* resolved: show TTLs in answer dumpLennart Poettering2021-03-151-3/+2
|
* resolved: use DNS_ANSWER_MASK_SECTIONS where appropriateLennart Poettering2021-03-151-1/+1
|
* resolved: let's tweak how we calculate TTL leftLennart Poettering2021-03-151-2/+11
| | | | | | | | | When responding from DNS cache, let's slightly tweak how the TTL is lowered: as before let's round down when converting from our internal µs to the external seconds. (This is preferable, since records should better be cached too short instead of too long.) Let's avoid rounding down to zero though, since that has special semantics in many cases (in particular mDNS). Let's just use 1s in that case.
* resolved: take shortest TTL of all of RRs in answer as cache lifetimeLennart Poettering2021-03-151-16/+44
| | | | | | | | We nowadays cache full answer RRset combinations instead of just the exact matching rrset. This means we should not cache RRs that are not immediate answers to our question for longer then their own RRs. Or in other words: let's determine the shortest TTL of all RRs in the whole answer, and use that as cache lifetime.
* resolved: drop unnecessary local variableLennart Poettering2021-03-151-3/+3
|
* resolved: fix indentationLennart Poettering2021-03-151-1/+1
|
* resolved: use dns_answer_isempty() where appropriateLennart Poettering2021-03-151-1/+1
|
* resolved: rebreak a few commentsLennart Poettering2021-03-151-12/+7
|
* resolved: add new helper dns_answer_min_ttl()Lennart Poettering2021-03-152-0/+21
|
* basic/extract-word: rename flagZbigniew Jędrzejewski-Szmek2021-03-111-1/+1
| | | | The flag enables "relaxed mode" for all kinds of unescaping, not just c-unescaping.
* resolved: when synthesizing stub replies from multiple upstream packet, ↵Lennart Poettering2021-03-063-0/+46
| | | | | | | | | | | let's avoid RR duplicates If we synthesize a stub reply from multiple upstream packet (i.e. a series of CNAME/DNAME redirects), it might happen that we add the same RR to a different reply section at a different CNAME/DNAME redirect chain element. Let's clean this up once we are about to send the reply message to the client: let's remove sections from "lower-priority" sections when they are already listed in a "higher-priority" section.
* resolved: fully follow CNAMEs in the DNS stub after allLennart Poettering2021-03-061-11/+27
| | | | | | | | | | | In 2f4d8e577ca7bc51fb054b8c2c8dd57c2e188a41 I argued that following CNAMEs in the stub is not necessary anymore. However, I think it' better to revert to the status quo ante and follow it after all, given it is easy for us and makes sure our D-Bus/varlink replies are more similar to our DNS stub replies that way, and we save clients potential roundtrips. Hence, whenever we hit a CNAME/DNAME redirect, let's restart the query like we do for the D-Bus/Varlink case, and collect replies as we go.
* resolved: split out helper that checks whether we shall reply with EDNS0 DOLennart Poettering2021-03-061-8/+14
| | | | Just some refactoring, no actual code changes.
* resolved: handle multiple CNAME redirects in a single reply from upstreamLennart Poettering2021-03-061-48/+57
| | | | | | | | www.netflix.com responds with a chain of CNAMEs in the same packet. Let's handle that properly (so far we only followed CNAMEs a single step when in the same packet) Fixes: #18819
* resolved: tighten checks in dns_resource_record_get_cname_target()Lennart Poettering2021-03-061-0/+10
| | | | | | | | | Let's refuse to consider CNAME/DNAME replies matching for RR types where that is not really conceptually allow (i.e. on CNAME/DNAME lookups themselves). (And add a similar check to dns_resource_key_match_cname_or_dname() too, which implements a smilar match)
* dns-query: export CNAME_MAX, so that we can use it in other files, tooLennart Poettering2021-03-062-2/+3
| | | | | | Let's rename it a bit, to be more explanatory while exporting it. (And let's bump the CNAME limit to 16 — 8 just sounded so little)
* resolved: never return ::1 when localhost or local hostname is resolved ↵Lennart Poettering2021-03-051-2/+2
| | | | | | while IPv6 is off in the kernel Fixes: #18812
* tree-wide: use UINT64_MAX or friendsYu Watanabe2021-03-057-29/+29
|
* resolved: disable event sources before unreffing themZbigniew Jędrzejewski-Szmek2021-03-019-22/+22
| | | | | | | | | | | | | | | | | | We generally operate on the assumption that a source is "gone" as soon as we unref it. This is generally true because we have the only reference. But if something else holds the reference, our unref doesn't really stop the source and it could fire again. In particular, on_query_timeout() is called with DnsQuery* as userdata, and it calls dns_query_stop() which invalidates that pointer. If it was ever called again, we'd be accessing already-freed memory. I don't see what would hold the reference. sd-event takes a temporary reference, but on the sd_event object, not on the individual sources. And our sources are non-floating, so there is no reference from the sd_event object to the sources. For #18427.
* resolved: unref event object after the sourcesZbigniew Jędrzejewski-Szmek2021-03-011-2/+2
| | | | It shouldn't matter because of all the refcounting, but it looks unclean.
* resolved: inline trivial functionZbigniew Jędrzejewski-Szmek2021-02-252-10/+5
|
* treewide: fix spellingJoerg Behrmann2021-02-251-1/+1
|
* resolved: don't discard mDNS queries with bad flagsSergey Bugaev2021-02-241-7/+4
| | | | | Even though RFC 6762 specifies these bits MUST be zero, it also says they MUST be ignored on reception.
* resolved: don't discard mDNS packets with ip6.arpa RRsSergey Bugaev2021-02-241-2/+4
| | | | ip6.arpa is also a valid domain name to put in mDNS packets.
View Lorry Controller Status