summaryrefslogtreecommitdiff
path: root/src/resolve/resolved-dns-transaction.c
AgeCommit message (Collapse)Author
2016-06-24Merge pull request #3594 from poettering/resolved-servfailMartin Pitt
resolved fixes for handling SERVFAIL errors from servers
2016-06-24resolved: add option to disable caching (#3592)Martin Pitt
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.
2016-06-23resolved: when processing auxiliary DNSSEC transactions, accept those with ↵Lennart Poettering
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.
2016-06-23resolved: rework SERVFAIL handlingLennart Poettering
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.
2016-06-21resolved: respond to local resolver requests on 127.0.0.53:53Lennart Poettering
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.
2016-06-21resolved: when using the ResolveRecord() bus call, adjust TTL for caching timeLennart Poettering
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)
2016-06-16resolved: when restarting a transaction make sure to not touch it anymore ↵Lennart Poettering
(#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
2016-06-14resolved: make sure we initialize the ifindex of direct zone answers properlyLennart Poettering
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.
2016-05-02resolved: work around broken DNS zones set up by incapdns.netLennart Poettering
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
2016-04-08resolved: handle oom properlyZbigniew Jędrzejewski-Szmek
CID #1349699-1349700.
2016-02-29Merge pull request #2702 from poettering/resolved-iterate-fixZbigniew Jędrzejewski-Szmek
resolved iteration fix
2016-02-22tree-wide: make ++/-- usage consistent WRT spacingVito Caputo
Throughout the tree there's spurious use of spaces separating ++ and -- operators from their respective operands. Make ++ and -- operator consistent with the majority of existing uses; discard the spaces.
2016-02-22resolved: fix notification iteration logic when transactions are completedLennart Poettering
When a transaction is complete, and we notify its owners, make sure we deal correctly with the requesters removing themselves from the list of owners while we continue iterating. This was previously already dealt with with transactions that require other transactions for DNSSEC purposes, fix this for other possibly transaction owners too now. Since iterating through "Set" objects is not safe regarding removal of entries from it, rework the logic to use two Sets, and move each entry we notified from one set to the other set before we dispatch the notification. This move operation requires no additional memory, and enables us to ensure that we don't notify any object twice. Fixes: #2676
2016-02-16Use provided buffer in dns_resource_key_to_stringZbigniew Jędrzejewski-Szmek
When the buffer is allocated on the stack we do not have to check for failure everywhere. This is especially useful in debug statements, because we can put dns_resource_key_to_string() call in the debug statement, and we do not need a seperate if (log_level >= LOG_DEBUG) for the conversion. dns_resource_key_to_string() is changed not to provide any whitespace padding. Most callers were stripping the whitespace with strstrip(), and it did not look to well anyway. systemd-resolve output is not column aligned anymore. The result of the conversion is not stored in DnsTransaction object anymore. It is used only for debugging, so it seems fine to generate it when needed. Various debug statements are extended to provide more information.
2016-02-16Replace DNS_RESOURCE_KEY_NAME with a version which always returns "." for rootZbigniew Jędrzejewski-Szmek
This fixes formatting of root domain in debug messages: Old: systemd-resolved[10049]: Requesting DS to validate transaction 19313 (., DNSKEY with key tag: 19036). New: systemd-resolved[10049]: Requesting DS to validate transaction 19313 (, DNSKEY with key tag: 19036).
2016-02-16systemd-resolved: split out inner loopZbigniew Jędrzejewski-Szmek
With two nested loops and a switch statements, it's quite hard to understand what break and continue mean.
2016-02-12Typo fixesMichael Biebl
2016-02-10tree-wide: remove Emacs lines from all filesDaniel Mack
This should be handled fine now by .dir-locals.el, so need to carry that stuff in every file.
2016-02-01resolved: rework what ResolveHostname() with family == AF_UNSPEC meansLennart Poettering
Previously, if a hostanem is resolved with AF_UNSPEC specified, this would be used as indication to resolve both an AF_INET and an AF_INET6 address. With this change this logic is altered: an AF_INET address is only resolved if there's actually a routable IPv4 address on the specific interface, and similar an AF_INET6 address is only resolved if there's a routable IPv6 address. With this in place, it's ensured that the returned data is actually connectable by applications. This logic mimics glibc's resolver behaviour. Note that if the client asks explicitly for AF_INET or AF_INET6 it will get what it asked for. This also simplifies the logic how it is determined whether a specific lookup shall take place on a scope. Specifically, the checks with dns_scope_good_key() are now moved out of the transaction code and into the query code, so that we don't even create a transaction object on a specific scope if we cannot execute the resolution on it anyway.
2016-02-01resolve: fix typosTorstein Husebø
2016-01-26resolved: fix the rcode to SUCCESS if we find at least one matching RR in a ↵Lennart Poettering
DNS response If we encounter NXDOMAIN, but find at least one matching RR in a response, then patch it to become SUCCESS. This should clean up handling of CNAME/DNAMEs, and makes sure broken servers and those conforming to RFC 6604 are treated the same way. The new behaviour opposes the logic suggested in RFC 6604, but given that some servers don't implement it correctly, and given that in some ways the CNAME/DNAME chains will be incomplete anyway, and given that DNSSEC generally only allows us to prove the first element of a CNAME/DNAME chain, this should simplify things for us.
2016-01-25resolved: don't consider NSEC/NSEC3 RRs as "pimary" for transactionsLennart Poettering
So far, abritrary NSEC and NSEC3 RRs were implicitly consider "primary" for any transaction, meaning we'd abort the transaction immediately if we couldn't validate it. With this patch this logic is removed, and the NSEC/NSEC3 RRs will not be considered primary anymore. This has the effect that they will be dropped from the message if they don't validate, but processing continues. This is safe to do, as they are required anyway to validate positive wildcard and negative responses, and if they are missing then, then message will be considered unsigned, which hence means the outcome is effectively the same. This is benefical in case the server sends us NSEC/NSEC3 RRs that are not directly related to the lookup we did, but simply auxiliary information. Previously, if we couldn't authenticate those RRs we'd fail the entire lookup while with this change we'll simply drop the auxiliary information and proceed without it.
2016-01-25resolved: replace DNS_TRANSACTION_RESOURCES by DNS_TRANSACTION_ERRNOLennart Poettering
Whenever we encounter an OS error we did not expect, we so far put the transaction into DNS_TRANSACTION_RESOURCES state. Rename this state to DNS_TRANSACTION_ERRNO, and save + propagate the actual system error to the caller. This should make error messages triggered by system errors much more readable by the user.
2016-01-25resolved: log recognizably about DNSSEC downgradesLennart Poettering
If we downgrade from DNSSEC to non-DNSSEC mode, let's log about this in a recognizable way (i.e. with a message ID), after all, this is of major importance.
2016-01-25resolved: properly handle LLMNR/TCP connection errorsLennart Poettering
The LLMNR spec suggests to do do reverse address lookups by doing direct LLMNR/TCP connections to the indicated address, instead of doing any LLMNR multicast queries. When we do this and the peer doesn't actually implement LLMNR this will result in a TCP connection error, which we need to handle. In contrast to most LLMNR lookups this will give us a quick response on whether we can find a suitable name. Report this as new transaction state, since this should mostly be treated like an NXDOMAIN rcode, except that it's not one.
2016-01-25resolved: log each time we increase the DNSSEC verdict countersLennart Poettering
Also, don't consider RRs that aren't primary to the lookups we do as relevant to the lookups.
2016-01-25resolved: if we detect a message with incomplete DNSSEC data, consider this ↵Lennart Poettering
an invalid packet event
2016-01-25resolved: also collect statistics about negative DNSSEC proofsLennart Poettering
We already maintain statistics about positive DNSSEC proofs, and count them up by 1 for each validated RRset. Now, update the same counters each time we validated a negative query, so that the statistics are the combined result of all validation checks, both positive and negative.
2016-01-25resolve: generate a nice clean error when clients try to resolve a name when ↵Lennart Poettering
the network is down
2016-01-18resolved: don't try to print error strings, where errno isn't setLennart Poettering
2016-01-18resolved: when restarting a transaction pick a new IDLennart Poettering
When we restart a transaction because of an incompatible server, pick a new transaction ID. This should increase compatibility with DNS servers that don't like if they get different requests with the same transaction ID.
2016-01-18resolved: enforce maximum limit on DNS transactionsLennart Poettering
given that DNSSEC lookups may result in quite a number of auxiliary transactions, let's better be safe than sorry and also enforce a limit on the number of total transactions, not just on the number of queries.
2016-01-18resolved: fix how we detect whether auxiliary DNSSEC transactions are readyLennart Poettering
Previously, when getting notified about a completed auxiliary DNSSEC transaction we'd immediately act on it, and possibly abort the main transaction. This is problematic, as DNS transactions that already completed at the time we started using them will never get the notification event, and hence never be acted on in the same way. Hence, introduce a new call dns_transaction_dnssec_ready() that checks the state of auxiliary DNSSEC transactions, and returns 1 when we are ready for the actual DNSSEC validation step. Then, make sure this is invoked when the auxiliary transactions are first acquired (and thus possibly reused) as well when the notifications explained above take place. This fixes problems particularly when doing combined A and AAAA lookups where the auxiliary DNSSEC transactions get reused between them, and where we got confused if we reused an auxiliary DNSSEC transaction from one when it already got completed from the other.
2016-01-17resolved: when we find a DNAME RR, don't insist in a signed CNAME RRLennart Poettering
If we have a signed DNAME RR response, there's no need to insist on a signature for a CNAME RR response, after all it is unlikely to be signed, given the implicit synthethis of CNAME through DNAME RRs.
2016-01-17resolved: when the server feature level changes between query and response ↵Lennart Poettering
restart transaction In some cases we learn something about a server's feature level through its responses. If we notice that after doing basic checking of a response, and after collecting all auxiliary DNSSEC info the feature level of the server is lower than where we started, restart the whole transaction. This is useful to deal with servers that response rubbish when talked to with too high feature levels.
2016-01-17resolved: check OPT RR before accepting a reply for verification of server ↵Lennart Poettering
feature level Let's make sure we first check if the OPT was lost in the reply, before we accept a reply as successful and use it for verifying the current feature level.
2016-01-17resolved: when restarting a DNS transaction, remove all auxiliary DNSSEC ↵Lennart Poettering
transactions When we restart a DNS transaction, remove all connections to any auxiliary DNSSEC transactions, after all we might acquire completely different data this time, requiring different auxiliary DNSSEC transactions.
2016-01-17resolved: downgrade server feature level more aggressively when we have ↵Lennart Poettering
reason to This adds logic to downgrade the feature level more aggressively when we have reason to. Specifically: - When we get a response packet that lacks an OPT RR for a query that had it. If so, downgrade immediately to UDP mode, i.e. don't generate EDNS0 packets anymore. - When we get a response which we are sure should be signed, but lacks RRSIG RRs, we downgrade to EDNS0 mode, i.e. below DO mode, since DO is apparently not really supported. This should increase compatibility with servers that generate non-sensical responses if they messages with OPT RRs and suchlike, for example the situation described here: https://open.nlnetlabs.nl/pipermail/dnssec-trigger/2014-November/000376.html This also changes the downgrade code to explain in a debug log message why a specific downgrade happened.
2016-01-17resolved: rename dnssec_verify_dnskey() → dnssec_verify_dnskey_by_ds()Lennart Poettering
This should clarify that this is not regular signature-based validation, but validation through DS RR fingerprints.
2016-01-17resolved: when validating an RRset, store information about the synthesizing ↵Lennart Poettering
source and zone in each RR Having this information available is useful when we need to check whether various RRs are suitable for proofs. This information is stored in the RRs as number of labels to skip from the beginning of the owner name to reach the synthesizing source/signer. Simple accessor calls are then added to retrieve the signer/source from the RR using this information. This also moves validation of a a number of RRSIG parameters into a new call dnssec_rrsig_prepare() that as side-effect initializes the two numeric values.
2016-01-13resolved: implement the full NSEC and NSEC3 postive wildcard proofsLennart Poettering
2016-01-11resolved: refuse doing queries for known-obsolete RR typesLennart Poettering
Given how fragile DNS servers are with some DNS types, and given that we really should avoid confusing them with known-weird lookups, refuse doing lookups for known-obsolete RR types.
2016-01-11resolved: rename DnsTransaction's current_features field to ↵Lennart Poettering
current_feature_level This is a follow-up for f4461e5641d53f27d6e76e0607bdaa9c0c58c1f6.
2016-01-11resolved: accept rightfully unsigned NSEC responsesLennart Poettering
2016-01-11resolved: rework how and when we detect whether our chosen DNS server knows ↵Lennart Poettering
DNSSEC Move detection into a set of new functions, that check whether one specific server can do DNSSEC, whether a server and a specific transaction can do DNSSEC, or whether a transaction and all its auxiliary transactions could do so. Also, do these checks both before we acquire additional RRs for the validation (so that we can skip them if the server doesn't do DNSSEC anyway), and after we acquired them all (to see if any of the lookups changed our opinion about the servers). THis also tightens the checks a bit: a server that lacks TCP support is considered incompatible with DNSSEC too.
2016-01-11resolved: rework server feature level logicLennart Poettering
This changes the DnsServer logic to count failed UDP and TCP failures separately. This is useful so that we don't end up downgrading the feature level from one UDP level to a lower UDP level just because a TCP connection we did because of a TC response failed. This also adds accounting of truncated packets. If we detect incoming truncated packets, and count too many failed TCP connections (which is the normal fall back if we get a trucnated UDP packet) we downgrade the feature level, given that the responses at the current levels don't get through, and we somehow need to make sure they become smaller, which they will do if we don't request DNSSEC or EDNS support. This makes resolved work much better with crappy DNS servers that do not implement TCP and only limited UDP packet sizes, but otherwise support DNSSEC RRs. They end up choking on the generally larger DNSSEC RRs and there's no way to retrieve the full data.
2016-01-11resolved: log why we use TCP when UDP isn't supported by a serverLennart Poettering
2016-01-11resolved: log about truncated replies before trying again, not afterLennart Poettering
2016-01-11resolved: don't attempt to send queries for DNSSEC RR types to servers not ↵Lennart Poettering
supporting them If we already degraded the feature level below DO don't bother with sending requests for DS, DNSKEY, RRSIG, NSEC, NSEC3 or NSEC3PARAM RRs. After all, we cannot do DNSSEC validation then anyway, and we better not press a legacy server like this with such modern concepts. This also has the benefit that when we try to validate a response we received using DNSSEC, and we detect a limited server support level while doing so, all further auxiliary DNSSEC queries will fail right-away.
2016-01-11resolved: log about reasons for switching to TCPLennart Poettering