On 11/07/2017 04:29 AM, Ralph Dolmans wrote:
> You mentioned that you are able to reproduce the issue. Can you maybe
> share a log where the looping happens, while using a verbosity of 4?
> Maybe that will give more insight.
I tried doing this previously, but found that verbosity of 4 slowed down
U
Any further thoughts on what could be behind this issue?
Thanks,
Jacob
On 10/06/2017 03:15 PM, Jacob Hoffman-Andrews via Unbound-users wrote:
> I also got a number of these errors on an upgrade to Unbound 1.6.6, on a
> server doing about 100-300 qps. Similar config: use-caps-for-id
reproduce
> this
> issue on my system - unbound 1.6.5-1, Debian, use-caps-for-id, validator
> enabled. Though I have some occurrences of looping module stopped error too,
> none of the domains caused this error.
>
> Ales
>
> On sobota 14. října 2017 12:51:15 CEST Jacob Hof
I tested without use-caps-for-id, and did not get the "looping module
stopped" error.
I also upgraded to 1.6.7 and applied your patch. Here is a sample of
some of the queries and log messages I got. I was loading Unbound with a
mixture of A and CAA queries pulled from the logs of all names in
cert
I also got a number of these errors on an upgrade to Unbound 1.6.6, on a
server doing about 100-300 qps. Similar config: use-caps-for-id, IPv6,
DNSSEC. No non-default modules enabled. I also have a test harness where
I can reproduce these. What additional information would be useful?
On 09/20/2017
On 07/27/2017 01:28 PM, Robert Edmonds wrote:
> Jacob Hoffman-Andrews via Unbound-users wrote:
>> I'm trying to write some documentation for users of Let's Encrypt about
>> CAA. I believe it's the case that standards-conformant authoritative
>> resolvers should
Hi all,
I'm trying to write some documentation for users of Let's Encrypt about
CAA. I believe it's the case that standards-conformant authoritative
resolvers should return NOERROR for qtypes they don't recognize, rather
than NOTIMP. Is this correct? If so, what is the relevant standard? I
haven't
On 07/21/2017 09:43 AM, Markus Gutschke wrote:
> The first step would be to file a useful bug report for the PowerDNS
> package in Ubuntu. If it needs somebody to monitor this process, I can
> volunteer, but I am not sure I'd be the best person to do this as I
> still don't fully understand the iss
(Renaming this branch of the thread to reflect the topic)
On 07/21/2017 09:12 AM, Markus Gutschke wrote:
> It's great to hear that PowerDNS found and fixed the bug.
> By default, [Xenial] ships with a version of PowerDNS that lags behind
> the official 4.0.x
> branch: https://packages.ubuntu.com/x
Thanks to W.C.A Wijngaards for the very helpful reply on my last
question, about DNSSEC, empty responses, and use-caps-for-id. We
discovered a bug in PowerDNS
(https://community.letsencrypt.org/t/caa-servfail-changes/38298/2),
which happily was fixed in the 4.0.4 release in June.
I have another qu
At Let's Encrypt, we recently started refusing to issue if there is a
failure during CAA lookup, in particular a SERVFAIL. We've received a
handful of reports from users who are hitting these SERVFAILs. The
authoritative resolver software and the root causes seem to be somewhat
different (PowerDNS
On 04/27/2017 07:27 AM, Viktor Dukhovni via Unbound-users wrote:
> On Wed, Apr 26, 2017 at 08:14:09PM -0700, Jacob Hoffman-Andrews wrote:
>
>> I'm trying to understand Unbound's TCP fallback better. Is it expected
>> that Unbound will fall back to TCP when UDP queries timeout, or only if
>> it rece
I'm trying to understand Unbound's TCP fallback better. Is it expected
that Unbound will fall back to TCP when UDP queries timeout, or only if
it receives a truncated ANSWER?
Specifically, I'm trying to make CAA queries, and finding that, when
querying a certain DNS provider (NetRegistry), UDP que
13 matches
Mail list logo
