Monday, August 31, 2009

Deadwood 2.4.07 released

I have just released Deadwood 2.4.07. This is a testing release that emphasizes adding new features more than fixing bugs.

The new features added after 2.4.06 are:
  • execfile support
  • Multiple in-flight queries for the same hostname are merged.
It can be downloaded here:

OK, I'm going to take a break from Deadwood and MaraDNS development for a few days or so.

Sunday, August 30, 2009

New Deadwood snapshot: Almost ready for Deadwood-2.4.07

I have finished up the multiple inflight SQA test and fixed a single segfault I found during the test.

Now, all I have to do before releasing Deadwood 2.4.07 is make sure it works In Windows, verify all of the SQA tests pass, then make and upload the source code tarball and Windows binaries.

In the meantime:

New Deadwood snapshot

I'm working on a test for inflight merging, and have documented the max_inflights parameter.

Friday, August 28, 2009

Deadwood snapshot update: inflight merging code finished

The code hasn't been tested, but Deadwood should now have multiple inflight query support.

Next: Test the code (make a custom DNS server that takes a few seconds to reply and increase Deadwood's timeout in the test)

In the meantime:

Thursday, August 27, 2009

Minor Deadwood snapshot update

I've added code to initialize the "inflight" hash (list of current in-flight DNS requests) and have added a CODE HERE to mark where I will add code to handle in-flight requests. I will also need to make code that removes inflight requests whenever we close a connection.

Wednesday, August 26, 2009

New Deadwood snapshot

In today's Deadwood snapshot, I'm continuing work on merging multiple in-flight DNS requests. It's here:

Tuesday, August 25, 2009

ObHack 006.3 released by Fritz

While I no longer am working on the ObHack codebase (modifications I did to the original 2007 Oblige 2 code), Fritz has taken over maintenance of the code and we have just released Obhack 006.3:

ObHack has a number of features not in to the Oblige 3 codebase, such as Deathmatch and CTF support (unlike Oblige, even single-player maps have some basic Deathmatch support, and there's even a mode which tries to make maps that are both good DM and single-player maps), Heretic support, and what not.

I hope people enjoy the code. Feel free to post suggested features or bugfixes here, but remember that Fritz, not myself, is maintaining the code.

New MaraDNS snapshot

I've updated the web page and have applied a one-line patch to fix the issue described here.

The file can be seen here:

Monday, August 24, 2009

Deadwood update: No Deadwood 2.3.05 release needed

I've looked at the code in handle_expired again and have concluded that the code does not present any security risk. The relevant code appears to be a fossil from the Deadwood 1 days, before I added randomization. The code copies over the Query ID from the local connection to the remote connection, makes a DNS header, then calls make_remote_connection to send a packet to the remote DNS server.

make_remote_connection uses set_dns_qid to make the query ID random before sending it to the remote DNS server.

In conclusion: There is no need to make a new Deadwood 2.3 release; the DNS QID is always a random number. However, the cleanup to make it so it doesn't look like the QID isn't random I'm going to keep in the 2.3 tree; should a bug come up in the 2.3 code, I'll also apply this fix.

New Deadwood snapshots

Doing work on being able to merge multiple in-flight requests together. As I looked over the code, I realized some things didn't work with DNS-over-TCP (resurrections, blacklist_ip), which I think I have fixed (but I'm not going to test this; DNS-over-TCP is a bad hack).

In addition, the code that resent queries when we didn't hear from upstream has been revamped to create a new query ID number every time we resend the query, instead of echoing the local query ID. This is something I have also fixed in the Deadwood 2.3 codebase.

One issue is that, sometimes we will need to keep the DNS-over-TCP connections around while the DNS-over-UDP connections have died. I've redone forward_remote_reply() so that, once this routine sends a UDP reply, it resets that particular local UDP connection so it won't send a reply again. This will hopefully solve the multiple DNS-over-TCP issue.

I think I will have it so DNS-over-TCP connections simply don't look for in-flight requests, but always open up a new request. I'll do this, but put some things in place so we could have both UDP and TCP on the same connection number if this is desirable in the future.

The work can be seen here:

The deadwood-H releases are releases for the next 2.4 release of Deadwood (the "Head" branch); the deadwood-S releases will become the next 2.3 release of Deadwood (the "Stable" branch). I have run all tests in 32-bit CentOS for the next stable release; all I have to do before Deadwood 2.3.05 is to test it in 64-bit CentOS, make a new random prime for both the source code and the Windows compile, make a Windows compile, then Deadwood 2.3.05 will be ready.

Sunday, August 23, 2009

New Deadwood snapshot: Final touches to execfile

I've done a couple of final touches to execfile support in Deadwood today; I have made it so execfile doesn't change directories in Windows, did a bit of final touch-up to the documentation, notably documenting it in Windows.

It's here:

Saturday, August 22, 2009

Deadwood snapshot update: execfile finished

OK, guys, I've decided to not devote any more time to execfile("foo") in Deadwood.

I have finished up the feature this morning; all files parsed with execfile must be in /etc/deadwood/execfile and errors in sub-files are not correctly reported; the workaround is Deadwood -f /etc/deadwood/execfile/filename, which will report the line a parse error is on.

I have also documented execfile.

The one last thing I will do before the next Deadwood 2.4 release is have it so, on Windows systems, execfile uses a different directory besides /etc/deadwood/execfile; probably just the same directory all the other Deadwood files are in Windows (#ifdef the chdir() to make sure it isn't used in Windows).

It's time to go back to merging multiple in-flight DNS requests.

Friday, August 21, 2009

New Deadwood snapshot

I am working on making it possible for the parser to load other files to parse while parsing a dwood2rc file; this makes some kinds of management easier for some sysadmins.

The feature currently works, but I need to harden it against security-type issues this feature can add.

Thursday, August 20, 2009

Deadwood 2.4.06 released: ip_blacklist support

I have released Deadwood 2.4.06; this release of Deadwood has ip_blacklist support.

This is useful if you have one of those annoying ISPs who take "not there" queries or otherwise performs "NXDOMAIN redirection". Simply add the IPs your ISP directs to you when you should get a NXDOMAIN, and Deadwood will convert any DNS response with one of the offending IPs in to a "not there" DNS reply.

Note that Deadwood will not convert cached entries this way; if you wish to use this feature and have used earlier versions of Deadwood, please delete your Deadwood cache first.

It can be downloaded for both CentOS Linux (as source code) and Windows here:

Wednesday, August 19, 2009

Deadwood updates

IPv6 now works with Deadwood and there's a new SQA regression to test the ip_blacklist feature. In addition, the synthetic "not there" reply now correctly echoes the client's ID, and another test caught a floating point exception ("foo % a" in C needs to make sure a is 0 or bad things happen) in some of the code I added before in the 2.4 branch of Deadwood.

I've updated the tests and should be able to release Deadwood 2.4.06 tomorrow.

In the meantime:

Tuesday, August 18, 2009

New Deadwood snapshot

Deadwood now sends out synthetic 0-TTL "not there" replies when given an answer with an IP on the ip_blacklist. Next:
  • IPv6 support for blacklisted IPs
  • SQA regression
  • Release Deadwood 2.4.06
In the meantime:

Monday, August 17, 2009

New Deadwood snapshot: Workaround for ISPs' error pages

Well, surfing the net this weekend, I discovered that those annoying little "error pages" (usually filled with ads) that some ISPs hoist on customers when they misspell a URL or otherwise go to a page without a DNS entry are actually a potential security problem.

That in mind, I have implemented a new dwood2rc parameter: ip_blacklist. Should an IP appear in an answer that is in the ip_blacklist, Deadwood will reject the answer. I have already implemented and documented the new feature, but I need to make these kinds of answers proper "nothere" replies (not actual NXDOMAINs for technical reasons), add IPv6 support (done in some parts of the code but not all of it), add a SQA regression, then I should be done with this feature.

For people who want to try out the feature in the meantime, it's here:

Friday, August 14, 2009

New Deadwood snapshot; new MaraDNS timeline

I have started work on having it so multiple identical "in flight" DNS requests only send one query to the remote server. This is to minimize a possible security problem.

I have decided to revise the MaraDNS timeline. The current MaraDNS timeline is as follows:
  • MaraDNS 1.0 will be supported for critical security fixes only until December 21, 2010. Should a security bug be discovered just before the cut-off date, requiring changes so that the patched version would be released after December 21, I will simply remove MaraDNS 1.0.
  • MaraDNS 1.2 is only supported for critical security fixes, and only until December 21, 2010. As per 1.0, should a security bug be discovered just before the cut-off date, requiring changes so that the patched version would be released after December 21, I will simply remove MaraDNS 1.2.
  • MaraDNS 1.3.07 will be supported only for critical security patches for the foreseeable future. A EOL date will be announced when and if MaraDNS 2.0 is released.
  • Critical bug fixes will be applied to the branch of MaraDNS for the foreseeable future.
  • I have no planned release date for MaraDNS 2.0. Indeed, at this point, I've decided to not even promise that MaraDNS 2.0 will be released. I hope it is, but I just don't like having a commitment to, say, release MaraDNS 2.0 before the end of the year looming over me.
What does this mean? It means that, while I still support MaraDNS (and appreciate all of the donations I have received), I'm not making enough money with MaraDNS for me to commit to releasing MaraDNS 2.0.

I'm having a lot of fun working on Deadwood, and I really hope to finish up the Deadwood code and release MaraDNS 2.0 by the end of the year, but, no promises. Since I'm not making much money doing this, this is "for fun and for free". Timelines and deadlines are not fun. So, I'm getting rid of them.

Monday, August 10, 2009

Deadwood and MaraDNS snapshot updates

I have released minor updates to the MaraDNS and Deadwood snapshots today; both are documentation-only changes. There were a couple of remaining references to the 2.3 DeadwoodTCP service in the README.txt for the Windows version of Deadwood; I have removed these.

In addition, I fixed the HTML a little for the MaraDNS download page and updated the copy of in the MaraDNS tarball.

The Deadwood snapshot can be downloaded here and the MaraDNS snapshot is here.

Sunday, August 9, 2009

Deadwood roadmap: Consolidate multiple requests for the same name

My next plan for Deadwood is to consolidate multiple requests for the same hostname. In other words, if one user asks for "", and while we wait for the answer for "" upstream, another user makes the same request, instead of processing it as a separate request, it makes more sense to attach the new request to the already-in-place request for "", and send the reply back to both requesters at the same time once we get the answer upstream.

Doing things this way improves security.

MaraDNS and Deadwood snapshot updates

I have uploaded an update to the stable 2.3 branch of Deadwood today; in this snapshot I have made a one-line change to the sqa_tcp test so it works with the new DNS packet the server sends over TCP. No other changes have been made. All SQA tests in Deadwood 2.3 now pass when using maradns-1.3.14 as the authoritative server.

It can be downloaded here.

I have also updated the MaraDNS snapshot to have the webpage download page point to MaraDNS 1.3.14, and now include the CSS for the idea I had a couple of months ago to change the colors of the MaraDNS webpage a little.

This can be downloaded here

Deadwood 2.4.05 released

OK, it's here: Deadwood 2.4.05. This release of Deadwood takes advantage of the now-working DNS compression code by implementing both resource record rotation and TTL aging. I've also updated the documents included in the Windows version to reflect the Deadwood changes.

It can be downloaded at

Next: I need to update Deadwood 2.3's SQA regressions to work with the maradns-1.3.14 changes. Then I need to release Deadwood 2.3.05 with these minor changes. Then I should update the MaraDNS docs (things like having the internal copy of the MaraDNS download webpage point to MaraDNS 1.3.14), add a NAPTR test to MaraDNS, etc..

Then I can start thinking about when I should release MaraDNS

And, oh, I should start thinking about making Deadwood fully recursive.

Saturday, August 8, 2009

Deadwood snapshot update

I have updated all of the SQA tests so that they pass with the new version of Deadwood; I uncovered a single bug (one memory leak) and revised the tests to disable RR rotation and TTL aging if it broke the test, changed the program name from "DwMain" to "Deadwood", accounted for the new cache format, etc.

I have also updated the documentation to refer to Deadwood by its new name, "Deadwood", instead of the old "DwMain" name.

My current Deadwood roadmap:
  • Add two SQA regressions; one to make sure RR rotation works (easy), another to make sure TTL aging works (a little more tricky, since I have to write a small Awk script to show the TTL as being within a certain range so the test doesn't fail when the TTL is one second shorter or longer)
  • Revise Valgrind SQA test to trigger both TTL aging and RR rotation (I've done this test by hand and already know this is not an issue, but having the regression is a good idea)
  • Verify that Deadwood passes all tests
  • Release Deadwood 2.4.05
In the meantime, the snapshot can be downloaded here.

Friday, August 7, 2009

Deadwood snapshot update

I am working on getting the tests revised to work with the post-2.4.04 Deadwood changes. Most of the tests have been revised.

The latest Deadwood snapshot can be downloaded here

MaraDNS snapshot update

Joey Parrish contributed a fix for MaraDNS parsing NAPTR records; this is integrated in the latest snapshot of MaraDNS, which can be downloaded here

Thanks, Joey, for helping MaraDNS development.

Wednesday, August 5, 2009

MaraDNS snapshot update

I've updated some of the documentation, the changelog, and a couple of web pages (updating the date of the last MaraDNS release to August 4, 2009; updating the advocacy page to point out the djbdns now has three security issues in its latest tarball)

I've also removed older MaraDNS snapshots, since we have just released MaraDNS 1.3.14.

It can be looked at here

OK, back to Deadwood.

Tuesday, August 4, 2009

MaraDNS 1.3.14 released

I have just released MaraDNS 1.3.14:
  • William Summers submitted a patch to fix OpenBSD compile issues.
  • Deadwood 2 updated to Deadwood-2.04 (with the tools also in MaraDNS removed and the INSTALL document revised accordingly)
  • Workaround for AFNIC (.fr) registration issues added
  • GCC 4.3.2 compile-time warnings removed
  • Milan Kupcevic added dns_port support to zoneserver
  • stdint.h now used for fixed-sized integers; this should make MaraDNS easier to compile on unsupported platforms.
It can be downloaded here

Monday, August 3, 2009

Deadwood snapshot update

At this point, both TTL aging and resource record rotation are working in Deadwood. Before releasing Deadwood 2.4.05:
  • Revise SQA regressions as needed to work with new Deadwood behavior
  • Add two SQA regressions; one to make sure RR rotation works, another to make sure TTL aging works
  • Revise Valgrind SQA test to trigger both TTL aging and RR rotation
  • Make sure all SQA tests pass
In the meantime, the snapshot is here

Sunday, August 2, 2009

Some guidelines on ObHack hacking

Since there is some interest in ObHack still, even though I've stopped work on it myself, I'll give people some guidelines for modifying ObHack.

ObHack is a C++ frontend; all the C++ code does is display the GUI and physically write the wad file. The lion's share of ObHack code is written in a language popular with game designers called LUA, a straightforward language that is a lot cleaner and maintainable than C.

The only time the C++ code needs to be modified is if one wishes to change the options seen in the GUI, or one wishes to change the version number of ObHack reported in the wad files created.

For people who aren't comfortable with C++, no big deal. Just change the LUA scripts (indeed, my earliest releases of ObHack were Oblige with just the scripts modified).

What ObHack does is first plan the level to be built. ObHack decides how many "quests" are there; a quest is going down a path until you're in a room with a small podium and a goody on the podium like a key, weapon, or power-up (a quest can also end with a switch that opens a door or to the exit that takes us to the next level). ObHack decides how many key quests to make, how many and what type of weapon and power-up quests there are, whether a given quest is secret, etc. ObHack also decides how long a quest should be at this point (how long the path we go down until we find the desired item is), and where the player starts on the map.

Once ObHack decides the quests to make, ObHack then sets up a square grid and decides how the squares are connected to each other, whether a given square is indoor or outdoors, etc. (Quests are marked with the type of scenery a place has, whether it's indoors or outdoors and what the floor, walls, etc. look like) Should ObHack not be able to make an exit quest or a key quest for a given locked door, ObHack will try again; if we can't make the quest as long as we wanted, ObHack will make the quest shorter, etc. ObHack also decides the average elevation of a given square at this point.

Each one of these squares is the size of a "room". ObHack also, at this point, decides to have "scenic" squares which you can not enter (nor can monsters enter) but add some scenery (this is why you see things like cages without monsters in them; that's a cage put in a scenic square).

Once the arrangement of rooms is done, ObHack then uses builder.lua to build the map. It is at this point that ObHack places ammo, health, armor (that isn't a goody at the end of a quest), and monsters. In addition, ObHack adds stairs, platforms, and scenery to levels (prefabs like the fountain, the pillars, and what not). Should ObHack not be able to place a stair in a level, ObHack will try redrawing the level again (starting from scratch with the planner) until ObHack has a level it is satisfied with.

Once that is done, ObHack converts the level in to a Doom wad, writes the wad, and the C++ code uses glbsp to make the wad have a node tree and be playable in Doom/Heretic.

So, for people who want to further develop ObHack, this should give people a starting point. LUA is really easy to program; don't let the C++ code scare you. The LUA code is a little messy at times, and, to be honest, I don't have time to really help people understand the code.

If anyone wants to continue working on ObHack and maintain the code, let me know. It's a lot of work, but you will have the satisfaction of having a Doom random map generator you have complete control over.

New MaraDNS and Deadwood snapshots

I've released a new MaraDNS and Deadwood snapshot today.

In the MaraDNS snapshot, I have further improved the heuristics for determining what value to have for RA (The DNS "Recursion available" bit). The RA bit is, quite frankly, a bit the DNS spec should never of had. It doesn't supply any really useful information.

An issue someone reported a couple of years ago is that some brain-dead embedded DNS caches actually look at the RA bit and won't accept recursive responses unless RA is set to one. So I spent a couple of days patching the MaraDNS source code to have RA be set for recursive replies.

Another issue reported on the MaraDNS mailing list is that the brain-dead AFNIC (.fr domains) looks at the RA bit returned by a server and doesn't allow a domain to be registered if RA is set but the IP in question isn't allowed to make recursive queries.

So, I've further refined things so that the AR bit is not set if the user hasn't enabled recursion (or if MaraDNS is compiled without recursive support via "./configure --authonly; make"). This allows people registering .fr domains with MaraDNS to have a way to register their domain (make sure the MaraDNS server serving the .fr domain doesn't have recursion enabled).

So, yeah, this issue should be resolved. I now need to set up some automated tests to make sure things still work for people using MaraDNS with brain-dead DNS implementations that refuse recursive answers without the RA bit set.

I've also updated Deadwood (the recursive resolver for the future MaraDNS 2.0 release) today; a small bugfix: Resource records would not rotate if the TTL was greater than about a day (1/256 of a year, to be precise).

The MaraDNS snapshot can be seen here and the Deadwood snapshot here

Saturday, August 1, 2009

New MaraDNS snapshot

I have just released a new snapshot of MaraDNS today; the first one since April:
  • Version of deadwood included with MaraDNS updated to 2.3.04
  • Web page content in tarball updated to be current with webpage
  • The code now uses stdint.h for fix-sized integers in the majority of the code; this should fix the Solaris compile problems
My next step is the set things up so the RA (recursion available) bit is always 0 if the user has not enabled recursion in MaraDNS with the recursive_acl parameter. I don't know when I will have time to finish this.

It can be downloaded here