Re: Multiple unbound instances

[Miguel Miranda via Unbound-users]

OK thanks. I have read the performance doc,  So I have two servers that are
serving 250k customers,  it is recommended that I configure 10g for cache
in one instance?  I have 16 cores (with hyper threading) in each one.
Should I configure 8 or 16 threads?
El mar. 4, 2016 10:19 AM, "Andi via Unbound-users" <
unbound-users@unbound.net> escribió:

> Zitat von Miguel Miranda via Unbound-users :
>
> Hello to all, im installing a load balancer and i want to run multiple
>> unbound instances, im doing this because my it experts says  it is not
>> recommended to have a huge cache (i have 32GB available) it is better to
>> have 2 or 3 GB cache in multiple unbound instances, this is good for high
>> availability too, so if a instances dies the balancer notices it and the
>>  other instances take the load,  what do you think about it ? if this a is
>> a good idea, how to run multiple unbound instances, i am running unbound
>> 1.5.1 Centos 6.7.
>> regards.
>>
>
> I would not suspect that the cache size would be a limiting factor for
> Unbound. It *can* be problematic if you need a lot of CPU power and
> therefore have a lot (>> 8) of threads using the same cache because of lock
> contention.
> For details have a look here :
> http://www.unbound.net/documentation/howto_optimise.html
> If you need high availability multiple instances will not help that much
> if they use the same kernel and/or the same hardware, so you have to split
> the multiple instances on multiple machines and maybe even different OS.
>
> Regards
>
> Andreas
>
>
>
>

Re: Multiple unbound instances

[Andi via Unbound-users]

Zitat von Miguel Miranda via Unbound-users :


Hello to all, im installing a load balancer and i want to run multiple
unbound instances, im doing this because my it experts says  it is not
recommended to have a huge cache (i have 32GB available) it is better to
have 2 or 3 GB cache in multiple unbound instances, this is good for high
availability too, so if a instances dies the balancer notices it and the
 other instances take the load,  what do you think about it ? if this a is
a good idea, how to run multiple unbound instances, i am running unbound
1.5.1 Centos 6.7.
regards.


I would not suspect that the cache size would be a limiting factor for  
Unbound. It *can* be problematic if you need a lot of CPU power and  
therefore have a lot (>> 8) of threads using the same cache because of  
lock contention.
For details have a look here :  
http://www.unbound.net/documentation/howto_optimise.html
If you need high availability multiple instances will not help that  
much if they use the same kernel and/or the same hardware, so you have  
to split the multiple instances on multiple machines and maybe even  
different OS.


Regards

Andreas

Re: Multiple unbound instances

[A. Schulze via Unbound-users]

Miguel Miranda via Unbound-users:


Hello to all, im installing a load balancer and i want to run multiple
unbound instances, im doing this because my it experts says  it is not
recommended to have a huge cache (i have 32GB available) it is better to
have 2 or 3 GB cache in multiple unbound instances, this is good for high
availability too, so if a instances dies the balancer notices it and the
 other instances take the load,  what do you think about it ? if this a is
a good idea, how to run multiple unbound instances, i am running unbound
1.5.1 Centos 6.7.
regards.


running multiple instances is possible - I do so.
But because of different configurations.

could your "it experts" prove the statement
 "it is not recommended to have a huge cache"
somehow?

Andreas

Multiple unbound instances

[Miguel Miranda via Unbound-users]

Hello to all, im installing a load balancer and i want to run multiple
unbound instances, im doing this because my it experts says  it is not
recommended to have a huge cache (i have 32GB available) it is better to
have 2 or 3 GB cache in multiple unbound instances, this is good for high
availability too, so if a instances dies the balancer notices it and the
 other instances take the load,  what do you think about it ? if this a is
a good idea, how to run multiple unbound instances, i am running unbound
1.5.1 Centos 6.7.
regards.

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

[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 authentic ...

That's an incomplete quote.  A more complete quote would be:

3.2.3.  The AD Bit

   The name server side of a security-aware recursive name server MUST
   NOT set the AD bit in a response unless the name server considers all
   RRsets in the Answer and Authority sections of the response to be
   authentic.  The name server side SHOULD set the AD bit if and only if
   the resolver side considers all RRsets in the Answer section and any
   relevant negative response RRs in the Authority section to be
   authentic. [...]

However, since the CD ("Checking Disabled") bit is set in the query
Unbound sends to its forwarder, the AD ("Authentic Data") bit is of
course not set in its response, so this whole section doesn't really
apply.

Please also note that this section only talks about setting the AD
bit, not about whether it's mandatory to include "all required DNSSEC
records that the querier is missing and which are required to validate
the included information".

If such or a similar mandate exists on a recursive resolver, it must
come from elsewhere.

Therefore my suggestion: "If the validator needs more information to
complete validation, it had better ask for it explicitly."

As has been pointed to elsewhere in this thread there's a question of
whether setting the CD bit in queries sent to a forwarder is
appropriate, but RFC 6840 (Clarifications and Implementation notes for
DNS security) seems to recommend the practice, ref. section 5.9, but
also lists a number of different ways this can be done, ref. appendix
B, which also mentions the possibility of there being more than one
validator on the path, as can be the case when using a forwarder.

Regards,

- Håvard