| Age | Commit message (Collapse) | Author |
|---|
|
CNAME records are special in the way they are treated by DNS servers,
and our cache should mimic that behavior: In case a domain name has an
alias, its CNAME record is returned in place of any other.
Our cache was not doing this despite caching the CNAME records, this
entailed needless lookups to re-resolve the CNAME.
|
|
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.
|
|
Takes a key and CNAME RR and returns the canonical RR of the right
type. Make use of this in dns_question_redirect().
|
|
Creates a new CNAME RR key with the same class and name as an existing key.
|
|
|
|
And set_free() too.
Another Coccinelle patch.
|
|
Another Coccinelle patch.
|
|
Patch via coccinelle.
|
|
Turns this:
r = -errno;
log_error_errno(errno, "foo");
into this:
r = log_error_errno(errno, "foo");
and this:
r = log_error_errno(errno, "foo");
return r;
into this:
return log_error_errno(errno, "foo");
|
|
|
|
Otherwise the epoll removal will fail and result in a warning.
|
|
|
|
Bring back a return statement 106784eb errornously removed.
Thanks to @phomes for reporting.
|
|
Some flags are defined differently on unicast DNS and LLMNR, let's
document this in the DNS_PACKET_MAKE_FLAGS() macro.
|
|
This partially reverts 106784ebb7b303ae471851100a773ad2aebf5b80, ad
readds separate DNS_PACKET_MAKE_FLAGS() invocations for the LLMNR and
DNS case. This is important since SOme flags have different names and
meanings on LLMNR and on DNS and we should clarify that via the comments
and how we put things together.
|
|
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.
|
|
Currently, dns_cache_put() does a number of things:
1) It unconditionally removes all keys contained in the passed
question before adding keys from the newly arrived answers.
2) It puts positive entries into the cache for all RRs contained
in the answer.
3) It creates negative entries in the cache for all keys in the
question that are not answered.
Allow passing q = NULL in the parameters and skip 1) and 3), so
we can use that function for mDNS responses. In this case, the
question is irrelevant, we are interested in all answers we got.
|
|
Make a scope with invalid protocol state fail as soon as possible.
|
|
With more protocols to come, switch repetitive if-else blocks with a
switch-case statements.
|
|
|
|
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.
|
|
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.
|
|
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.
|
|
only maintain one question RR key per transaction and other fixes
|
|
We do so for Unicast DNS and LLMNR anyway, let's also do this for mDNS,
and simplify things.
|
|
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.
|
|
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.
|
|
|
|
|
|
We explicitly need to turn off name compression when marshalling or
demarshalling RRs for bus transfer, since they otherwise refer to packet
offsets that reference packets that are not transmitted themselves.
|
|
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.
|
|
Following our usual logic of treating NULL arrays as empty arrays (for
example, see strv.c) do the same for questions too.
|
|
|
|
Delete unnecessary checks before some function calls
|
|
The following functions return immediately if a null pointer was passed.
* calendar_spec_free
* link_address_free
* manager_free
* sd_bus_unref
* sd_journal_close
* udev_monitor_unref
* udev_unref
It is therefore not needed that a function caller repeats a corresponding check.
This issue was fixed by using the software Coccinelle 1.0.1.
|
|
|
|
|
|
We should never allow leaking of "localhost" queries onto the network,
even if there's an explicit domain rotue set for this.
|
|
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.
|
|
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.
|
|
With the exponential backoff, we can perform more requests in the same amount of time,
so bump this a bit.
In case of large RTT this may be necessary in order not to regress, and in case
of large packet-loss it will make us more robust. The latter is particularly
relevant once we start probing for features (and hence may see packet-loss
until we settle on the right feature level).
|
|
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.
|
|
We cannot rely on CLOCK_BOOTTIME being supported by the kernel, so fallack
to CLOCK_MONOTONIC if the former is not supported.
|
|
resolved: never attempt to resolve loopback addresses via DNS/LLMNR/mDNS
|
|
We already refuse to resolve "localhost", hence we should also refuse
resolving "127.0.0.1" and friends.
|
|
|
|
The NSEC type itself must at least be in the bitmap, so NSEC records with empty
bitmaps must be bogus.
|
|
We were tracking the bit offset inside each byte, rather than inside the whole bitmap.
|
|
We were counting the number of bits set rather than the number of bytes they occupied.
|
|
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.
|
