Re: Trouble building bind with Openssl support
Mark Andrews wrote: > > If you really want to go down this path then you need to copy over > the shared library which is dynamically loaded into named at runtime specifically lib/engines/libgost.so > or rebuild openssl to include the gost code in libcrypto. How do you do that? The documentation doesn't say. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: changing NSEC3 salt
On Feb 11 2014, David Newman wrote: [...] That's interesting. It seems to contradict Lucas' advice to "always use '1 0 10' for these [NSEC3] flags, as fewer aren't secure enough and more aren't any more secure." It's difficult to see how that can make sense. Increasing the number of iterations simply gives a linear increase in the computational cost of testing names against NSEC3s (and the same factor in the overheads in authoritative and validating nameservers, of course). Moore's law wipes out a factor of 10 before very long ... It's not often mentioned, incidentally, that using more iterations increases the probability of a collision. Of course, it's pretty damn small to begin with, so that doesn't really matter. But the algorithm, described in RFC 5155 section 5, could have been better designed from that point of view. -- Chris Thompson Email: c...@cam.ac.uk ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
bind-9.9.5 regression test error
I've been trying to run the regression tests for bind-9.9.5 and keep
getting lots of timeouts and errors in the system/inline test.
The procedure I'm using to build and run the tests is at
http://www.linuxfromscratch.org/blfs/view/svn/server/bind.html
For bind-9.9.4-P2, all the tests pass, but using the same procedure for
bind-9.9.5 the system/inline test fails. I dug into the tests and find
that the inline/ns3 server is causing me a problem.
What I found is that I can go to the bin/tests/sys directory and run:
$ sh run.sh inline
for just the problem test. There I find is that the start.pl program is
running the following in each of the ns{1,2,3,4,5,6} subdirectories:
/tmp/bind/bind-9.9.5/bin/named/named -m record,size,mctx -T clienttest
-c named.conf -d 99 -g -U 4 >named.run 2>&1 &echo $!
At the end of the tests, the stop.pl program sends a TERM signal to
these processes, but the ns3 process doesn't shut down. I instrumented
the scripts and got:
stopping servers with TERM: ns1
stopping servers with TERM: ns2
stopping servers with TERM: ns3
stopping servers with TERM: ns4
stopping servers with TERM: ns5
stopping servers with TERM: ns6
wait 60
stopping servers with ABRT: ns1
stopping servers with ABRT: ns2
stopping servers with ABRT: ns3
I:ns3 didn't die when sent a SIGTERM
stopping servers with ABRT: ns4
stopping servers with ABRT: ns5
stopping servers with ABRT: ns6
R:FAIL
The named.run log in ns3 is somewhat confusing, but it does not give any
indication that the TERM signal was received. (I can send it if that is
needed.) I did the above without actually running the inline/test.sh
script but that script also has a lot of timeouts and produces errors
independent of the termination problem above.
I'm hesitant to deploy 9.9.5 with this error, but don't know if it's a
problem with our build process, a bug in the test procedure, or a bug in
named itself.
Can anyone shed light on this issue?
Thanks.
-- Bruce Dubbs
linuxfromscratch.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: bind-9.9.5 regression test error
## Bruce Dubbs (bruce.du...@gmail.com): > I've been trying to run the regression tests for bind-9.9.5 and keep > getting lots of timeouts and errors in the system/inline test. I saw the same symptoms when packaging/testing bind-9.9.5. I traced the issue to processes blocking in read() from /dev/random - so adding --with-randomdev=/dev/urandom to configure's arguments made all tests pass. Regards, Christoph -- Spare Space ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind-9.9.5 regression test error
Christoph Moench-Tegeder wrote: ## Bruce Dubbs (bruce.du...@gmail.com): I've been trying to run the regression tests for bind-9.9.5 and keep getting lots of timeouts and errors in the system/inline test. I saw the same symptoms when packaging/testing bind-9.9.5. I traced the issue to processes blocking in read() from /dev/random - so adding --with-randomdev=/dev/urandom to configure's arguments made all tests pass. Thank you. Works great! Solved my problem. -- Bruce ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind-9.9.5 regression test error
In message <52fbd79b.4070...@gmail.com>, Bruce Dubbs writes: > Christoph Moench-Tegeder wrote: > > ## Bruce Dubbs (bruce.du...@gmail.com): > > > >> I've been trying to run the regression tests for bind-9.9.5 and keep > >> getting lots of timeouts and errors in the system/inline test. > > > > I saw the same symptoms when packaging/testing bind-9.9.5. I traced > > the issue to processes blocking in read() from /dev/random - so > > adding --with-randomdev=/dev/urandom to configure's arguments made > > all tests pass. > > Thank you. Works great! Solved my problem. The inline system test uses DSA and ECDSAP256SHA256 keys both of which require random numbers to sign. If we know that there isn't a random device these algorithms are skipped. Different OS's have differing behaviours for /dev/random as well the sources of randomness differ so it is difficult to know apriori if the test will work or not. The random device can also be changed through named.conf. It is nice to see "make test" being run by someone other than us. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind-9.9.5 regression test error
On 02/12/2014 11:16 AM, Christoph Moench-Tegeder wrote: ## Bruce Dubbs (bruce.du...@gmail.com): I've been trying to run the regression tests for bind-9.9.5 and keep getting lots of timeouts and errors in the system/inline test. I saw the same symptoms when packaging/testing bind-9.9.5. I traced the issue to processes blocking in read() from /dev/random - so adding --with-randomdev=/dev/urandom to configure's arguments made all tests pass. If you don't have enough random bits on your system to run these simple tests, your /dev/random is seriously underpopulated, and likely a security risk. You should definitely not put BIND in production compiled with the option you mention above. For Linux systems haveged is a fairly painless way to populate your entropy pool, which should be fine for BIND. There are of course other more complicated methods as well for higher-security requirements. Doug PS for Mark, When I was maintaining BIND for FreeBSD I always ran the unit tests before I put a new version live. :) ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: changing NSEC3 salt
On 02/12/2014 05:17 AM, Chris Thompson wrote: On Feb 11 2014, David Newman wrote: [...] That's interesting. It seems to contradict Lucas' advice to "always use '1 0 10' for these [NSEC3] flags, as fewer aren't secure enough and more aren't any more secure." It's difficult to see how that can make sense. Increasing the number of iterations simply gives a linear increase in the computational cost of testing names against NSEC3s (and the same factor in the overheads in authoritative and validating nameservers, of course). I can't speak directly for Michael, but I was the "lead technical reviewer" for "DNSSEC Mastery," so I can tell you from my perspective that the intent was not to provide a thorough treatise on all of the possible ramifications of every possible combination of flags. The intent was to help people get up and running with DNSSEC; with reasonable defaults, and a minimum of fuss. Personally, I am hard pressed to justify setting iterations at a value higher than 10. As many others have pointed out, some quite recently, NSEC3 is not going to save you from zone walking by a determined "attacker." Changing the salt often'ish will help, as will doing more than 1 or 2 iterations. But at the end of the day someone who really wants to calculate a rainbow table on your zone can and will do so. Moore's law wipes out a factor of 10 before very long ... Exactly which is IMO another reason that values higher than 10 are not likely to do anything other than increase the costs on validators, and for no good reason. It's not often mentioned, incidentally, that using more iterations increases the probability of a collision. Of course, it's pretty damn small to begin with, so that doesn't really matter. But the algorithm, described in RFC 5155 section 5, could have been better designed from that point of view. Honestly that wasn't a factor in my thinking, but it's interesting info to store away for future use, thanks. :) Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
New BIND versions are available (-W1 versions)
Recent maintenance releases of BIND (BIND 9.9.5, 9.8.7, and 9.6-ESV-R11) were found to contain a defect preventing the included dig, nslookup, and host utilities from exiting properly when run on Microsoft Windows systems. Only Windows systems were affected. To address this regression, which was caused by a fix for another issue which exposed a previously harmless bug in BIND's Windows network code, ISC is issuing replacement versions of the maintenance releases for Windows users. BIND 9.9.5-W1 replaces BIND 9.9.5 BIND 9.8.7-W1 replaces BIND 9.8.7 and even though we publicly stated that there would be no further fixes to BIND 9.6-ESV.. BIND 9.6-ESV-R11-W1 replaces BIND 9.6-ESV-R11. (..but this time we mean it about 9.6-ESV being EOL. Seriously. Upgrade.) All three versions are available from: http://www.isc.org/downloads Our apologies to the Windows users that this regression affected. Unix users do not need to upgrade to the new versions. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind-9.9.5 regression test error
## Doug Barton (do...@dougbarton.us): > If you don't have enough random bits on your system to run these simple > tests, your /dev/random is seriously underpopulated, and likely a > security risk. You should definitely not put BIND in production compiled > with the option you mention above. Our build/test environment is not our production environment. Further, the ideas about "random numbers for practical purposes" have shifted a bit. In short, you don't really need "high real entropy", but a stream of numbers *unpredictable to the adversary*. See: http://www.metzdowd.com/pipermail/cryptography/2014-February/019920.html http://blog.cr.yp.to/20140205-entropy.html http://iang.org/ssl/hard_truths_hard_random_numbers.html In fact, on systems like FreeBSD you never get to see the "entropy" directly, you only get the output of a PRNG (yarrow in this case), which is periodically reseeded with "real entropy". Even linux ranodm(4) suggests to use /dev/urandom in most cases, as frequent reads on /dev/random will deplete the entropy pool and make /dev/random unusuable for those who really need it. Regards, Christoph -- Spare Space ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
