MaraDNS Halloween snapshot

I have uploaded a new snapshot of MaraDNS today. This snapshot is a snapshot of the work I have done so far porting Deadwood to Windows. The UDP client works; the TCP client, however, has problems which I am still debugging.

Windows sockets are somewhat different from *NIX sockets; I have been reading the Winsock Programmer's FAQ and have downloaded Visual Studio C++ express with all of the MSDN documentation, which will hopefully give me the Windows version of things like "man 2 select".

Some of the *NIX code looks different since I'm making Deadwood portable. There is not a fcntl() visible in the main code; instead I have a macro, make_socket_nonblock() which does the right thing in both *NIX and Windows. There are some other changes: Sockets are not ints, but SOCKETs in Windows; you don't close() a socket, but closesocket() it. An error for sockets is INVALID_SOCKET. There's no inet_aton(), much less inet_pton(), so I just wrote a wrapper for inet_addr() that acts like inet_pton(). The socket code now looks like a strange mixture of Windows and *NIX socket code, with #defines in DwSocket.h making the Windows code look like *NIX code, and making the *NIX code look like Windows code.

My current project is to fix the TCP code in Windows.

As an aside, XP service pack 2 only has one loopback IP address, but Microsoft has a hotfix that fixes this issue; I needed to do this so I can test MaraDNS when offline.

You know, it's a mystery to me why IPV6, out of its 340282366920938463463374607431768211456 possible IPs, only allocates one for loopback. I mean, they could have allocated 16 IPV6 IPs for loopback; I'm sure 340282366920938463463374607431768211440 IPs is enough for non-loopback use.

Anyway, the latest snapshot can be downloaded here.

- Sam

MaraDNS snapshot update: Deadwood now has TCP support

I have added TCP load balancing support to Deadwood. Let me clarify that: Deadwood now compiles two programs, DwMain, which is the UDP DNS load balancer, and DwTcp, which is currently a general-purpose simple TCP load balancer.

What DwTcp does is quite simple: It listens on a user-settable port (53, or DNS, by default). When a client connects to it, DwTcp connects to the upstream TCP server on a user-settable port (again, 53 by default) and any data the client sends over TCP is sent, unchanged, to the upstream server, and any data upstream sends over TCP is sent, unchanged, back to the client.

DwTcp is currently not DNS-specific. It could be used as a HTTP or even SMTP load balancer. The main problem with DwTcp is, when used as a load balancer, is that the servers behind DwTcp will not be able to determine the IP connections come from--they will see the DwTcp server's IP, and DwTcp does not log connections.

My plan is to integrate the TCP code back in to DwMain, making DwMain both a TCP and UDP DNS load balancer. I have written the DwTcp code in a manner that should not make this too difficult to do.

I also plan on making the TCP code do some useful DNS-specific things. One useful feature, for example, would be to look at the incoming TCP packet. If the request is not an AXFR or IXFR request, send the question over UDP and, if the UDP reply is not truncated, convert the UDP reply back in to a TCP reply. If the packet is truncated, try again over TCP.

However, other things are more important. I am currently working on Winsock support and getting the code to run as a native Windows binary with MinGW32. Both the UDP and TCP code compile in Windows, but the socket() call fails in the TCP code. Since I didn't have Winsock documentation at home, I couldn't resolve the issue.

After finishing that, I want to add ip-based ACL support which will allow the load balancers to restrict the range of IP addresses that can connect to the load balancer.

MaraDNS snapshot update

Jean-Jacques Sarton and myself have added IPV6 support to Deadwood. This is an optional compile-time flag, since a number of systems don't have IPV6 support yet (Cygwin and Mingw32, *cough* *cough*). In order to enable IPV6 support, add '-DIPV6' to the flags when compiling Deadwood, as in:

        export FLAGS='-Os -DIPV6'
        make

The IPV6 support adds, in DeLi Linux 0.7.2, 356 bytes to the code when disabled, and 708 bytes to the code when enabled. The binary is now 14,448 bytes in size when compiled in DeLi 0.7.2 with the '-Os' flag, IPv6 disabled, and the binary stripped. With IPv6 enabled, the binary is 14,800 bytes in size. Of course, keep in mind that uClibc is also bigger when it has IPv6 support.

In addition, it would seem that, somewhere in the 1.2 development cycle, I broke the echoing of the RD ("Recursion Desired") bit in the DNS header. This has been restored. Also, looking at that code, I realized it wasn't thread-safe, so I made the code thread safe. Also, it would seme that not only do some brain-dead embedded DNS programs check the RD bit in the DNS header, they also check the RA ("Recursion Available") bit (neither bit should be looked at whem getting a DNS reply, but oh well). So, I've hacked things so MaraDNS replies with a packet with the RA bit off if sending an authoritative reply, and the RA on if sending a recrusive reply. Not 100% ananally RFC-compliant, but should fix the problems seen with braindead DNS programs.

And yes, the RD and RA fixes have been backported to the 1.2 branch, and should be a part of the next 1.2 release (mid-December, barring a critical security problem).

The MaraDNS snapshot can be downloaded here

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

MaraDNS support email works again

Just letting everyone know that MaraDNS support email works again, and that people can send me MaraDNS support questions via private email from the MaraDNS contact page.

I won't have an update to the MaraDNS code today; I have been too busy with real life to work on MaraDNS for the last couple of days. I may have a minor update for Friday; we'll see.

I should have time Sunday to work on MaraDNS again.

- Sam

MaraDNS snapshot update

I have been hard at work on the Deadwood project these last few days. This is the code that will eventually replace MaraDNS' recursive core. I have managed to accomplish the following with the Deadwood code this weekend:

• I created a finite state machine tokenizer that can convert a FSM definition in to easy-to-parse tokens.
• I greated a FSM definition that can parse mararc files.
• I created a parser to parse the tokenized mararc FSM definition.
• I wrote a wrapper for the FSM parser to parse mararc files and store the parameters in memory for access by other parts of the Deadwood project.
• I added some capabilities to the DwString library so it is able to do all of the above.
• I wrote a coding style document for the Deadwood code.

I have also made some minor revisions to the main MaraDNS code:

• I have added an #ifdef that should resolve the problem with running MaraDNS on cygwin
• I have removed the one warning visible when MaraDNS is compiled as an authoritative-only client (with ipv6 support to boot)

Anyway, the snapshot can be looked at here.

---

I am aware that MaraDNS support email is currently not working. I have let the relevant people know, and things will hopefully be resolved in a few days.

Groundbreaking of Deadwood project

In today's snapshot of MaraDNS, I have started a new project that I have been meaning to do for years: A complete rewrite of the recursive half of MaraDNS. I am calling this project the "Deadwood" project. My goals is to, step by step, make a non threaded recursive DNS server. The three stages of the Deadwood project will be

• Make a basic "load balancing" DNS server that takes incoming DNS requests, sends the request on to one or more "upstream" DNS servers, and give the reply from the upstream server back to the client.
• Make a basic caching DNS server, that will need the upstream server do all the heavy lifting of making the recursive query, but that will remember queries so the upstream server doesn't have to do as much work
• A full-featured recursive server, like what MaraDNS now has

Today, I have begun the first step; it is, if you will, the "groundbreaking" (first) release of the new MaraDNS recursor. What I have done is make a simplified buffer-overflow resistant string library that has all of the parts of MaraDNS's string library that I actually use, but none of the stuff that I implemented but never use. My next step is to make a mararc parser, and then I will make the DNS client.

It is part of the lastest MaraDNS snapshot available here, in a directory with the title deadwood-1

While I have wanted to do this for years now, I'm glad I waited because people have done a lot of testing with MaraDNS and found some minor security problems. I now know what coding mistakes to avoid to not even have those minimal kinds of security problems.

MaraDNS snapshot update

I have been updating the MaraDNS snapshot for the last couple of days. Fairly minor updates; yesterday I added a test to make sure the zoneserver works. Today, I added a test to make sure the ipv6 binding works when MaraDNS is compiled as an authoritative-only client. It can be downloaded here.

- Sam

Announce: C-40 interactice fiction contest

After the success of the Commodore 32 machine shipped in 2004, we have decided to upgrade this machine for 2007. The new C-40 machine is available at an even lower price than the 2004 Commodore 32, has an easier-to-read LCD panel display, and is far more portable than our earlier model.

While completely compatible with the Commodore 32 games, the C-40 also has an expanded memory. This machine has some 40960 bytes of memory that game cartridges can use. Like the Commodore 32, this C-40 can play both z3 and z5 z-machine games.

We are looking forward to shipping some games that will take full advantage of the C-40s large memory for the Christmas season this year. This is where you come in: We are introducing a C-40 contest where anyone on the internet can make a z3/z5 z-machine game that fits in 40960 bytes or less. Unlike the previous Commodore 32 contest, one is not required to use Inform nor the minform library to make entries for this contest. Any system that the contest entry writer can come up with to pack as much adventure in 40960 bytes is welcome, including home-grown parsers and optimized assembly language. In addition, games are not limited to text adventures; ASCII arcade games are welcome, as long as they can be played on the C-40's 80x24 display.

We are also looking for judges to judge the games in the contest.

The rules of this contest are:

• Any kind of game that is a Z-machine version 3 or Z-machine version 5 game that fits in 40960 bytes or less is welcome.
• All games submitted to this contest must be original for the contest.
• All games must run correctly in Frotz 2.43 using an 80x24 display.
• All games must be submitted on or before Monday, December 4 2007.
• All games are to be submitted to me via email.
• Any entry submitted to the C-40 contest must be one where there is permission to redistribute the submission on my webpage and on the IF archive.

As a matter of convenience, I have version 6.15 of Inform along with the mInform library available for people who want to use this SDK (Software development kit) to make entries for this contest available here (400k .zip file).

This will run in both *nix systems (including Mac OS X) and on Microsoft Windows. Windows users: You will need to create a directory named \tmp before being able to compile programs with the inform.exe program included in the zip file.

Based on the Commodore 32 entries, one should be able to fit a small 10-room adventure in the 40960 bytes allowed in the C-40 contest, or, with some clever programming, a large 25-room adventure.

Of course, one could opt to make a huge Scott-Adams style adventure with dozens of rooms. Or, for that matter, one can make a very extensive ASCII ART arcade game in 40960 bytes (but remember the 80x24 rule!).

- Sam

MaraDNS snapshot update

I have made some improvments to MaraDNS in today's snapshot

• MaraDNS compiles again (albeit with one warning) with configured to be authoritative-only ( ./configure --authonly; make )
• Tests revised to pass when running a snapshot version of MaraDNS
• New script that only runs the tests relevant for the authoritative-only compile of MaraDNS added

It can be downloaded here.

Maradns snapshot update

I have uploaded a snapshot of MaraDNS today. In today's snapshot, I have added support for AIX contributed by Alfred Reibenschuh. I have also added a large number of tests to make sure most mararc parameters work, and fixed a couple of ocscure mararc parameters that were not working correctly.

It can be downloaded here

- Sam