Re: [Unbound-users] stub-zone reverse problem

2010-01-26 Thread Alexander Clouter
john  wrote:
>
> stub-zone:
>   name: "10.10.10.in-addr.arpa." <-
>   stub-addr: a.b.c.d
> 
> [snipped]
>
> ;; AUTHORITY SECTION:
> 10.in-addr.arpa. <-
> 
> 
When you put 'stuff' into the 10.x.y.z range you are amending the zone 
10.in-addr.arpa. and not something more specific.

Same applies for 168.192.in-addr.arpa. (but obviously not 
16->31.172.in-addr.arpa.

Cheers

-- 
Alexander Clouter
.sigmonster says: Truth is hard to find and harder to obscure.

___
Unbound-users mailing list
Unbound-users@unbound.net
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users


Re: [Unbound-users] 1.4.1 crashing

2010-01-26 Thread Artis Caune
2010/1/26 Attila Nagy :
> Hello,
>
> It still crashes for us. :(
> I thought about saving the traffic and trying to replay that to another
> (idle) server, but couldn't yet find the time to do that...

same here.



-- 
Artis Caune

Everything should be made as simple as possible, but not simpler.
___
Unbound-users mailing list
Unbound-users@unbound.net
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users


Re: [Unbound-users] 1.4.1 crashing

2010-01-26 Thread Attila Nagy

Hello,

It still crashes for us. :(
I thought about saving the traffic and trying to replay that to another 
(idle) server, but couldn't yet find the time to do that...


W.C.A. Wijngaards wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi, I committed r1959.  This has a different structure alignment, which
had changed in svn trunk (but is not in 1.4.0 or in the patch itself).
This could help out with bus-errors, perhaps with alignment problems for
malloc itself, especially on 64bit.   I am not sure but it certainly
changed and I think could create this sort of result.  Could you try that?

Perhaps the misaligned read only causes trouble on a page boundary or
something like that and this is what trips it up only occasionally?

Best regards,
   Wouter

On 01/15/2010 08:46 PM, Artis Caune wrote:
  

2010/1/15 W.C.A. Wijngaards :


Artis noted that it seems to be running fine with "validator iterator"
module-config statement (not without the validator).  Could this be the
same for you?
  

unfortunately one instance just crashed, it was running 10+ hours.
Looks like with validator it just takes longer.







-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAktUVrcACgkQkDLqNwOhpPg+dACeN9C2f/bg4Pha9zewOMY9RAue
PXcAnj5Qs/me/4c4zIsUfMyQjuJskSZf
=Gj8j
-END PGP SIGNATURE-
___
Unbound-users mailing list
Unbound-users@unbound.net
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
  


___
Unbound-users mailing list
Unbound-users@unbound.net
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users

[Unbound-users] stub-zone reverse problem

2010-01-26 Thread john

Hi,
I run unbound as a resolver and I've configured it with a stub zone for 
reverse DNS on a local subnet we use internally, however it doesn't seem 
to send the requests for the zone to the IP specified in the sub-zone 
config. I looked in the archives and found someone else with a similar 
problem:


 http://www.unbound.net/pipermail/unbound-users/2009-May/000583.html

The solution there also works for me. Before this, I had configured 
unbound with:


stub-zone:
  name: "10.10.10.in-addr.arpa."
  stub-addr: a.b.c.d

and with that config I get an answer like this from unbound:



; <<>> DiG 9.5.1-P3 <<>> -t ns 10.10.10.in-addr.arpa. @x.x.x.x
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16381
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;10.10.10.in-addr.arpa. IN  NS

;; AUTHORITY SECTION:
10.in-addr.arpa.10800   IN  SOA localhost. nobody.invalid. 1 
3600 1200 604800 10800


If I then apply the 'fix' from the post above:

"local-zone: "10.in-addr.arpa." nodefault"

It answers correctly with the details from the server specified in the 
stub address.


I am not serving any zones from unbound- it is acting purely as a resolver 
so this seems like unbound is serving the 10.in-addr.arpa. authority bit 
when it hasn't been configured to do so. Any ideas why it's doing this?


I'm using the Debian Lenny package (1.0.2-1+lenny1) on this box, but it 
seems to do the same with 1.4.1 built from source.


john
___
Unbound-users mailing list
Unbound-users@unbound.net
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users


Re: [Unbound-users] Unbound issues

2010-01-26 Thread Rod Taylor
> Another disconcerting fact is that the cache hit rate is 54% when its
> still OK but drops to 26% when you get trouble.  Take a look at that
> dump-requestlist, and also perform a unbound-control stats_noreset >
> snapshot and look at it: the number of unwanted replies in particular.
> Certain forms of Kaminsky-eeks! would tend to blast lots of different
> queries to a resolver...

We are attempting to use Unbound as a DNS resolver/cache for a spider.
In a typical hour we are looking up several million domains but
typically only need to resolve it a handful of times per day.


We boosted outgoing-range to 8192, reduced jostle-timeout to 200, and
eliminated the min-ttl.

We also tried boosting the slabs counters to various values between 4 and 512.

None of these made any noticeable difference.


CPU usage becomes very low when exceeded begins to climb. Does unbound
sleep or spin while waiting for a lock?

Additional thoughts? We are going to attempt using much much smaller
cache values. I tend to believe it is the cache management from
dealing with several million different domains, but of course I have
no proof of that.


>>   verbosity: 1
>>   statistics-interval: 300
>>   statistics-cumulative: yes
>>   extended-statistics: no
>>   num-threads: 4
>>   outgoing-range: 2048
>>   msg-cache-size: 3G
>>   msg-cache-slabs: 8
>>   num-queries-per-thread: 2048
>>   jostle-timeout: 1000
>>   so-rcvbuf: 8M
>>   rrset-cache-size: 6G
>>   rrset-cache-slabs: 8
>>   cache-min-ttl: 7776000
>>   harden-glue: yes
>>   harden-dnssec-stripped: yes
>>   harden-referral-path: yes
>>   use-caps-for-id: yes
>>   unwanted-reply-threshold: 1000
>>   val-clean-additional: yes
>>   val-permissive-mode: no
>>   key-cache-slabs: 8
>>   neg-cache-size: 1g


> On 01/19/2010 11:15 PM, Rod Taylor wrote:
>> We are trying unbound out. Machine is quad CPU with 16GB ram. I'm
>> picking on thread 2 because it shows the issue best as it seems to
>> receive up to 6 times as many queries as the other 3 threads. As you
>> can see, the time to execute climbs gradually through the period and
>> starts to "exceed" allowed limits about mid-way down the stats results
>> shown here.
>>
>> Config bits.
>> server:
>>       verbosity: 1
>>       statistics-interval: 300
>>       statistics-cumulative: yes
>>       extended-statistics: no
>>       num-threads: 4
>>       outgoing-range: 2048
>>       msg-cache-size: 3G
>>       msg-cache-slabs: 8
>>       num-queries-per-thread: 2048
>>       jostle-timeout: 1000
>>       so-rcvbuf: 8M
>>       rrset-cache-size: 6G
>>       rrset-cache-slabs: 8
>>       cache-min-ttl: 7776000
>>       harden-glue: yes
>>       harden-dnssec-stripped: yes
>>       harden-referral-path: yes
>>       use-caps-for-id: yes
>>       unwanted-reply-threshold: 1000
>>       val-clean-additional: yes
>>       val-permissive-mode: no
>>       key-cache-slabs: 8
>>       neg-cache-size: 1g
>>
>>
>> Below are snippets from the statistics taken roughly every 5 minutes
>> from startup over a period of 7 hours.
>>
>> server stats for thread 2: 420 queries, 284 answers from cache, 136 
>> recursions
>> server stats for thread 2: requestlist max 21 avg 16.2647 exceeded 0
>> server stats for thread 2: 3189 queries, 3053 answers from cache, 136 
>> recursions
>> server stats for thread 2: requestlist max 21 avg 16.2647 exceeded 0
>> server stats for thread 2: 3375 queries, 3239 answers from cache, 136 
>> recursions
>> server stats for thread 2: requestlist max 21 avg 16.2647 exceeded 0
>> server stats for thread 2: 4560 queries, 4424 answers from cache, 136 
>> recursions
>> server stats for thread 2: requestlist max 21 avg 16.2647 exceeded 0
>> server stats for thread 2: 32129 queries, 13211 answers from cache,
>> 18918 recursions
>> server stats for thread 2: requestlist max 1196 avg 620.017 exceeded 0
>> server stats for thread 2: 227635 queries, 63600 answers from cache,
>> 164035 recursions
>> server stats for thread 2: requestlist max 1196 avg 605.375 exceeded 0
>> server stats for thread 2: 412374 queries, 113701 answers from cache,
>> 298673 recursions
>> server stats for thread 2: requestlist max 1196 avg 649.591 exceeded 0
>> server stats for thread 2: 591627 queries, 164560 answers from cache,
>> 427067 recursions
>> server stats for thread 2: requestlist max 1196 avg 685.99 exceeded 0
>> server stats for thread 2: 762418 queries, 214876 answers from cache,
>> 547542 recursions
>> server stats for thread 2: requestlist max 1196 avg 725.279 exceeded 0
>> server stats for thread 2: 925072 queries, 265281 answers from cache,
>> 659791 recursions
>> server stats for thread 2: requestlist max 1196 avg 766.182 exceeded 0
>> server stats for thread 2: 1082217 queries, 315509 answers from cache,
>> 766708 recursions
>> server stats for thread 2: requestlist max 1213 avg 803.033 exceeded 0
>> server stats for thread 2: 1240514 queries,