Age | Commit message (Collapse) | Author |
|
search domains and retry.
|
|
Instead of repairing potential garbage ensure that we receive proper C
strings. Inspired by a similar diff by deraadt@ for ldapd.
|
|
The resolver is the actual consumer and shouldn't trust the frontend.
Fold the IPv4/IPv6 specific checks thanks to the previous commit.
Idea from florian
OK florian
|
|
Reduce duplicate code and use getnameinfo(3) for IPv4 as well.
This commit is the equivalent of sbin/resolvd/resolvd.c revision 1.21
"Simplify address family handling, ditch inet_ntop(3)".
OK florian
|
|
RTM_PROPOSAL's list of IP addresses does not contain scope IDs by design.
This is not a problem as the proposal is always bound to an interface,
as long as we use it...
Fill in the scope ID for link-local IPs and replace inet_ntop(3) usage with
getnameinfo(3) in the IPv6 case such that it actually turns up in the string
representation.
This is the unwind specific fix to ensure working IPv6LL; libunbound still
requires another fix.
This commit is the equivalent of sbin/resolvd/resolvd.c revision 1.20
"Install missing scope identifier for IPv6 link-local addresses".
OK florian
|
|
(200ms) to answer before trying the next strategy. However, we need to
skip strategies that are not available. In the default configuration,
without a config file unwind(8) would give DoT 200ms more time, but no
DoT forwarders are known, so this is useless.
OK kn
|
|
Do not abuse "dhcp" to say "DHCP and SLAAC".
unwind.conf(5) does so but unwindctl(8) does not; in fact, the latter
already has `status autoconf' to
Show nameservers learned from dhclient(8), dhcpleased(8) or slaacd(8).
Adjust unwind's config manual and internal code accordingly; still accept
the old keyword but do not document it.
hostname.if(5) already advises for `inet[6] autoconf' instead of `dhcp' and
other related daemons don't abuse the word "dhcp" like unwind does.
Feedback sthen
OK florian
|
|
Found in resolvd(8) which uses the same code.
|
|
authorities when encountering a validation error.
This only helps one particular case of validation errors: When
authorities are out of sync and some carry old zones. In all other
cases this causes a huge amount of work that will just end in a
SERVFAIL because the result will still be bogus.
OK sthen
|
|
switched networks. We validated it, we can't do better than that!
While here reorder the long list of conditions to make it easier to
understand when we doubt a response because we might be behind a
captive portal. First list all conditions when we do not doubt the
response and then the two conditions when we do doubt the response.
OK benno
|
|
the configuration struct. This is also an implicit list of enabled
resolver strategies. We have also stored an explict lookup array of
enabled strategies outside of the configuration to be able to quickly
answer "is this strategy enabled" without traversing the preferences
list.
Move this table into the configuration so that we don't need to
"repair" it on config reload.
This fixes a bug where on startup the preferences list and enabled
lookup table were not in sync. It didn't matter in practice since we
do a config reload and then pass in DNSSEC trustanchors on startup.
Both actions combined repaired things.
OK benno
|
|
fails to report the path that the failure occured on. Suggested by
deraadt@ after some tech discussion.
Work done and verified by Ashton Fagg <ashton@fagg.id.au>
ok deraadt@ semarie@ claudio@
|
|
provided nameservers, i.e. the stub resolver check succeeded.
Previously we would only probe DNS64 on network change but would not
reschedule when it failed. Sometimes (most of the time?) this failes
because our address is still tentative or a default route has
not yet been installed.
OK phessler
|
|
ugly and the underlying problem (dhclient and unwind playing well
together) should be solved differently.
Final straw was jca reporting that it breaks his setup.
|
|
localhost.
|
|
This is a step towards starting unwind earlier, before the network is
up and partitions are mounted.
OK kn
|
|
resolver so we have to schedule a re-check.
OK kn
|
|
old configuration. We will then request another check that runs in
parallel to the old check. If the new check finishes earlier, the
current check result will be overwritten by an outdated check result
which is likely wrong.
While here fix some whitespace.
OK phessler
|
|
to configure libunbound accordingly. This way it no longer tries to
talk to IPv6 nameservers when only IPv4 is available and vice versa.
input deraadt
OK kn
|
|
handle them like UNKNOWN.
Found the hard way by kn.
|
|
useful for us out of it and it can be quite noisy when we are missing
IPv4 or IPv6 addresses.
It is still available when logging to stderr when running with -d.
OK phessler
|
|
When unwind(8) learns new autoconf resolvers (from dhcp or router
advertisements) it checks if a DNS64 is present in this network
location and tries to recover the IPv6 prefix used according to
RFC7050.
The learned autoconf resolvers are then prevented from upgrading to
the validating state since DNS64 breaks DNSSEC.
unwind(8) can now perform its own synthesis. If a query for a AAAA
record results in no answer we re-send the query for A and if that
leads to an answer we synthesize an AAAA answer using the learned
prefixes.
Testing & OK kn
|
|
upcomming DNS64 diff simpler.
|
|
Let's go through the check_resolver() / new_resolver() code path
which will also hook up the resovler to the shared cache.
This means also one less special case for upcomming DNS64 support.
|
|
Follows claudio's lead in ospfd et al.
Problem reported by mortimer.
|
|
Problem reported by mortimer
|
|
Log the query and answer SERVFAIL instead of exiting fataly.
That way we can at least figure out where libunbound goes off the
rail.
OK otto
|
|
OK kn some time ago
|
|
has the downside to always copy the maximum IMSG size (about 16k)
between the resolver and frontend process for DNS answers because
we had to keep it as simple as possible.
We can now rearange things in -current to be less wasteful. This copies
only the usually small DNS answer.
In the unusual case that a DNS answer is larger than the maximum IMSG size
fragment the message and send multiple IMSGs.
|
|
16k) by splitting them up.
Previously unwind would send meta-data about the finished query from
the resolver process to the frontend process and then silently fail to
send the actual answer because it was too big for imsg.
When receiving the meta-data for the next query the frontend process
would then exit via fatal() because it was still expecting an answer.
This likely fixes rare crashes observed by Leo Unglaub.
Note that even with DNSSEC signatures, answers this big are very rare.
OK tb, benno
|
|
resolvers.
OK kn
|
|
memcpy the address into a local var before comparing it with code
that reads ints using int *. at least sparc64 and landisk suffer from this.
with and ok jca@
|
|
in 'resolvers[type]->state = state'.
ok florian@
|
|
resulting in a "fatal in resolver: wrong unified cache set on
resolver".
I believe this happens because we are using an UNKNOWN resolving
strategy to resolve queries.
Disable the upgrade logic for now and always construct a fresh
resolver context and set the unified context on it before any cache
gets allocated. This causes a bit of memory churn on startup and when
changing networks, but better than a crashing unwind.
First observed by deraadt
|
|
OK florian@. reads ok benno@
|
|
The resolving only strategies mess up the negative cache by claiming
DNSSEC related records do not exist which confuses the validating
strategies.
Found the hard way by kn@ and analysed by otto@
OK kn@
|
|
ub_event_pluggable.c instead of ub_event.c.
( https://github.com/NLnetLabs/unbound/issues/99 )
We have been the odd one out, so switch to ub_event_pluggable, too.
|
|
https://github.com/NLnetLabs/unbound/issues/99
ub_ctx_delete would free the passed in event_base leading to
use-after-free since libunbound never allocated the memory and
unwind expects to continue using the event_base.
|
|
testing by otto & pamela as part of a larger diff
|
|
testing by otto & pamela as part of a larger diff
|
|
|
|
recursor. Also change strategy to not fetch addresses of nameservers
pro-actively, it does not help a lot in typical unwind setups and
consumes resources we would like to spend on actual resolving user
queries. ok florian@
|
|
|
|
- check if this is an answer to a still running query up front,
if not there is nothing more to do
- get rid of the retry case, we can now just inline it
- reduce indent by always calculating elapsed time for DOUBT_NXDOMAIN_SEC
Triggered by, input and OK otto
|
|
|
|
|
|
|
|
Also add some consistentcy checking to detect logic errors. ok @florian
|
|
Unfortunately this required a fair amount of deck chair shuffling.
Input & OK otto
|
|
|