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.
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.
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.
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 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.
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.
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.
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:
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.
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:
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 1.3.post-7 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.
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 MaraDNS.org in the MaraDNS tarball.
The Deadwood snapshot can be downloaded here and the MaraDNS snapshot is here.
My next plan for Deadwood is to consolidate multiple requests for the same hostname. In other words, if one user asks for "www.example.com", and while we wait for the answer for "www.example.com" 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 "www.example.com", and send the reply back to both requesters at the same time once we get the answer upstream.
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 example.com 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.
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.
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.
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 1.3.15.01.
And, oh, I should start thinking about making Deadwood fully recursive.
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.
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.
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.
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
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 MaraDNS.org 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.