MaraDNS snapshot update

Well, I've implemented a secure random number generator for the new Deadwood code. Last time, with MaraDNS, I used AES, which became an AES variant in late 2001. The problem with AES is that it may have cache timing issues with some CPUs, since it uses table lookups to get indexes based on key information. I revised the code to work around this, at the expense of making the code about three times slower. Also, the code is fairly large and block ciphers are not the best building block for making random streams.

This time, I am using a new stream cipher/cryptographic hash algorithm called "Radio Gatun". Radio Gatun is a new and novel cryptographic primitive: It's a cryptographic hash that can take an input of any length, and generates, from that input, a hash of any desired length. It's also (if not officially) a stream cipher that can take a key of any desired length.

Radio Gatun is a derivative of a late 1990s stream cipher/hash construction called PANAMA. PANAMA's cryptographic hash creation was broken, but it's (as far as we know) still as secure stream cipher. Radio Gatun is not as fast as PANAMA, but appears (so far) to be both a secure cryptographic hash and a secure stream cipher primitive.

Radio Gatun, in theory, can use words of any length from one bit to 64 bits. In practice, test vectors only exist for the 32-bit and the 64-bit versions of Radio Gatun. The Deadwood code is using the 32-bit version of Radio Gatun, but this can be fairly easily changed to use the 64-bit (or, if one wants, the 16-bit or even 8-bit) version by changing two defines in DwRadioGatun.h, and rewriting the dwr_rng() function.

Radio Gatun is a good deal more compact than AES; the entire library fits in under 2k (2048 bytes) when compiled with -Os; compare this with the 12k or so the AES-derived library uses.

---

I have also created a basic SQA test, and fixed some bugs. There was a minor bug in the FSM definition that made it so dwood1rc parameters could not have numbers in them, making ipv4_bind_addresses not work; this has been fixed. Another bug is that I did not use the socket bound on port 53 to forward the remote reply back to the local user; this made Dig unhappy, since Dig checks the port number of the reply.

In addition, I have added "DwMain -f dwood1rc" style argument parsing.

Oh, oh, there's some under the hood changes. DwMain.c is now a very small file; DwSocket.c has all of the functions that use socket-specific code (and no functions that don't use socket code) and DwSys.c has the rest of the functions. This way, adding DNS-over-TCP, ipv6, and WinSock support only requires changing the DwSocket.c file.

The DwMain binary, when compiled in DeLi Linux 0.7.2 with the -Os flag and stripped, is currently 14,092 bytes in size.

MaraDNS 1.3.07.06 and 1.3.09 release

Today I release not one, but two versions of MaraDNS: MaraDNS 1.3.07.06 and MaraDNS 1.3.09. These are both beta-test versions of MaraDNS; the changelog is here. Downloads of these versions of MaraDNS are available here (Scroll down to see the 1.3 releases).

I also have made a tiny version of the Radio Gatún hash function available under the same license terms as MaraDNS (BSD w/o advertising clause), which is available here.

- Sam

MaraDNS update; Ubuntu rant

OK, I have uploaded a new snapshot of MaraDNS today. This fixes a bug in the zoneserver where it did not properly inform the user they have an incorrect IP in their mararc file, and also, the Deadwood project now does something useful.

If you look in the directory deadwood-1 off of the Snapshot's directory, you will observe a number of files. This is a working (if very basic) DNS load balancer. Basically, use "make" to compile the code, and then edit the dwood1rc file to configure the load balancer. The dwood1rc file uses the same general format as a mararc file, but only supports the following three parameters:

1. bind_address This is the IP address we bind to
2. chroot_dir This is the directory the program will run from
3. upstream_servers["."] this is a list of DNS servers that the load balancer will try to contact

Basically, what the server does is listen on the address specified in bind_address. When it gets a DNS query, it will make sure this query is a query (an not an answer), then send the query, as is, to one of the servers listed in upstream_servers["."]. It will then wait up to 7 seconds for an answer from the upstream server. When it gets a reply, it sets the "this is an answer" DNS bit, then sends the reply back to the original client.

The load balancer can only handle 32 pending replies from the upstream server before it will no longer process incoming replies. When the server is overload, it currently silently drops packets.

No attempt is made to randomize the query ID nor the source port of the query when forwarding the query.

Only ipv4 is supported; there is no ipv6 support. Only DNS-over-UDP is support; DNS-over-TCP is not supported.

I plan on, before moving on to implement caching, to add support for randomized query IDs and source ports, to add user-configurable maximum wait time and maximum allowed number of pending queries, to have the server send "server fail" DNS messages if the load balancer is overloaded, and supporting DNS-over-TCP.

In the meantime, people may want to look at the Deadwood code and give me suggestions on how I can improve this code. As always, the snapshot can be downloaded here

---

It would seem that Ubuntu does not come with a firewall by default. Ugh. I'm really disappointed that, not only does Ubuntu install a bunch of services that bind to ports, but they don't bother to install a firewall to protect the system. This is really insecure. What I have done is go in to /etc/rc2.d and turn off all of the services that bind to ports. I have also downloaded an article on installing a firewall in Ubuntu, and am working on getting a firewall going.

In the 1990s, RedHat had a lot of security problems. They finally woke up and RedHat and Fedora now come with a firewall when you install the OS. Ubuntu needs to learn from RedHat's lesson.

MaraDNS snapshot update

Jean-Jacques Sarton has added the ability for askmara-tcp to send IPv6 packets. I haven't tested the code, but MaraDNS compiles without any warnings. The updated snapshot can be downloaded here

Note: MaraDNS 1.3.07 will not include RPMs

I'm letting MaraDNS users know that future releases of MaraDNS 1.3.07 will not include RPM files. The reason is because my current computer does not have a system for building RPM files; I am using my older computer to build the .rpm files, which runs CentOS 3.

Instead, I will have a script update the .spec file with every release of MaraDNS, and rpm users can build their own .rpm files thusly:

• Copy the file build/maradns-version.spec to the directory /usr/src/redhat/SPECS.
• Copy the maradns-version.tar.bz2 file to /usr/src/redhat/SOURCES
• Become root and enter the /usr/src/redhat/SPECS
• As root, do this command: rpmbuild -ba maradns-version.spec.
• You should now have .rpm files in /usr/src/redhat/SRPMS/ and /usr/src/redhat/RPMS/i386 (or whatever)

I will leave the building of .rpm files to people who are experts at making rpm packages, and concentrate my efforts on making the best possible recursive DNS server; my current project is a complete rewrite of the recursive code.

MaraDNS snapshot update

I have uploaded an updated snapshot of MaraDNS today. In this update:

• askmara can now send packets over ipv6 if MaraDNS is compiled as an authoritative-only DNS server (Thanks, Mr. Sarton)
• A script now automatically updates the .rpm spec file
• I have made a lot of progress with the code that will become the new recursive code. We will hopefully have a working load-balancing DNS server with the new recursive code by Friday.

It can be downloaded here.

MaraDNS snapshot update: ipv6 works again

I have uploaded an update to the MaraDNS snapshot. Here are the changes since the last update:

• I broke ipv6 in the last snapshot release when I changed MaraDNS to compile with no warnings when compiled as an authoritative-only server. Fortunatly, my regressions very quickly caught this bug, and I made the one-line fix to get ipv6 to work again.
• Mr. Sarton has added ipv6 support to the askmara-tcp tool (He's actually added a lot of ipv6 support, which I'm slowly making part of the post 1.3.07 code as I get time to evaluate his patches).
• I have added some tests to make sure we can use DNS-over-TCP to send packets over 512 bytes in length (not a big real-world issue, since MaraDNS has full RFC2181 DNS truncation support)
• Some slight updates to the documentation included with the deadwood code

The code can be downloaded here.

I hope to have time Sunday to update Deadwood some more, and release another snapshot Monday.

- Sam