Re: Some sites not resolving (DNSSEC?)

2018-05-23 Thread Havard Eidnes via Unbound-users
> This generally seems to work except for several hosts from which I try to > fetch podcasts. One of these is coder.show. Just a note, http://dnsviz.net/d/coder.show/dnssec/ shows several warnings related to coder.show -- apparently the auth name servers reply with CNAME *and* other data for

Re: Negative cache being ignored.

2017-10-17 Thread Havard Eidnes via Unbound-users
> In this example, trying to lookup a CAA record for a domain: > ... > # time host -t CAA jhmnet.net 192.168.136.181 ... > real    0m3.876s > > Run this again, immediately after: .. > real    0m0.016s > > Implying the cache is working as expected. (cache-max-negative-ttl: 120) > > However,

Re: TCP fallback on timeout

2017-04-27 Thread Havard Eidnes via Unbound-users
> Unfortunately, DNS servers aren't required to support TCP. IMHO, that is an all too commonly held misconception. Publishing name servers need to support TCP as well. I'm pretty sure section 4.2 of RFC 1035 mandates it. It doesn't use the formal requirements keywords because it predates the

Re: Unbound exiting on stats write failure?,Re: Unbound exiting on stats write failure?

2016-10-03 Thread Havard Eidnes via Unbound-users
>> one of our unbound hosts recently exited, and before it did, it >> logged this: >> >> Sep 19 14:25:56 xxx unbound: [96:4] error: tube msg write failed: >> Resource temporarily unavailable >> Sep 19 14:25:56 xxx unbound: [96:4] fatal error: could not write stat >> values over cmd

Re: Unbound exiting on stats write failure?,Re: Unbound exiting on stats write failure?

2016-09-20 Thread Havard Eidnes via Unbound-users
> The error is on a pipe between unbound processes (threads). It should > not be out of resources (it might block of course, waiting for them, and > blocking pipes are not a problem for unbound, but this error is like a > pipe randomly breaks up). Hm. > Are you on OpenBSD? Perhaps upgrade the

Unbound exiting on stats write failure?

2016-09-20 Thread Havard Eidnes via Unbound-users
Hi, one of our unbound hosts recently exited, and before it did, it logged this: Sep 19 14:25:56 xxx unbound: [96:4] error: tube msg write failed: Resource temporarily unavailable Sep 19 14:25:56 xxx unbound: [96:4] fatal error: could not write stat values over cmd channel Now,

Re: message is bogus, non secure rrset with Unbound as local caching resolver

2016-03-19 Thread Havard Eidnes via Unbound-users
> But unbound is trying to set the AD flag in its reply. And thus it > needs all the RRsets to be secure. Thus, the reply from the forwarder > with CD flag becomes bogus. Yes, I know unbound is trying to validate the answer. However, insisting that a recursor return all pertinent data required

Re: message is bogus, non secure rrset with Unbound as local caching resolver

2016-03-04 Thread Havard Eidnes via Unbound-users
>> Following the "not a bug" response from the BIND maintainers >> yesterday evening, can you please point to chapter and verse >> mandating this behaviour for non-authoritative recursive >> resolvers? > > RFC4035 3.2.3 for validators, all RRsets in answer and authority > sections should be

Re: message is bogus, non secure rrset with Unbound as local caching resolver

2016-03-03 Thread Havard Eidnes via Unbound-users
>> info: validate(cname): sec_status_secure >> info: validate(positive): sec_status_secure >> info: message is bogus, non secure rrset uninett.no. NS IN >> >> As far as I can tell, the problem here is caused by extra NS-records in >> the authority-section that do not include the RRSIG

Re: message is bogus, non secure rrset with Unbound as local caching resolver

2016-03-02 Thread Havard Eidnes via Unbound-users
>> The "right" thing is to have RRSIGs for all elements of the >> answer and authority sections. This is mandated by >> RFC4034,4035. All the RRsets in the answer and authority >> section MUST validate to mark the response as valid. > > FYI, I've submitted a tentative bug report to the BIND

Re: message is bogus, non secure rrset with Unbound as local caching resolver

2016-03-02 Thread Havard Eidnes via Unbound-users
> The "right" thing is to have RRSIGs for all elements of the > answer and authority sections. This is mandated by > RFC4034,4035. All the RRsets in the answer and authority > section MUST validate to mark the response as valid. FYI, I've submitted a tentative bug report to the BIND maintainers

Re: message is bogus, non secure rrset with Unbound as local caching resolver

2016-03-02 Thread Havard Eidnes via Unbound-users
>> Unfortunately, the BIND server only tends to return responses where >> the authority-section has NS-records but no RRSIG-record >> during the night. I suspect it has something to do with >> traffic levels and what other systems are accessing it. It >> makes it all a bit hard to troubleshoot.

Query forwarding

2016-01-18 Thread Havard Eidnes via Unbound-users
Hi, I'm trying to figure out how unbound can be configured to behave with respect to query forwarding. In unbound.conf(5) I find this particular gem: forward-first: If enabled, a query is attempted without the forward clause if it fails. The data could not be

unbound-control dump_cache / load_cache

2015-12-29 Thread Havard Eidnes via Unbound-users
Hi, a while back I needed/wanted to reconfigure my unbound recursor to have more memory available for the "rrset cache", in what seems to be a futile attempt at increasing the cache hit rate. This would cause unbound to discard its cache in its entirety. I thought that in order to soften the

Re: Multi-threaded operation?

2015-10-05 Thread Havard Eidnes via Unbound-users
Hi, it looks like I'll have to answer my own question, which is a little disappointing: > I'm running unbound 1.5.4 on NetBSD/amd64 7.0, and I notice that > despite me having configured > > server: > num-threads: 12 > so-reuseport: yes > > only one of the threads is handling all the queries,