sudo in CentOS

I finally got sick and tired of having to, in CentOS, type in su, followed by the root password, just to run Deadwood (which needs to run as root since it needs to bind to port 53), followed by exiting the root prompt. So, I finally did a simple RTFM with the “sudo” man page and edited /etc/sudoers so that my user account can use sudo to run the program. Just like how things are done in Ubuntu.

Come to think of it, I could have used dns_port to have Deadwood bind to a unprivileged port and then just connect to that port. But, then again, I would have to add selectable port numbers to askmara (my command-line utility in MaraDNS for making DNS queries from the command line). Nah.

Now, if only there was a sudo get_me_a_job and sudo get_my_wife_a_US_visa (well, there is the second one, but it supposedly takes about a year; I need a sudo nice -20 get_my_wife_a_US_visa so they will do it faster).

RadioGatún[32] passes all Dieharder tests

Dieharder is a series of tests to test the quality of random numbers. I have installed Dieharder 2.27.12 on my CentOS virtual machine (by virtue of the fact that this is the most recent version of Dieharder with handy precompiled 32-bit binaries) and then started running RadioGatún[32] as a stream cipher through this battery of tests.

The first time I tested RG32 (my shorthand for “RadioGatún[32]”), a couple of tests were marked as poor—which is not surprising, since the full battery is some 74 tests. When a tests is marked as being “poor”, that indicates that the stream of random numbers generated have a 1% or smaller chance of not being random. A good set of random numbers will occasionally fail a randomness test, since well-made random numbers sometimes do not quite look random.

I re-ran the tests that were “poor”, first with the same RG32 seed at a different point in its stream (which resulted in having a “possibly weak” result—a 5% chance the test was not random—for a different test, which is not surprising since there are 20 tests in this section of Dieharder), then with a couple of other RG32 seeds. With the third RG32 seed, none of the 20 tests were marked “poor” or “possibly weak”.

Conclusion: RG32 shows no biases when used as a pseudo-random number generator (PRNG). In practical terms: Deadwood is using a strong random number generator.

While I was testing the quality of RadioGatún’s random stream, I tried to run the tests at CAcert.at, but the server gave me an “Internal server error” instead of test results. I tried with two different sample sizes (one about 130 megs in size; the other about 18 megs in size).

I should note that RG32 is quite fast, even with the code-size-optimized implementation I made for Deadwood. Compiled with -03 in GCC, I got 20 megabytes of numbers in three or four seconds. cat /dev/null gives me 200 megabytes of zeros in the same amount of time.

Update: Using the rg32 seed (hash input) of “dieharder7&rdquo, Dieharder 2.27.12 passes all tests; again, random numbers should sometimes fail a randomness test, but they don’t with this particular seed and particular version of the full Dieharder test suite.

Windows does have /dev/random

You know, I spent too many years reading Slashdot. I somehow got the impression that Windows did not have a good source of cryptographically strong pseudo-random numbers. While true for Windows 95 and Windows 98, this has not been true for years.

Microsoft Windows has had, since Windows 2000, a form of /dev/random/ called CryptGenRandom(). Indeed, it appears that MinGW/Msys have the required wincrypt.h header file for supporting this function.

I will have to, once I get the DNS resolution bugs fixed, set things up so Deadwood uses CryptGenRandom() for some of the entropy for random query IDs and ports, and not require a secret file.

ObHack 006.9 released

Fritz and I have made another release of ObHack. Fritz has done all of the hard work updating the program; my contributions consist of verifying there are no viruses in the Windows binary (with AVG) and making the .zip file and source code .7z file.

It can be seen here:

http://samiam.org/slump/

Since Andrew hasn't come out with an OBLIGE release in a while, this should whet people's appetites for having an updated Doom random map generator.

As always, I do not support ObHack; please do not post to this blog ObHack support concerns--they will not be approved.

Update: A more detailed changelog and support for ObHack 006.9 is available in this Doomworld discussion.

I am getting sponsorship for MaraDNS

I am letting people know that I am now getting regular sponsorship for MaraDNS. This means that, as long as the sponsorship continues, I will, contrary to the roadmap I placed in this blog entry, add new features to MaraDNS (as I said when I clarified my MaraDNS roadmap).

That’s the good news.

The bad news for the freetards is that the features I will add will be the features my sponsor wants me to add. They are not the features you want to add to MaraDNS—unless you’re willing to also sponsor MaraDNS.

Deadwood update: I have found some bugs

Just letting you all know that I have, from a single day of casual web surfing, found a number of host names that don’t resolve correctly with Deadwood 2.6.04. I will be working on fixing those this week.

There is no need to send me bug reports about Deadwood 2.6.04. I am already aware of its bugs.

I should probably note that Deadwood has much more solid code that MaraDNS 1.0’s recursive resolver did at this point back in 2001; the bugs I’m seeing are SERVER FAILs and hostnames resolving incorrectly. The bugs MaraDNS 1.0 had during this phase of development (good enough to start using on the real internet for recursive resolution) caused crashes.

Deadwood 2.6.04 released: CNAME support

I’m almost at the finish line.

Deadwood is almost feature-complete for the (hopefully very soon) up-and-coming 2.0 release of MaraDNS.

This morning, I wrapped up support for resolving incomplete CNAME entries. The only thing I have to do at this point is have Deadwood do the right thing for ANY records, then the testing cycle begins.

In plain English, this means Deadwood is ready for people who do not need to run an email server with it (email servers need to do a lot of ANY queries); it is OK to test it by browsing the web with it.

As I was doing the regression tests for the release (a series of tests I run before any release to make sure nothing breaks between releases), I discovered that one of my tests, which works fine in CentOS 5.3 and 5.4, no longer works in CentOS 5.5. This is an issue with the OS, not Deadwood. If I have time and feel charitable, I will isolate the bug and make a bug report. I still run this test in CentOS 5.3 when I do Deadwood’s 64-bit testing.

In addition, I had to revise the tests using Valgrind, since CentOS 5.5 has updated Valgrind to a version with slightly different output. I have set up these tests to have two successful outputs—the output in Valgrind that comes with CentOS 5.5, and the old output for when I do 64-bit testing in CentOS 5.3.

This release of Deadwood is available here:

http://maradns.org/deadwood/testing/

I am using its recursive resolution to write this blog entry right now. Web surfing around, the only website I have seen problems with is tagged.com; some host name needed to load Javascript here isn’t resolving. I will look at this when I have some time.

Another known bug is that Deadwood makes unneeded multiple upstream DNS queries when resolving an incomplete CNAME record.

OK, I have a lot to do, but encourage users who aren’t running MTAs (email servers) to test out Deadwood 2.6.04 and report any bugs as comments here or on the MaraDNS mailing list. Please do not email me bug reports, unless it’s a Bugtraq-worthy security bug report.