summaryrefslogtreecommitdiff
path: root/src/resolve/resolved-dns-transaction.c
AgeCommit message (Collapse)Author
2015-12-10resolved: don't accept doing queries for invalid RR typesLennart Poettering
2015-12-10resolved: chase DNSKEY/DS RRs when doing look-ups with DNSSEC enabledLennart Poettering
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.
2015-12-10resolved: reenable caching for LLMNRLennart Poettering
This got borked in 547493c5ad5c82032e247609970f96be76c2d661.
2015-12-10resolved: split out check whether reply matches our questionLennart Poettering
It's complicated enough, it deserves its own call. (Also contains some unrelated whitespace, comment and assertion changes)
2015-12-08resolved: add dns_cache_export_to_packet()Daniel Mack
This new functions exports cached records of type PTR, SRV and TXT into an existing DnsPacket. This is used in order to fill in known records to mDNS queries, for known answer supression.
2015-12-08resolved: implement query coalescingDaniel Mack
Implement dns_transaction_make_packet_mdns(), a special version of dns_transaction_make_packet() for mDNS which differs in many ways: a) We coalesce queries of currently active transaction on the scope. This is possible because mDNS actually allows many questions in a to be sent in a single packet and it takes some burden from the network. b) Both A and AAAA query keys are broadcast on both IPv4 and IPv6 scopes, because other hosts might only respond on one of their addresses but resolve both types. c) We discard previously sent packages (t->sent) so we can start over and coalesce pending transactions again.
2015-12-08resolved: add 'next_attempt_after' field to DnsTransactionDaniel Mack
For each transaction, record when the earliest point in time when the query packet may hit the wire. This is the same time stamp for which the timer is scheduled in retries, except for the initial query packets which are delayed by a random jitter. In this case, we denote that the packet may actually be sent at the nominal time, without the jitter. Transactions that share the same timestamp will also have identical values in this field. It is used to coalesce pending queries in a later patch.
2015-12-08resolved: split dns_transaction_go()Daniel Mack
Split some code out of dns_transaction_go() so we can re-use it later from different context. The new function dns_transaction_prepare_next_attempt() takes care of preparing everything so that a new packet can conditionally be formulated for a transaction. This patch shouldn't cause any functional change.
2015-12-08resolved: handle more mDNS protocol detailsDaniel Mack
2015-12-08resolved: fix debug messageDaniel Mack
2015-12-08resolved: handle mDNS timeouts per transactionDaniel Mack
mDNS packet timeouts need to be handled per transaction, not per link. Re-use the n_attempts field for this purpose, as packets timeouts should be determined by starting at 1 second, and doubling the value on each try.
2015-12-08resolved: short-cut jitter callbacks for LLMNR and mDNSDaniel Mack
When a jitter callback is issued instead of sending a DNS packet directly, on_transaction_timeout() is invoked to 'retry' the transaction. However, this function has side effects. For once, it increases the packet loss counter on the scope, and it also unrefs/refs the server instances. Fix this by tracking the jitter with two bool variables. One saying that the initial jitter has been scheduled in the first place, and one that tells us the delay packet has been sent.
2015-12-08resolved: add mDNS initial jitterDaniel Mack
The logic is to kick off mDNS packets in a delayed way is mostly identical to what LLMNR needs, except that the constants are different.
2015-12-08resolved: add packet header details for mDNSDaniel Mack
Validate mDNS queries and responses by looking at some header fields, add mDNS flags.
2015-12-03resolved: add a concept of "authenticated" responsesLennart Poettering
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.
2015-12-03resolved: introduce a dnssec_mode setting per scopeLennart Poettering
The setting controls which kind of DNSSEC validation is done: none at all, trusting the AD bit, or client-side validation. For now, no validation is implemented, hence the setting doesn't do much yet, except of toggling the CD bit in the generated messages if full client-side validation is requested.
2015-12-03resolved: add a simple trust anchor database as additional RR sourceLennart Poettering
When doing DNSSEC lookups we need to know one or more DS or DNSKEY RRs as trust anchors to validate lookups. With this change we add a compiled-in trust anchor database, serving the root DS key as of today, retrieved from: https://data.iana.org/root-anchors/root-anchors.xml The interface is kept generic, so that additional DS or DNSKEY RRs may be served via the same interface, for example by provisioning them locally in external files to support "islands" of security. The trust anchor database becomes the fourth source of RRs we maintain, besides, the network, the local cache, and the local zone.
2015-11-27resolved: announce support for large UDP packetsTom Gundersen
This is often needed for proper DNSSEC support, and even to handle AAAA records without falling back to TCP. If the path between the client and server is fully compliant, this should always work, however, that is not the case, and overlarge packets will get mysteriously lost in some cases. For that reason, we use a similar fallback mechanism as we do for palin EDNS0, EDNS0+DO, etc.: The large UDP size feature is different from the other supported feature, as we cannot simply verify that it works based on receiving a reply (as the server will usually send us much smaller packets than what we claim to support, so simply receiving a reply does not mean much). For that reason, we keep track of the largest UDP packet we ever received, as this is the smallest known good size (defaulting to the standard 512 bytes). If announcing the default large size of 4096 fails (in the same way as the other features), we fall back to the known good size. The same logic of retrying after a grace-period applies.
2015-11-27resolved: implement minimal EDNS0 supportTom Gundersen
This is a minimal implementation of RFC6891. Only default values are used, so in reality this will be a noop. EDNS0 support is dependent on the current server's feature level, so appending the OPT pseudo RR is done when the packet is emitted, rather than when it is assembled. To handle different feature levels on retransmission, we strip off the OPT RR again after sending the packet. Similarly, to how we fall back to TCP if UDP fails, we fall back to plain UDP if EDNS0 fails (but if EDNS0 ever succeeded we never fall back again, and after a timeout we will retry EDNS0).
2015-11-27resolved: degrade the feature level on explicit failureTom Gundersen
Previously, we would only degrade on packet loss, but when adding EDNS0 support, we also have to handle the case where the server replies with an explicit error.
2015-11-27resolved: fallback to TCP if UDP failsTom Gundersen
This is inspired by the logic in BIND [0], follow-up patches will implement the reset of that scheme. If we get a server error back, or if after several attempts we don't get a reply at all, we switch from UDP to TCP for the given server for the current and all subsequent requests. However, if we ever successfully received a reply over UDP, we never fall back to TCP, and once a grace-period has passed, we try to upgrade again to using UDP. The grace-period starts off at five minutes after the current feature level was verified and then grows exponentially to six hours. This is to mitigate problems due to temporary lack of network connectivity, but at the same time avoid flooding the network with retries when the feature attempted feature level genuinely does not work. Note that UDP is likely much more commonly supported than TCP, but depending on the path between the client and the server, we may have more luck with TCP in case something is wrong. We really do prefer UDP though, as that is much more lightweight, that is why TCP is only the last resort. [0]: <https://kb.isc.org/article/AA-01219/0/Refinements-to-EDNS-fallback-behavior-can-cause-different-outcomes-in-Recursive-Servers.html>
2015-11-27resolved: never cache RRs originating from localhostLennart Poettering
After all, this is likely a local DNS forwarder that caches anyway, hence there's no point in caching twice. Fixes #2038.
2015-11-27resolved: handle properly if there are multiple transactions for the same ↵Lennart Poettering
key per scope When the zone probing code looks for a transaction to reuse it will refuse to look at transactions that have been answered from cache or the zone itself, but insist on the network. This has the effect that there might be multiple transactions around for the same key on the same scope. Previously we'd track all transactions in a hashmap, indexed by the key, which implied that there would be only one transaction per key, per scope. With this change the hashmap will only store the most recent transaction per key, and a linked list will be used to track all transactions per scope, allowing multiple per-key per-scope. Note that the linked list fields for this actually already existed in the DnsTransaction structure, but were previously unused.
2015-11-27resolved: for a transaction, keep track where the answer data came fromLennart Poettering
Let's track where the data came from: from the network, the cache or the local zone. This is not only useful for debugging purposes, but is also useful when the zone probing wants to ensure it's not reusing transactions that were answered from the cache or the zone itself.
2015-11-27resolved: store just the DnsAnswer instead of a DnsPacket as answer in ↵Lennart Poettering
DnsTransaction objects Previously we'd only store the DnsPacket in the DnsTransaction, and the DnsQuery would then take the DnsPacket's DnsAnswer and return it. With this change we already pull the DnsAnswer out inside the transaction. We still store the DnsPacket in the transaction, if we have it, since we still need to determine from which peer a response originates, to implement caching properly. However, the DnsQuery logic doesn't care anymore for the packet, it now only looks at answers and rcodes from the successfuly candidate. This also has the benefit of unifying how we propagate incoming packets, data from the local zone or the local cache.
2015-11-25resolved: fully support DNS search domainsLennart Poettering
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
2015-11-18resolved: shortcut lookups names in the local zoneLennart Poettering
Previously, we'd always generate a packet on the wire, even for names that are within our local zone. Shortcut this, and always check the local zone first. This should minimize generated traffic and improve security.
2015-10-27util-lib: split out allocation calls into alloc-util.[ch]Lennart Poettering
2015-10-27util-lib: move more locale-related calls to locale-util.[ch]Lennart Poettering
2015-10-27util-lib: move string table stuff into its own string-table.[ch]Lennart Poettering
2015-10-25util-lib: split out fd-related operations into fd-util.[ch]Lennart Poettering
There are more than enough to deserve their own .c file, hence move them over.
2015-09-16resolved: cache - only allow putting a single question key at a timeTom Gundersen
Only one key is allowed per transaction now, so let's simplify things and only allow putting one question key into the cache at a time.
2015-08-25resolved: rename DNS UDP socket to 'dns_udp_fd'Lennart Poettering
This hopefully makes this a bit more expressive and clarifies that the fd is not used for the DNS TCP socket. This also mimics how the LLMNR UDP fd is named in the manager object.
2015-08-25resolved: move assertionDaniel Mack
Make a scope with invalid protocol state fail as soon as possible.
2015-08-25resolved: use switch-case statements for protocol detailsDaniel Mack
With more protocols to come, switch repetitive if-else blocks with a switch-case statements.
2015-08-25resolved: remove runtime check for previously asserted conditionDaniel Mack
2015-08-24resolved: change error code when trying to resolve direct LLMNR PTR RRsLennart Poettering
If we try to resoolve an LLMNR PTR RR we shall connect via TCP directly to the specified IP address. We already refuse to do this if the address to resolve is of a different address family as the transaction's scope. The error returned was EAFNOSUPPORT. Let's change this to ESRCH which is how we indicate "not server available" when connecting for LLMNR or DNS, since that's what this really is: we have no server we could connect to in this address family. This allows us to ensure that no server errors are always handled the same way.
2015-08-24resolved: replace transaction list by hashmapLennart Poettering
Right now we keep track of ongoing transactions in a linked listed for each scope. Replace this by a hashmap that is indexed by the RR key. Given that all ongoing transactions will be placed in pretty much the same scopes usually this should optimize behaviour. We used to require a list here, since we wanted to do "superset" query checks, but this became obsolete since transactions are now single-key instead of multi-key.
2015-08-21resolved: only maintain one question RR key per transactionLennart Poettering
Let's simplify things and only maintain a single RR key per transaction object, instead of a full DnsQuestion. Unicast DNS and LLMNR don't support multiple questions per packet anway, and Multicast DNS suggests coalescing questions beyond a single dns query, across the whole system.
2015-08-21resolved: add extra check for family when doing LLMNR TCP connectionsLennart Poettering
It shouldn't happen that we try to resolve IPv4 addresses via LLMNR on IPv6 and vice versa, but let's explicitly verify that we don't turn an IPv4 LLMNR lookup into an IPv6 TCP connection.
2015-08-21resolved: minor typo comment fixLennart Poettering
2015-08-17resolved: cache - add more detailed cache debug loggingTom Gundersen
2015-08-03sd-event: make sure sd_event_now() cannot failLennart Poettering
Previously, if the event loop never ran before sd_event_now() would fail. With this change it will instead fall back to invoking now(). This way, the function cannot fail anymore, except for programming error when invoking it with wrong parameters. This takes into account the fact that many callers did not handle the error condition correctly, and if the callers did, then they kept simply invoking now() as fall back on their own. Hence let's shorten the code using this call, and make things more robust, and let's just fall back to now() internally. Whether now() is used or the cache timestamp may still be detected via the return value of sd_event_now(). If > 0 is returned, then the fall back to now() was used, if == 0 is returned, then the cached value was returned. This patch also simplifies many of the invocations of sd_event_now(): the manual fall back to now() can be removed. Also, in cases where the call is invoked withing void functions we can now protect the invocation via assert_se(), acknowledging the fact that the call cannot fail anymore except for programming errors with the parameters. This change is inspired by #841.
2015-08-03resolved: transaction - exponentially increase retry timeoutsTom Gundersen
Rather than fixing this to 5s for unicast DNS and 1s for LLMNR, start at a tenth of those values and increase exponentially until the old values are reached. For LLMNR the recommended timeout for IEEE802 networks (which basically means all of the ones we care about) is 100ms, so that should be uncontroversial. For unicast DNS I have found no recommended value. However, it seems vastly more likely that hitting a 500ms timeout is casued by a packet loss, rather than the RTT genuinely being greater than 500ms, so taking this as a startnig value seems reasonable to me. In the common case this greatly reduces the latency due to normal packet loss. Moreover, once we get support for probing for features, this means that we can send more packets before degrading the feature level whilst still allowing us to settle on the correct feature level in a reasonable timeframe. The timeouts are tracked per server (or per scope for the multicast protocols), and once a server (or scope) receives a successfull package the timeout is reset. We also track the largest RTT for the given server/scope, and always start our timouts at twice the largest observed RTT.
2015-07-28resolved: compare dns question arrays properlyLennart Poettering
Let's optimize things a bit and properly compare DNS question arrays, instead of checking if they are mutual supersets. This also makes ANY query handling more accurate.
2015-07-27resolved: transaction - don't explicitly verify packet sourceTom Gundersen
This is handled by the kernel now that the socket is connect()ed.
2015-07-27resolved: transaction - don't unref server when creating TCP socketTom Gundersen
This was a bug.
2015-07-27resolved: transaction - introduce dns_transaction_emit()Tom Gundersen
This function emits the UDP packet via the scope, but first it will determine the current server (and connect to it) and store the server in the transaction. This should not change the behavior, but simplifies the code.
2015-07-27resolved: transaction - move a couple of functionsTom Gundersen
No functional change, but makes follow-up patch clearer.
2015-07-27resolved: transaction - move DNS UDP socket creation to the scopeTom Gundersen
With access to the server when creating the socket, we can connect() to the server and hence simplify message sending and receiving in follow-up patches.