-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Alexander, Alexander Gall wrote: | Wouter, | | Here's an update on my testing of 0.7.2 (I had the flu last week, back | to work now :-) Thank you very much for the test. I'll examine your logs below. | Total run time so far is about 62 hours with a bit over 10 million | answered queries. I was confident enough to let unbound run for | almost two days just now, which should have been enough to test most | of the TTL and DNSSEC validation expiration logic I guess. Good to know that validation was tested too; and works :-) | Everything else is left at the default values. Please let me know if | you want me to test anything non-default in particular. | I did not notice any problems at all and didn't get any reports from | our users neitherl. I count this as a success :-) Great! 10 million real user queries is not something that I can try myself. | unbound also correctly dealt with the situation that it had a trust | anchor defined for example.net (from the set of trust anchors | distributed by RIPE NCC | <https://www.ripe.net/projects/disi/keys/ripe-ncc-dnssec-keys-new.txt>), | but the corresponding DNSKEY is missing from the zone: | | [1201660228] unbound[16620:0] info: failed to prime trust anchor -- could not fetch DNSKEY rrset <example.net. DNSKEY IN> Ah, yes, in such a situation you can wait for example.net to fix their zone and after 900 (default bogus ttl) unbound will pick that up, or instead change your config and kill -HUP unbound (this also clears the cache). | Operational experience: I was able to integrate unbound into our | anycast caching system without problems. This allows me to run BIND | and unbound in parallel on different anycast instances just as I had | planned to do. All of this is looking very good. | Oh this is really nice. Would be interesting to know of any noticable differences between bind and unbound. Apart from version.bind CH TXT, of course. Your log file. Thank you for sharing the statistics. * There are many TCP connect errors. I assume now, that someone configured a zone as example.com NS 10.0.0.100, with a nameserver on their local subnet. Unbound cannot contact that nameserver, and tries (finally) to use TCP on it; which gives this error. I think the log file should not be cluttered with zone administration mistakes by others. I can demote this particular error to a higher verbosity level (2), or I can print the address that failed and then you (the operator) or a script can pickup those and block them (do-not-query-address: 10.0.0.0/8 in the config file). I think I'll demote the error message, as it does not bother the resolver operator. What do you think? Would you like to have the addresses printed to the log anyway? * You have 93% cache hits. With the default 4+4 Mb cache (4 mb for rrset data, 4 mb for message data), so unbound caps memory usage at about 20-30 Mb total for the process. For 10 million queries. This is impressive. You could try to increase cache size to improve cache hits; but it doesn't seem worth the effort. * The requestlist (this is the to-do list of pending recursive queries) stays nice and small as well. If the computer were unable to bear the load, this number would shoot up as requests come in faster than they could be handled. * For the histogram, onlookers please note the average reply time printed a) does not include the cache responses (which are better measured in qps then seconds per query) b) is skewed because of really large upper numbers caused by unbound retrying very hard for a couple of records (remote server down). In a newer unbound the median is printed as well, a nicer way to average recursion speed. * There is a significant bump on the lower end of your histogram, at 32 microsec. I assume this is because a lot of recursion requests are due to a CNAME. Like where a CNAME is used to load-balance with DNS. Consequently, I need to pay attention to CNAME-processing when I do optimization, good to know. Thank you, Best regards, ~ Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHoFXzkDLqNwOhpPgRAk4yAKCHYLcZJSNiZcvGutrnArjjEhrbKACdEysj rnLAr+n8gWm/A1j0TnwocO4= =kCYw -----END PGP SIGNATURE-----