summaryrefslogtreecommitdiff
path: root/src/resolve/resolved-dns-query.c
AgeCommit message (Collapse)Author
2016-07-11treewide: fix typos and remove accidental repetition of wordsTorstein Husebø
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-05-04treewide: fix typos (#3187)Torstein Husebø
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-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-04resolved: don't follow CNAMEs originating from DNS on LLMNRLennart Poettering
Fixes: #2514
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-01-26resolved: teach resolved the difference between "routing" and "search" domainsLennart Poettering
Following the changes to expose the "routing" and "search" domain concepts in networkd, actually make resolved use them. It will now use routing domains exclusively for making DNS routing decisions, and use search domains additionally for extending single-label names.
2016-01-25resolved: use dns_query_reset_answer() where we canLennart Poettering
2016-01-25resolved: properly propagate query candidate errorLennart Poettering
We already properly propagate errors from transactions to queries. Make sure that errors that happened during handling of query candidates are propagated to the query, too.
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: synthesize RRs for data from /etc/hostsLennart Poettering
This way the difference between lookups via NSS and our native bus API should become minimal.
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: split out RR synthesis logic into its own C fileLennart Poettering
Also, while we are at it, set the "authenticated" bit for everything we synthesize
2016-01-25resolved: move dns_type_to_af() to dns-type.cLennart Poettering
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: end log messages in a full stopLennart Poettering
2016-01-18resolved: never consider following a CNAME/DNAME chain for a CNAME/DNAME lookupLennart Poettering
Let's avoid thinking that a CNAME/DNAME chain traversal could be a good idea if QTYPE is already CNAME/DNAME. (Also, let's bail out early when trying to see if some RR is a suitable CNAME/DNAME for some other RR).
2016-01-18resolved: when following a CNAME, turn off search domainsLennart Poettering
If the first step was done via a search domain, make sure the subsequent steps are not.
2016-01-18resolved: properly reset old collected data when following a CNAME redirectLennart Poettering
2016-01-18resolved: rework IDNA logicLennart Poettering
Move IDNA logic out of the normal domain name processing, and into the bus frontend calls. Previously whenever comparing two domain names we'd implicitly do IDNA conversion so that "pöttering.de" and "xn--pttering-n4a.de" would be considered equal. This is problematic not only for DNSSEC, but actually also against he IDNA specs. Moreover it creates problems when encoding DNS-SD services in classic DNS. There, the specification suggests using UTF8 encoding for the actual service name, but apply IDNA encoding to the domain suffix. With this change IDNA conversion is done only: - When the user passes a non-ASCII hostname when resolving a host name using ResolveHostname() - When the user passes a non-ASCII domain suffix when resolving a service using ResolveService() No IDNA encoding is done anymore: - When the user does raw ResolveRecord() RR resolving - On the service part of a DNS-SD service name Previously, IDNA encoding was done when serializing names into packets, at a point where information whether something is a label that needs IDNA encoding or not was not available, but at a point whether it was known whether to generate a classic DNS packet (where IDNA applies), or an mDNS/LLMNR packet (where IDNA does not apply, and UTF8 is used instead for all host names). With this change each DnsQuery object will now maintain two copies of the DnsQuestion to ask: one encoded in IDNA for use with classic DNS, and one encoded in UTF8 for use with LLMNR and MulticastDNS.
2016-01-17resolved: fix logging about DNAME redirectionLennart Poettering
2016-01-11resolved: set a description on all our event sourcesLennart Poettering
2016-01-07resolved: query_process_cname - make fully recursiveTom Gundersen
This ensures we properly resolve the CNAME chain as far as we can, rather than only CNAME chains of length one.
2015-12-26resolved: never use data from failed transactionsLennart Poettering
Otherwise if we have an A lookup that failed DNSSEC validation, but an AAAA lookup that succeeded, we might end up using the A data, but we really should not.
2015-12-18resolved: propagate the DNSSEC result from the transaction to the query and ↵Lennart Poettering
the the bus client It's useful to generate useful errors, so let's do that.
2015-12-18resolved: rename DNS_TRANSACTION_FAILURE → DNS_TRANSACTION_RCODE_FAILURELennart Poettering
We have many types of failure for a transaction, and DNS_TRANSACTION_FAILURE was just one specific one of them, if the server responded with a non-zero RCODE. Hence let's rename this, to indicate which kind of failure this actually refers to.
2015-12-18resolved: add support NSEC3 proofs, as well as proofs for domains that are ↵Lennart Poettering
OK to be unsigned This large patch adds a couple of mechanisms to ensure we get NSEC3 and proof-of-unsigned support into place. Specifically: - Each item in an DnsAnswer gets two bit flags now: DNS_ANSWER_AUTHENTICATED and DNS_ANSWER_CACHEABLE. The former is necessary since DNS responses might contain signed as well as unsigned RRsets in one, and we need to remember which ones are signed and which ones aren't. The latter is necessary, since not we need to keep track which RRsets may be cached and which ones may not be, even while manipulating DnsAnswer objects. - The .n_answer_cachable of DnsTransaction is dropped now (it used to store how many of the first DnsAnswer entries are cachable), and replaced by the DNS_ANSWER_CACHABLE flag instead. - NSEC3 proofs are implemented now (lacking support for the wildcard part, to be added in a later commit). - Support for the "AD" bit has been dropped. It's unsafe, and now that we have end-to-end authentication we don't need it anymore. - An auxiliary DnsTransaction of a DnsTransactions is now kept around as least as long as the latter stays around. We no longer remove the auxiliary DnsTransaction as soon as it completed. THis is necessary, as we now are interested not only in the RRsets it acquired but also in its authentication status.
2015-12-14resolved: don't choke on NULL DNS transactions when determining query ↵Lennart Poettering
candidate state
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: log when we chase a CNAME RRLennart Poettering
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: don't bother with picking a search domain when searching is disabledLennart Poettering
2015-11-29tree-wide: remove unused variablesThomas Hindoe Paaboel Andersen
2015-11-27resolved: don't follow the global search list on local scopesLennart Poettering
It probably doesn't make sense to mix local and global configuration. Applying global search lists to local DNS servers appears unnecessary and creates problems because we'll traverse the search domains non-simultaneously on multiple scopes. Also see: https://github.com/systemd/systemd/pull/2031
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-25resolved: don't claim DnsQuestion have to have the same namesLennart Poettering
Wen DnsQuestion objects are used for DnsQuery objects all contained keys have to share the same name, but otherwise they generally don't have to, and this can actually happen in real-life because DnsPacket objects for mDNS use DnsQuestion for the question section. Hence, rename: dns_question_is_valid() to dns_question_is_valid_for_query(), since the name uniqueness check it does is only relevant when used for a query. Similar, rename dns_question_name() to dns_question_first_name(), to be more accurate, as this difference matters if we keys don#t have to share the same name.
2015-11-23resolved: add ResolveService() bus call for resolving SRV and DNS-SD servicesLennart Poettering
This also adds client-side support for this to systemd-resolve-host. Note that the ResolveService() API can deal both with DNS-SD service (consisting of service name, type and domain), as well as classic SRV services (consisting just of a type and a domain), all exposed in the same call. This patch also reworks CNAME handling in order to reuse it between hostname, RR and service lookups. In contrast to Avahi and Bonjour, this new API will actually reolve the A/AAAA RRs the SRV RRs point to in one go (unless this is explicitly disabled). This normally comes for free, as these RRs are sent along the SRV responses anyway, hence let's make use of that. This makes the API considerably easier to use, as a single ResolveService() invocation will return all necessary data to pick a server and connect() to it. Note that this only implements the DNS-SD resolving step, it does not implement DNS-SD browsing, as that makes sense primarily on mDNS, due to its continuous nature.
2015-10-27util-lib: split out allocation calls into alloc-util.[ch]Lennart Poettering
2015-09-16resolved: rr - introduce dns_resource_key_new_redirect()Tom Gundersen
Takes a key and CNAME RR and returns the canonical RR of the right type. Make use of this in dns_question_redirect().
2015-08-24resolved: remove duplicate handling of "no servers" query resultLennart Poettering
So far we handled immediate "no server" query results differently from "no server" results we ran into during operation: the former would cause the dns_query_go() call to fail with ESRCH, the later would result in the query completion callback to be called. Remove the duplicate codepaths, by always going through the completion callback. This allows us to remove quite a number of lines for handling the ESRCH. This commit should not alter behaviour at all.
2015-08-21resolved: always split up questions into per-RR transactionsLennart Poettering
We do so for Unicast DNS and LLMNR anyway, let's also do this for mDNS, and simplify things.
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: rework synthesizing logicLennart Poettering
With this change we'll now also generate synthesized RRs for the local LLMNR hostname (first label of system hostname), the local mDNS hostname (first label of system hostname suffixed with .local), the "gateway" hostname and all the reverse PTRs. This hence takes over part of what nss-myhostname already implemented. Local hostnames resolve to the set of local IP addresses. Since the addresses are possibly on different interfaces it is necessary to change the internal DnsAnswer object to track per-RR interface indexes, and to change the bus API to always return the interface per-address rather than per-reply. This change also patches the existing clients for resolved accordingly (nss-resolve + systemd-resolve-host). This also changes the routing logic for queries slightly: we now ensure that the local hostname is never resolved via LLMNR, thus making it trustable on the local system.
2015-08-14resolved: locally synthesize replies for "localhost"Lennart Poettering
Let's make sure that clients querying resolved via the bus for A, AAAA or PTR records for "localhost" get a synthesized, local reply, so that we do not hit the network. This makes part of nss-myhostname redundant, if used in conjunction. However, given that nss-resolve shall be optional we need to keep this code in both places for now.