A chronicle of my Linux desktop

I have a tradition, dating back to 1995, of taking a screenshot of my Linux desktop at least once a year; I didn’t make one in 1997, but did make two in 1996, 2002, and 2007.

For the most part, I have been using FVWM1 for my Linux desktop; my 1995 screenshot shows FVWM1, as well as My most recent screenshot for 2010. Indeed, the only years where I’m not using FVWM1 for my desktop are 1996, 1999, 2001, 2002, 2003, and 2009 (but in 2009 FVWM1 is running on a virtual machine, and 2002 has two screenshots, one of which used FVWM1).

My web browser has also changed over the years; the 2000 screenshot shows me using Netscape 4; the 2002 screenshots show me using Mozilla and Konqueror; 2005-2009 screenshots show Firefox; and the 2010 screenshot uses Opera (note that I still use Firefox, but in Windows).

It’s an interesting look at my Linux desktop environment over the years. One thing is how font handling has improved over the years (note: The second 2007 and the 2008 screenshots show some experiments I did with font design); the wordprocessor in one of the 1996 screenshots as well as both 2002 screenshots show how ugly fonts used to look in Linux; for the 2010 screenshot I finally threw in the towel and use Verdana as my only proportional font, along with having full True Type delta hinting enabled. Another thing is how resolution has slowly been increasing over the years; my 1995-1998 screenshots show an 800x600 display with 256 colors; my 1999-2007 screenshots are 1024x768 with high (65536) color, and my most recent screenshots are 1280x800 with 24-bit true color.

Links to the screenshots along with, in some cases, descriptions and configuration files, are available here:

http://samiam.org/screenshots/

New Deadwood snapshot

Progress made on dwx_remake_complete_reply(), which will take a packet as stored in Deadwood's cache, remove any DNS RRs which are not used for answering the original DNS question, and create a trimmed packet. Next: Finish the dwx_copy_over_section() code.

New Deadwood snapshot

dwx_make_ns_refer() implemented; this creates a string stored in the cache for an incomplete NS referral.

Next: Code for taking a complete cached string and making one with all unneeded records removed.

New Deadwood snapshot

dwx_make_cname_refer() implemented; this creates a string stored in the cache for an incomplete CNAME referral.

Next: Functions to create a string in the cache for incomplete NS referrals.

It’s, as always, here:

http://maradns.org/deadwood/

And another snapshot for today

Bug fix (which should be applied to stable 2.5 branch of Deadwood): Compression code had incorrect RDLENGTH in decompressed packet when the first packet had a DNS label that wasn't a compression pointer.

This actually doesn't cause any problems in Deadwood 2.4/2.5 because the RDLENGTH has the correct value again when we recompress the string before sending it over the wire (see dwc_compress_rr() where it says dw_put_u16(c,c->len - rdold,rdold - 2);), but it's best to fix this bug.

Also, dwx_stdout_dns_packet() implemented; this will allow Deadwood to be run thusly when there's a DNS name Deadwood is having a hard time resolving correctly:

Deadwood --solve www.poorly-done.dns.name.foo

The idea is to implement things so if Deadwood is run this way, it will interactively try and solve the DNS name in question, showing why it is we're having a hard time trying to resolve it.

New Deadwood snapshot

In today’s Deadwood snapshot, I have verified that dwx_determine_answer_type() correctly determines the type of DNS reply we got; I fixed a couple of bugs going through this process.

As always, it can be looked at here:

http://maradns.org/deadwood

Dillo 2.2: Return of the CSS hack

I have always had a soft spot for the Dillo web browser. It is the only graphical browser I was able to get to run on an old Gateway Handbook I have lurking around. Dillo is a browser which runs nicely on Windows 3.11 era machines while any other current browser plain simply does not run on a computer from that era.

About a week ago, Dillo 2.2 with limited CSS support has been released. Very limited CSS support.

Any web designer from the first decade of the 2000s remembers the days of the CSS hack. I remember designing a page from that era, having it look really nice in Mozilla (this was before Mozilla Firefox), but having the CSS make the site unusable in Netscape 4, forcing me to find a hack to hide the CSS from Netscape 4. For people who still care about Netscape 4 (but, really, you shouldn’t), the hack is /*/*/, which hides CSS from NN 4 until the next comment in the CSS.

Today, a lot of advanced CSS is not supported in Internet Explorer 6, which, despite Microsoft and web designers’ best efforts, is still used by 20% of the browser audience. Fortunately, the CSS hacks (there are various) for hiding content from IE6 are well-known; my usual hack is the !important hack for having IE6 see one set of CSS commands and web standard compliant browsers see another set of CSS commands.

Thankfully, the “zoo decade” (the first decade of the 2000s) is over, and the only browsers with significant market share that doesn’t pass the Acid 2 test are older versions of Internet Explorer. Everything else out there is standards compliant.

Well, everything else except Dillo 2.2. While Dillo supports a little CSS, it is no where near standards compliant. Click here for a screenshot of Dillo 2.2 rendering the Acid 2 test.

Dillo 2.2 is starting to support CSS. Indeed, my pages with CSS look a lot better with the very limited CSS Dillo 2.2 supports than with no CSS at all (my hacks for hiding the CSS from Netscape 4 are still in place). However, since Dillo 2.2 has very limited CSS support, I am having to do a CSS hack to hide the CSS which looks bad in Dillo: @media all {. You can see how I use this hack to hide the CSS from Dillo in this CSS.

Hopefully, the Dillo developers will not make this hack stop working until the Acid2 test gives us a smiling face in Dillo’s CSS renderer.

New Deadwood snapshot

In today's Deadwood snapshot, I have implemented dwx_determine_answer_type(), which does some simple heuristics to determine what kind of DN packet we got (answer, negative answer, incomplete CNAME referral, NS referral, error, or no useful data).

Civilization V announced

Fans of turn-based strategy games will be very pleased to hear that Civilization V has been announced.

Its most significant new feature will be using a hex grid. This is an interesting divergence from a square grid but reduces the error in land movement from 40% to only 15% or so. I recently discussed this on C-evo’s forum. There are three different ways Civilization clones have grids:

• A square grid, with diagonal movement costing as much as horizontal or vertical movement. Most Civilization games do things this way.
• A hexagonal grid, with movement in the six directions having the same cost. FreeCiv has had support for this for many years. East-west movement is 15% slower than north-south movement (or vice versa)
• A square grid where diagonal moves cost more than horizontal and vertical moves. C-evo does this: A diagonal move costs 1.5 as much as a horizontal or vertical move. No, any fractional move left over at the end of a turn does not roll over for one’s next turn.

Update: There is an official website at http://www.civilization5.com/

New Deadwood snapshot

In today’s snapshot of Deadwood, I have added (but not tested) a function called dwx_get_1_dns_rr(): Given a dw_str object (dw_str: Deadwood string), and a offset where we start looking in that string where a DNS packet starts, we get a single DNS rr from the DNS packet.

This will be used as part of the code which, when given a DNS packet received from the remote server, returns a DNS packet which will be stored in Deadwood’s cache, either as a complete or incomplete DNS reply.

In addition, once recursion is complete enough for me to make releases, I will make them first as 2.6 releases, then as 2.9 (3.0 release candidate) releases, and finally as 3.0 releases. 2.5 I will keep around; having dnswall functionality, not to mention a source code release complete with TCC to compile Deadwood quickly and easily in Windows, is useful enough to have a stable branch with these features added.

It can be downloaded here:

http://maradns.org/deadwood/

How Deadwood will store the referral types

As I mentioned in my last Deadwood blog entry, I will create some new types so Deadwood better supports recursion. Types 0, 1, and 2 (“complete” DNS answers; in other words answers that can be sent to a stub resolver) will be stored in the same manner Deadwood 2.4 stores them (the DNS packet, a list of offsets of the records in the packet, AN/NS/AR counts, and finally the “type” byte).

However, CNAME referrals (type 17 replies) and NS referrals (type 16) will be stored somewhat differently. A CNAME referral will be stored as a list of DNAME records in the following format:

{length}{DNAME}

{length} will be a signed 16-bit integer. {DNAME} will be a raw DNS name (samiam.org will be \x06samiam\x03org\x00). After this list, we will have the following three bytes

{final offset}\0x11

The final offset will be an unsigned 16-bit integer with a pointer to the beginning of the final DNAME entry.

A NS referral will be stored as follows:

{type (A, AAAA, or name)}{data}

Type will be an eight-bit number which can be either A (1), AAAA (2), or name (3). The type determines the data; an A NS referral is a 4-byte IPv4 IP, an AAAA NS referral is a 16-byte IPv6 IP, and a “name” type will be a DNAME with the glueless NS referral.

After all of the NS referral, we will have a list of unsigned 16-bit offsets pointing to the NS referrals in the string, followed by a signed 8-bit number with the number of NS referrals (Deadwood ignores NS records after the first 16 records), followed by the \x10 byte indicating that this record is a NS referral.

ObHack Windows zipfile fixed

I haven't used the program to make .zip files in *NIX in a while, and its command line parameters can be a bit confusing (the correct way to make a zipfile is zip -r ObHack-win-006.8.zip ObHack-win-006.8, with that '-r' being lower case; the manpage incorrectly states that you can do it as zip -r ObHack-win-006.8 ObHack-win-006.8 but that doesn't actually work); as a consequence, the zipfile had a single invisible file with the name .zip in it.

I have remade the zipfile and uploaded it to the ObHack webpage.

ObHack 006.8 released

Fritz has released ObHack 006.8, a random map generator for Doom and Heretic, today. It can be downloaded here:

http://samiam.org/slump/

Support for ObHack is in this forum:

http://www.doomworld.com/vb/doom-editing/

Some more thoughts on Deadwood’s “Type”

I’ve been thinking some more about Deadwood’s type byte, which I discussed in the last blog entry. The reason why the only thing the type byte notes is whether the NXDOMAIN bit is set is because, when I was making Deadwood a simple DNS cache that treats DNS data, as much as possible, like a “black box”.

For a caching-only DNS program, we don’t care what’s in the packet except to decide how long to cache it. We only used the type byte because it was the only place I could store the NXDOMAIN bit in the header.

There’s a lot of confusion about the NXDOMAIN bit, and, as DJB has pointed out, a lot of naive DNS implementations get it wrong. The NXDOMAIN bit in the DNS header indicates that not only isn’t there a DNS entry for this name with this record type, there is no DNS entry for this name for any record type. You can also have a simple DNS “not there” reply, which is a DNS record without the NXDOMAIN bit set, but in the format of a NXDOMAIN: No answer in the AN section, and a SOA record in the NS section.

So, in reality, we have positive DNS answers, and we have two types of negative DNS answers: “Not there” DNS replies, and NXDOMAINs.

Deadwood currently treats “not there” and positive answer DNS replies the same: Both DNS replies are passed as-is on to the client. They are both type 0 (answer to pass on to the client without setting the NXDOMAIN bit) replies.

Now that we are doing a deeper inspection of DNS packets, I would like to change that. I would like to have positive replies distinguished from non-NXDOMAIN “not there” replies, and require a reply with the NXDOMAIN bit set to be, in fact, a NXDOMAIN reply.

So, my revised list of types:

• Type 0: Positive answer
• Type 1: NXDOMAIN negative reply
• Type 2: Non-NXDOMAIN negative reply
• Type 16: NS referral
• Type 17: CNAME referral
• Type 18: All known servers timed out last time we tried to get this data

The reason for the revised numbering scheme is that I would like types 0-15 to be set aside for replies we pass on to the client, with 16-31 used for data which means we have to do more work to find an answer. Type 18 will let us know to be more patient with the servers (maybe they’re just really flaky), and even allows there to be framework to have Deadwood periodically try to contact these servers just in case it’s a case of the servers being offline whenever the admin unplugs the server to plug in the fridge to cool down the beer (note: I’ll probably not implement this).

The format of packets in the cache

The last byte of a cache entry for Deadwood is a single “type” byte (also called “is_nxdomain” in the source code). This is an unsigned 8-bit value; right now only two values are used for this:

• 0, which indicates that it is a complete answer to our DNS question, and the NXDOMAIN bit in the header is not set (NXDOMAIN means “thisf host does not exist for any record type”)
• 1, which indicates that it is a complete answer to our DNS question, with the NXDOMAIN bit in the header set to 1 (which means, but Deadwood won’t use this, that no other host names exist for this query)

With eight bits to play with there, we can use this type to indicate various records which, while not complete DNS answers, are useful for a recursive DNS server

• Have type 2, which is a NS referral. A NS referral can be any combination of glued and glueless NS records. NS records with A or AAAA (IPv4 or IPv6) glue that we can use is converted in to the A and AAAA addresses we get from the glue records; NS records without glue are kept only as names (speaking of glueless, I am a pretty hard critic of DJB, but I am glad we got A6 and DNAME killed)
• Have type 3, which is an incomplete CNAME referral; this thing can be a CNAME chain if the upstream server gave us a CNAME chain

I will discuss the binary format of type 2 (NS referral) and type 3 (CNAME referral) records in a future blog.

I do not support ObHack

I no longer maintain and do not support ObHack, some hacks I did for a Doom random map generator until a couple of years ago. To get support for ObHack, go to this location:

http://www.doomworld.com/vb/doom-editing/

and look for the most recent thread about ObHack. You may have to go back a page or two (click on the small link marked “>>”) to find the most recent ObHack thread.

Right now, the last poster to post about ObHack was Fritz, the maintainer. He is doing a a good job maintaining and updating ObHack, and can best handle your concerns.

MaraDNS snapshot

Looking at the MaraDNS web page, I realized that the date for the last MaraDNS was out of date. Fixed, both on the webpage and in today’s snapshot of MaraDNS:

http://maradns.org/download/1.4/snap/201002/

New Deadwood snapshot: Bailiwick check done

Yes, I am getting married this week. However, I was able to get a little time to devote to Deadwood, and have just made a new Deadwood snapshot. In today’s snapshot, I have taken all of the Bailiwick checking code I wrote last week and have integrated it with the rest of the code which scans a DNS packet.

Right now, the DNS packet scanning does the following:

• It looks at the AN (answer) section of the DNS reply. Anything that is not either a direct answer to our query or part of a CNAME chain leading up to our answer is marked “RRX_IGNORE”.
• If there are any records in the AN section of the DNS reply, we mark as “RRX_IGNORE” all records in the NS and AR section of the DNS reply
• If there is no answer (AN) section, we look at the NS and AR sections
• We verify that all NS records are in-Bailiwick (as described in previous blog entries)
• We then look at records in the AR (glue records) section; any IPv4 and IPv6 records are compared to NS referrals in the NS section; if a given glue record corresponds to a NS record, we mark the glue record as “Glue for NS record number X”, where X is a number from 1 to 16 (we only support the first 16 NS records), and note that the NS record in question has IPv4 or IPv6 glue
• At this point, all NS records are marked as being either out of bailiwick, glueless, with only IPv4 glue, with only IPv6 glue, or with both IPv4 and IPv6 glue

Next: Based on this information we have gotten, figure out what to do next (whether we have our answer, whether this is a CNAME referral, or give the list of NS server to go to, either as glueless records or as a list of IPs).

Timeline: I’m getting married Friday, guys.

A look at free Windows POP3 mail clients

I am in the process of looking for a free (beer) Windows POP3 mail client. Poking around, here is what I found:

• Mozilla Thunderbird
• Eudora, but the Wikipedia claims Eudora is moving to using Thunderbird
• Pegasus Mail has been around for a while; no source code
• Opera includes an email client
• There is a fork of Firefox called “Seamonkey” that includes a POP3 email client
• gpg4win is a port of the Linux Balsa email client for Windows (also includes GPG for signing and encrypting email)
• Mulberry is another email client
• For people who want the old-school UNIX feel, there is Pine which is now called “Alpine” and, yes, there is a full Windows port

I’m done with chess variants

Taking chess too seriously

Years ago, I went to a local club where I would meet people and hang out with friends. Among other things, we have a couple of cheap $5 chessboards like what you buy at Wal*Mart and Target and people would sometimes play chess at this club.

Tired of getting my butt kicked all the time at this club, I bought some chess books, started studying them, and looked up and joined a local US Chess Federation club with stronger players. Pretty soon, I had very strong chess players teaching me how to correctly develop my pieces and I was winning instead of losing games at that local club where people played casual chess games.

One time, while playing a game at the local club, there was a position where I was winning the game and my opponent (who beat me countless times before I learned how to move at that USCF club) made a move where my best reply was to capture his pawn using an unusual move called “En Passant”. Well, since he was a casual player, he didn't know about this rule. We ended up having an argument over it and ending the game over the argument.

Looking back, I was in the wrong. Yes, at the local USCF club, any tournament director would have told him that en passant was legal and forced him to accept the move. But, we weren't at the USCF tournament. We were at a local club hanging out and playing a casual game of chess. I was taking the game of Chess far to seriously at this point and didn't get a chance to finish a game I was winning because I was acting in a manner appropriate for the local USCF club but inappropriate for a friendly Chess game.

Well, once I was able to beat all of my buddies who used to kick my butt at the casual club, I realized that Chess was only a game and I was working too hard to get good at something without any real-world use. I started concentrating on improving my computer skills instead and soon had a good job in the computer industry. I also let my USCF membership lapse.

Chess Variants

It was around this time that I got interested in Chess variants (ways of changing the rules of Chess). I was studying the opening in regular Chess, and it really amazed me how people went to so much effort trying to evaluate a move in the opening, but I was disappointed in how they only looked at the opening of one game, when regular Chess is a subset of an infinite number of possible Chess games.

What I really wanted to see was people start studying the opening in depth of a different Chess game; once people felt that opening was studied, I wanted to see people study the opening of yet another chess variant. The Chess we know is just one grain of sand in the infinite beach of possible Chess games, and I wanted to see more of the beach explored.

This wish finally became last last couple of years possible because of some programs made or hacked by a talented programmer by the name of H.G. Muller. I was able to use his software to play tens of thousands of my single contribution to the world of Chess variants (which, ironically enough, is one of the relatively few Chess variants to be mentioned in the Wikipedia, albeit as a single one-line mention). After studying the opening, I realized that Schoolbook Chess (my one Chess variant) was a bit unbalanced in favor of white, but my research also showed another similar setup is a more balanced game, with white only having a very slight advantage.

Once I was finally able to do this research, my interest in Chess variants waned. I realized that the infinity of possibilities only exists in the abstract. Most Chess players will be perfectly content playing only regular Chess for the rest of their life; the very few people who are open to playing variants haven't played a single given game enough to make studying its opening worthwhile or even feasible in any manner besides using computer simulations. One community, looks at a given variant, plays at most a dozen games with the variant, and moves on to the next variant.

Chess bores me

I realized, while doing this opening research, that the results of opening research bore me, as well as actually playing a Chess variant. I just don't enjoy Chess any more. It was only a fun game for me in the context of that club many moons ago and having something to do with my buddies. It hasn't been a fun game for me for over a decade, when my last casual buddy got sick and tired of me beating him all of the time.

The only thing about Chess variants that interests me today is studying the opening and developing opening theory. Even that is not too interesting; I seem to be the only person in the world who likes the idea of studying a Chess variant's opening in any amount of detail.

In addition, there isn't anyone out there who appreciates the effort I went in researching my one chess variant. So, not only is it no fun, but there isn't any demand for the work I did researching chess variants.

It's time to move on. That in mind, not only will I no longer visit Chess-Variant related web sites, I have deleted my webpage with all of my Schoolbook-related files (A chess variant I invented). I'm keeping the ChessV webpage around, for the simple reason that, if I delete this webpage, Greg's ChessV program will no longer be available on the internet, and there has been interest in this program.

Actually, I wish someone else would offer to host ChessV so I can let go of it too, but I can host it until we find another host.

New Deadwood snapshot: Bailiwick check code

I’ve finished (but have not tested) the core routines to make sure a NS referral we get is in bailiwick. Next: add the glue to integrate this in to the code that processes a remote DNS reply and test things to make sure it works.

I may (but probably won’t) have time to do this early next week; don’t be surprised if I can’t make another Deadwood update for a couple of weeks. My personal life is pretty busy right now, for the exact same reason CentOS 5.3 was delayed—I’m getting married next week.

I’ve disabled anonymous comments

I have disabled anonymous comments on this blog. Unfortunately, I am having to reject about one spam comment a day which post using anonymous identities. Even before the spammers came here, my experience has been that anonymous posters usually post something stupid or a flame; I just looked through my archive and have gotten about one useful anonymous comment in my three years of running this blog.

So, no more anonymous comments. If you want to comment here, get a Google or OpenID.

People's Tactics was written in Visual Basic

Looking at how People’s Tactics handles errors (by popping up a windows saying something like “Run time error ‘11’: Division by zero”), and seeing how slowly the program runs, I looked more closely at the code. Looking at the PeoplesTactics.exe binary, I discovered this string near the top: MSVBVM60.DLL. Yep, People’s Tactics was written in Visual Basic, which explains why the AI is so slow when trying to make its move.

The newer Advanced Tactics is written with a .NET language, probably VB.NET (since People’s Tactics was written in Visual Basic, I find it quite unlikely Vic decided to use C# instead for Advanced Tactics).

Also, yesterday’s hack to allow another set of rules to be used with People’s Tactics random maps results in crashes when trying to play with Civil War units. I’m not sure if other rules (such as WWI units) will also cause problems; my testing of a hacked form of the Banana Republic units for a random game, however, shows no problems.

Changing the random scenario in People’s Tactics

I discovered today that it is possible to change the random scenarios in the game People’s Tactics (scroll down and look in the sidebars to see the People’s Tactics download).

People’s tactics uses the scenario scenarios/2PL_Two_Rivers.pt1 to determine the type of units and other game rules for random scenarios; if you back up this file and then rename, say, 2PL_World_War_One.pt1 to have the name 2PL_Two_Rivers.pt1, random scenarios will now have World War I units (no tanks until this technology is purchased with political points, etc.).

Cool way of getting more variety out of People’s Tactics’ random scenarios.

New Deadwood snapshot

In today’s Deadwood snapshot, I’ve done half of the work with the bailiwick-checking code; I will do the other half either tonight or tomorrow.

It can be downloaded here:

http://maradns.org/deadwood/snap/

As an aside, the format for Deadwood snapshots is Deadwood-H-YYYYMMDD-N.tar.bz2

Here, “H” stands for “Head” (there is also the occasional “Deadwood-S-... snapshot where “S” stands for “Stable”), “YYYY” is the year (2010), “MM” is the month, “DD” is the day, and “N” is the release number for that day (usually 1, but sometimes I release two or three Deadwood snapshots on a given day).

There is no such thing as a perfectly secure program

Back in 2007, I posted this criticism of DjbDNS on their mailing list. As you can imagine, the people on the mailing list were not happy.

What has changed with DjbDNS since I wrote this criticism:

• DjbDNS has finally been made open-source
• Three security holes have been discovered in DjbDNS
• The DjbDNS tarball on the official download page is still the outdated 1.05 version of DjbDNS

I can not help but observe that, ever since those three security holes have been discovered in DjbDNS, DJB advocates have been a lot more quiet about how ultra-secure DjbDNS is.

In comparison, MaraDNS has had 12 security problems in its near-decade of existence. OK, so I have four security problems for every security problem DjbDNS has. Then again, of those 12 holes:

• Four were only in unstable development releases of MaraDNS
• One was caused by broken behavior in the Linux kernel and not by MaraDNS
• Two were patches against theoretical problems in AES that do not have any real-world exploits
• The remaining five problems only allowed an attacker to perform a denial of service against MaraDNS; the one I patched yesterday only works in the unusual case of an attacker being able to give MaraDNS a csv2 zone file

To make this an apples-to-apples comparison, there have only been five practically exploitable security problems in stable releases of MaraDNS caused by my own coding errors. None of them have been worse than denial of service.

I should also point out the hole I patched yesterday only exists because I decided it was good to have a more attractive zone file format for MaraDNS.

The idea that there exists an uber-genius programmer who can magically make code without any security problems that never needs to be updated was a myth DJB advocates liked to present in the first decade of the 2000s. This is nothing more than a myth, shattered by the three security holes people have discovered in DJBdns (not to mention the backscatter spam problem in Qmail, which is a security problem).

Security is a process. Programmers, no matter how experienced or skilled, make errors. To criticize a programmer for making a mistake is unreasonable and unrealistic. The best we can do is make a program with a coding style that minimizes security problems; considering that MaraDNS has had only four (maybe five) practically exploitable security problems in stable releases is a very good record.

If you want security, you want to use a program that the programmer stands behind and continues to support. Which is what I have been doing with MaraDNS for nearly a decade and which I have no plans to stop doing.

MaraDNS 1.4.03 and 1.3.07.10 released

I have released MaraDNS 1.4.03 and 1.3.07.10 today. This fixes a minor security issue.

There was a bug introduced in MaraDNS 1.3.03 (January 2007): Hostnames that incorrectly not end with a dot result in a string being deallocated then used.

MaraDNS 1.2 does not have this issue.

This issue can not be exploited from zones loaded using DNS's zone transfer mechanism; fetchzone filters data obtained this way. This issue can only be exploited in the unusual case of an attacker having control of the contents of a csv2 zone file to be parsed by MaraDNS.

This issue, on Linux systems, results in a null pointer dereference that terminates that MaraDNS process.

Impact: Denial of service

This issue is now fixed in MaraDNS 1.4.03 and 1.3.07.10, released February 2, 2010. I have already talked with the relevant people at Debian, who feel this bug is not serious enough to warrant a new stable release of MaraDNS in the Debian repositories.

The updated files can be downloaded here:

http://www.maradns.org/download.html

Next: Upload MaraDNS 1.4.03 to Sourceforge (Update: Done)

Note also that MaraDNS 1.4.03 documents the reject_aaaa/ptr parameters, as posted to the blog yesterday.

New MaraDNS snapshot

I have finally documented the reject_aaaa and reject_ptr features which I added back in 2003, to work around the annoying DNS lookups some *NIX programs do.

I'll probably end up adding this feature to Deadwood.

It can be downloaded here:

http://maradns.org/download/1.4/snap/201002

- Sam