Hi Matt,
the SERVFAIL is probably not caused by DNSSEC because the zone is not
signed. The problem is that the zone is broken. There is a CNAME
record in the zone apex, which is a violation of the DNS specification
(https://tools.ietf.org/html/rfc2181#section-10.1).
Random resolution failures are
On 06/30/2015 07:01 PM, Paul Wouters wrote:
> With that many CNAMEs requiring validation and intermittent failure, my guess
> is your wifi is dropping a significant amount of queries.
It could also be NAT state table overflow.
> This is a case where shorter negative cache lifetimes should help a
On Tue, Jun 30, 2015 at 02:01:19PM -0300, Paul Wouters wrote:
> With that many CNAMEs requiring validation and intermittent failure,
> my guess is your wifi is dropping a significant amount of queries.
> This is a case where shorter negative cache lifetimes should help a
> lot. This should come int
With that many CNAMEs requiring validation and intermittent failure, my guess
is your wifi is dropping a significant amount of queries.
This is a case where shorter negative cache lifetimes should help a lot. This
should come into dnssec-trigger very soon.
What will also help is once edns-query
On Tue, Jun 30, 2015 at 06:44:41PM +0200, Tomas Hozza wrote:
> Please file a bug against dnssec-trigger. It will be better for
> getting additional information. Also please see the reply by Paul
> Wouters to your previous email.
Oh hey. I forgot that I posted this already, and didn't see the reply
On 30.06.2015 17:07, Matthew Miller wrote:
> With the DNSSEC feature enabled as per the testing instructions, I'm
> sometimes (but not always) getting failures for popular geek blog Boing
> Boing, when public DNS still works:
>
> $ host boingboing.net
> Host boingboing.net not found: 2(SERVFAIL
