summaryrefslogtreecommitdiff
path: root/src/resolve/resolved-dns-scope.h
diff options
context:
space:
mode:
authorLennart Poettering <lennart@poettering.net>2020-11-05 11:01:52 +0100
committerLennart Poettering <lennart@poettering.net>2021-02-09 17:58:25 +0100
commit775ae35403f8f3c01b7ac13387fe8aac1759993f (patch)
tree4d2a693ea94e2a611c133d0678630d6ff0014e6b /src/resolve/resolved-dns-scope.h
parentd8f3836ea9ddbe74e575803d833e845825eb8e54 (diff)
downloadsystemd-775ae35403f8f3c01b7ac13387fe8aac1759993f.tar.gz
resolved: add support for answering DNSSEC questions on the stub
This substantially beefs up the local DNS stub feature set in order to allow local clients to do DNSSEC validation through the stub. Previously we'd return NOTIMP if we'd get a DO or DO+CD lookup. With this change we'll instead: 1. If we get DO+CD requests (i.e. DNSSEC with no local checking) we'll proxy DNS queries and response mostly unmodified to/from upstream DNS servers if possible (this is called "bypass" mode). We will patch in new request IDs, (and patch them back out on reply), so that we can sanely keep track of things. We'll also maintain a minimal local cache for such lookups, always keeping the whole DNS packets in it (if we reply from cache we'll patch the TTLs of all included RRs). 2. If we get DO requests without CD (i.e. DNSSEC with local checking) we'll resolve and validate locally. In this mode we will not proxy packets, but generate our own. We will however cache the combination of answer RRs (along with their packet section assignments) we got back in the cache, and use this information to generate reply packets from the DNS stub. In both cases: if we determine a lookup is to be answered from LLMNR or mDNS we'll always revert to non-DNSSEC, non-proxy operation as before. Answers will lack the DO bit then, since the data cannot be validated via DNSSEC by the clients. To make this logic more debuggable, this also adds query flags for turning off RR sources. i.e. cache/network/zone/trust anchor/local synthesis may now be disabled individually for each lookup. The cache is substantially updated to make all this work: in addition to caching simple RRs for lookup RR keys, we'll now cache the whole packets and the whole combination of RRs, so that we can answer DO and DO+CD replies sensibly according to the rules described above. This sounds wasteful, but given that the DnsResourceRecord/DnsResourceKey/DnsAnswer/DnsPacket objects are all ref-counted and we try to merge references the actual additional memory used should be limited (but this might be something to optimize further later on). To implement classic RR key lookups and new-style packet proxy lookups (i.e. the ones necessary for DO+CD packet proxying, as described above) DnsTransaction and DnsQuery objects now always maintain either a DnsResourceKey/DnsQuestion as lookup key or a DnsPacket for "bypass" mode. Fixes: #4621 #17218
Diffstat (limited to 'src/resolve/resolved-dns-scope.h')
-rw-r--r--src/resolve/resolved-dns-scope.h16
1 files changed, 7 insertions, 9 deletions
diff --git a/src/resolve/resolved-dns-scope.h b/src/resolve/resolved-dns-scope.h
index de05c0838f..c7317a6bd8 100644
--- a/src/resolve/resolved-dns-scope.h
+++ b/src/resolve/resolved-dns-scope.h
@@ -53,14 +53,12 @@ struct DnsScope {
LIST_HEAD(DnsQueryCandidate, query_candidates);
- /* Note that we keep track of ongoing transactions in two
- * ways: once in a hashmap, indexed by the rr key, and once in
- * a linked list. We use the hashmap to quickly find
- * transactions we can reuse for a key. But note that there
- * might be multiple transactions for the same key (because
- * the zone probing can't reuse a transaction answered from
- * the zone or the cache), and the hashmap only tracks the
- * most recent entry. */
+ /* Note that we keep track of ongoing transactions in two ways: once in a hashmap, indexed by the rr
+ * key, and once in a linked list. We use the hashmap to quickly find transactions we can reuse for a
+ * key. But note that there might be multiple transactions for the same key (because the associated
+ * query flags might differ in incompatible ways: e.g. we may not reuse a non-validating transaction
+ * as validating. Hence we maintain a per-key list of transactions, which we iterate through to find
+ * one we can reuse with matching flags. */
Hashmap *transactions_by_key;
LIST_HEAD(DnsTransaction, transactions);
@@ -90,7 +88,7 @@ int dns_scope_mdns_membership(DnsScope *s, bool b);
int dns_scope_make_reply_packet(DnsScope *s, uint16_t id, int rcode, DnsQuestion *q, DnsAnswer *answer, DnsAnswer *soa, bool tentative, DnsPacket **ret);
void dns_scope_process_query(DnsScope *s, DnsStream *stream, DnsPacket *p);
-DnsTransaction *dns_scope_find_transaction(DnsScope *scope, DnsResourceKey *key, bool cache_ok);
+DnsTransaction *dns_scope_find_transaction(DnsScope *scope, DnsResourceKey *key, uint64_t query_flags);
int dns_scope_notify_conflict(DnsScope *scope, DnsResourceRecord *rr);
void dns_scope_check_conflicts(DnsScope *scope, DnsPacket *p);