There are two functional changes in this commit.
1) When searching for an in-flight DNSSEC query to use
(rather than starting a new one), compare the already
sent query (stored in the frec "stash" field, rather than
using the hash of the query. This is probably faster (no hash
calculation) and eliminates having to worry about the
consequences of a hash collision.
2) Check for dependency loops in DNSSEC validation,
say validating A requires DS B and validating DS B
requires DNSKEY C and validating DNSKEY C requires DS B.
This should never happen in correctly signed records, but it's
likely the case that sufficiently broken ones can cause
our validation code requests to exhibit cycles.
The result is that the ->blocking_query list
can form a cycle, and under certain circumstances that can lock us in
an infinite loop.
Instead we transform the situation into an ABANDONED state.
Previously, hash_questions() would return a random hash
if the packet was malformed, and probably the hash of a previous
query. Now handle this as an error.
The 2.86 upstream server rewrite severely broke re-reading
of server configuration. It would get everyting right the first
time, but on re-reading /etc/resolv.conf or --servers-file
or setting things with DBUS, the results were just wrong.
This should put things right again.
Fix the following build failure with gcc 4.8 raised since version 2.86:
option.c: In function 'one_opt':
option.c:2445:11: error: 'for' loop initial declarations are only allowed in C99 mode
for (char *p = arg; *p; p++) {
^
option.c:2445:11: note: use option -std=c99 or -std=gnu99 to compile your code
option.c:2453:11: error: 'for' loop initial declarations are only allowed in C99 mode
for (u8 i = 0; i < sizeof(daemon->umbrella_device); i++, arg+=2) {
^
Fixes:
- http://autobuild.buildroot.org/results/39b34a4e69fc10f4bd9d4ddb0ed8c0aae5741c84
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
To be treated as hex, the pattern must consist of only hex digits AND
contain at least one ':'. Thanks to Bengt-Erik Sandstrom who tripped
over a pattern consisting of a decimal number which was interpreted
surprisingly.
Fix error created in 1ce1c6beae
Many thanks to Hartmut Birr for finding the bug and bisecting to
the guilty commit.
The breaking commit creates cache entries which have F_NXDOMAIN
set but none of F_IPV4, F_IPV6 or F_SRV. If cache_scan_free() is called
to delete such an entry it will fail to do so.
If the cache has no free slots and the least-recently-used slot is such
an entry, then a new insertion will attempt to make space by calling
cache_scan_free(), which will fail when it should be impossible and
trigger the internal error.
The 2.86 domain-match rewrite changed matching from
whole-labels to substring matching, so example.com
would match example.com and www.example.com, as before,
but also goodexample.com, which is a regression. This
restores the original behaviour.
Also restore the behaviour of --rebind-domain-ok=//
to match domains with onlt a single label and no dots.
Thanks to Sung Pae for reporting these bugs and supplying
an initial patch.
The IDs logged when --log-queries=extra is in effect
can be wrong in three cases.
1) When query is retried in response to a a SERVFAIL or REFUSED
answer from upstream. In this case the ID of an unrelated query will
appear in the answer log lines.
2) When the same query arrives from two clients. The query is
sent upstream once, as designed, and the result returned to both clients,
as designed, but the reply to the first client gets the log-ID of the
second query in error.
3) When a query arrives, is sent upstream, and the reply comes back,
but the transaction is blocked awaiting a DNSSEC query needed to validate
the reply. If the client retries the query in this state, the blocking
DNSSEC query will be resent, as designed, but that send will be logged with
the ID of the original, currently blocked, query.
Thanks to Dominik Derigs for his analysis of this problem.
The domain-match rewrite didn't take into account
that domain names are case-insensitive, so things like
--address=/Example.com/.....
didn't work correctly.
Transitional encoding accepts every emoticon you can think about.
Because setlocale were not enabled before, IDN 2003 input was not
accepted by dnsmasq. It makes no sense therefore to maintain backward
compatibility. Accept only proper encoded unicode names and reject
random unicode characters.
Signed-off-by: Petr Menšík <pemensik@redhat.com>
--address=/münchen.de/ is not accepted unless LOCALEDIR is defined on
build. It is not by default. If LIBIDN1 or 2 is defined, call setlocale
to initialize locale required to translate domains to ascii form.
Signed-off-by: Petr Menšík <pemensik@redhat.com>
If dnsmasq re-reads a resolv file, and it's empty, it will
retry after a delay. In the meantime, the old servers from the
resolv file have been deleted, but the servers_array doesn't
get updated, leading to dangling pointers and crashes.
Thanks to Brad Jorsch for finding and analysing this bug.
This problem was introduced in 2.86.
The dnsmasq_time() function, in the case of HAVE_BROKEN_RTC, was calling
times() to read the number of ticks "elapsed since an arbitrary point in
the past" and then dividing that by sysconf(_SC_CLK_TCK) to compute the
number of seconds elapsed since that arbitrary instant. This works fine
until the number of ticks exceeds 2^31, beyond which time the function
would begin erroneously returning negative times. On my system this
happens after approximately 248 days of uptime. A symptom is that
dnsmasq no longer populates the resolver cache with DHCP-derived names
at startup, as the inserted cache entries immediately expire due to
having negative expiration times that cause is_expired() to return true
when called with now==0.
This commit replaces the archaic implementation of dnsmasq_time() with a
call to the POSIX-standardized clock_gettime(CLOCK_MONOTONIC), thereby
eliminating the need to convert manually from ticks to seconds. The new
implementation will yield correct results until the system uptime
exceeds approximately 68 years.
Signed-off-by: Matt Whitlock <dnsmasq@mattwhitlock.name>
Behaviour to stop infinite loops when all servers return REFUSED
was wrongly activated on client retries, resulting in
incorrect REFUSED replies to client retries.
Thanks to Johannes Stezenbach for finding the problem.
