> 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
> 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,
> 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
>> 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
> 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
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,
> 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
>> 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
>> 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
>> 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
> 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
>> 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.
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
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
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,
15 matches
Mail list logo