Yes, open source is a win-win

Open source is a win-win.

I am very pleased to let the MaraDNS community know that I have successfully gotten a job offer which I just accepted this week. This is a job offer which I would not have gotten if I had not kept my skills current while living in Mexico by continuing to develop MaraDNS, culminating with a three-year-long complete rewrite of the recursive code.

The timing for getting this offer is perfect. As I planned to do a year ago, now that MaraDNS 2.0 is out the door, I will put MaraDNS on the back burner. This will give me more time to be a productive worker at my new job and refine my programming knowledge to master new technologies, keeping my skills current in the 2010s.

I am going to continue to support MaraDNS, of course. I will fix important bugs brought up on the mailing list, and will naturally fix any critical security bug that may be found in MaraDNS. I will also answer emails on the mailing list when and if I have time to do so. But, I do not have any plans to add new features to MaraDNS at this time.

I would like to thank all MaraDNS users for all of your comments, feedback, bug reports, and feature requests. I have devoted a lot of the last decade to MaraDNS, and it has been an honor to freely give to the world something which I hope people find useful.

Open source development truly pays off. It’s a win for users, since they have good code which they can change any way they see fit; it’s a win for developers, because it allows them to showcase their work and demonstrate their programming discipline to prospective employers. I encourage people who are looking to improve their programming skills to become part of an open-source project. It can be frustrating at times; but it is also rewarding.

Deadwood 3.0.01 released

I have released Deadwood 3.0.01 today. With this release made, no new features will be added to the Deadwood recursive resolver for the foreseeable future. However, bug fixes and other routine maintenance will still be applied to this software package.

Deadwood is now a stable recursive resolver suitable for embedded systems, desktop PCs, or on internet servers. Deadwood is fully 64-bit compatible, has optional support for IPv6, and does not require threads to resolve records.

Deadwood 3.0.01 will be the recursive resolver for MaraDNS 2.0, which I will release shortly, as well as being an optional recursive DNS server to use in MaraDNS 1.4.

It has been a pleasure developing Deadwood and MaraDNS for nearly a decade. I will continue to support MaraDNS and Deadwood but have no plans to add new features once MaraDNS 2.0 is released.

In addition, I no longer need to accept donations for MaraDNS. All Deadwood and MaraDNS support needs to be done via the MaraDNS mailing list.

The 3.0.01 release of Deadwood is available here:

http://maradns.org/deadwood/stable/

MaraDNS 1.9: Moving towards MaraDNS 2.0

I have made the changes to MaraDNS’ codebase to prepare her for the MaraDNS 2.0 release. The changes are (drum roll) pretty simple, actually: I have gone through all of the #ifdef AUTHONLY statements to either keep them as AUTHONLY statements, or to change them to #ifdef IPV6 for statements which enable IPv6 support (MaraDNS 1 has no recursive IPv6 support, so AUTHONLY is also used to enable IPv6).

The only other change I have done is to revise the build scripts to:

• Always define AUTHONLY when compiling MaraDNS
• Update the configure script and Makefiles to allow one to enable or disable IPv6
• Not link MaraDNS to the pthreads library (MaraDNS 2.0 will be thread-free)
• Compile Deadwood as MaraDNS 2.0’s recursive resolver
• I removed makefiles for all operating systems besides Linux, Windows, and a generic *NIX “noflock” makefile

It can be looked at here:

http://maradns.org/download/1.9/

At this point, the code for both MaraDNS 2.0 and Deadwood 3.0 (the recursive resolver MaraDNS will have) are done: The only changes will be bug fixes. The thing I should do at this point is revise MaraDNS’ documentation to reflect the MaraDNS 2.0 changes, as well as removing any MaraDNS 1 SQA tests that test MaraDNS’ recursor.

One issue MaraDNS 2.0 will have is that the recursive resolver will require a separate IP, and that there isn’t an automated way to convert a MaraDNS 1 mararc file in to a MaraDNS 2 mararc file and Deadwood 3 dwood3rc file. This in mind, I have no plans to stop supporting MaraDNS 1.4 for critical security fixes and other important bugfixes and updates (such as updating the default list of root nameservers) for the foreseeable future, as well as supporting MaraDNS 2.0 for “this host does not resolve” bugs, as well as other bug fixes.

Where is the money?

This job market is scary

Sometimes, in the middle of the night, I just wake up and I can’t sleep anymore. I wonder if I am going to be able to re-enter the technology field or if I’m just going to end up teaching ESL for the rest of my life.

How MaraDNS came in to being

About a decade ago, everything was right. I had a well-paying promising contract with a major software company. I was making far more money than I knew what to do with. The work environment was fun and there was no limit with where I could take my career.

I was miserable.

It didn’t help that the girl I was dating at the time was not working out. When I finally let her go—she still owes me $312.98 for the record—I could not for love or money get a decent date. Having to commute for an hour followed by working eight hours followed by another hour coming back home five times a week doesn’t leave me much time to be part of the singles scene.

Something had to change.

The last job I had in technology before the dot-com bubble popped was for an internationalization firm. I met a lot of people from a lot of countries speaking a lot of languages. This revived my long-dormant interest in learning Spanish. Once that company died when the dot-com party ended, I went down to Mexico for a few months to learn Spanish.

It was a life-changing experience. I instantly went from being a guy who couldn’t get a decent date to save my life to someone who had this beautiful girl in my bed passionately making out with me. While things sadly didn’t work out with her, I discovered a world where I was no longer isolated and miserable. I had found home.

Of course, I wasn’t going to put my technical skills to waste. No, I wanted to make a name for myself and MaraDNS was already well underway when I was still working in the dot-com industry. It ignited my passion because here was something that wasn’t going to get forgotten when the company I worked for got bought out two times. It was my chance to make my mark on the world.

And, indeed, it has. You do a Google search of my name and MaraDNS is the third link that pops up. It has a Wikipedia entry. Indeed, MaraDNS is notable enough that the entry can not be easily deleted by the kinds of Wikipedia editors hell-bent on removing anything they can from the Wikipedia [1], because it has been used by a number of people and mentioned in books, in the title of a ZDnet article, as well as a number of scholarly papers.

After over a year of hard work, I released MaraDNS 1.0 on June 21, 2002. Then I went back to college and put MaraDNS on the back burner. Sure, I fixed bugs, but with all of my studies, and with adjusting to living in a far more conservative town than where I lived before (something I never fully adjusted to, quite frankly), I put MaraDNS on the back burner, sometimes going as long as half a year without updating it. Even back then, I wanted to rewrite MaraDNS’ recursive code, but just didn’t have time to do it.

As things were winding down with college and I was getting accustomed to life in that town, I was able to devote some time to improving the authoritative half of MaraDNS, including adding non-recursive IPv6 support to MaraDNS and improving its zone file format. This culminated with MaraDNS 1.2 being released in late 2005, a few months after I graduated from college. I then made some minor revisions to the zone file format to make it possible to write a Python script to convert BIND zone files in to MaraDNS zone files; that resulted in the 1.3 release a year after 1.2 was released.

It was between the 1.2 and 1.3 releases that I decided it was more important to go back to Mexico to improve my personal relationships than to try and get a job in the computer industry again. I had two notable rejections because I didn’t know more about C++ and objected-oriented programming, from both Google and a startup in southern California, and ended up briefly working as a cashier in Wal*Mart before throwing in the towel and going back to Mexico.

While dating girls down in Mexico, not only did I get a Python script to convert BIND zone files to MaraDNS zone files done, I finally started work on rewriting the recursive engine, something I had wanted to do for years. I started writing Deadwood in late 2007, with me planning to have a standalone recursive DNS daemon finished in mid-2008.

That didn’t happen. I had the fully non-recursive cache finished by late 2007, but then realized I had to concentrate more strongly on dating to have the right girl in my life in 2008.

It was while dating in 2008 that I started realizing the needs to put boundaries on MaraDNS support and start looking in to getting compensated for my hard work. Private email support was getting backlogged, so I finally had to let people know I would not support MaraDNS via private email without being paid for my time. People who appreciated MaraDNS started paying me a little in the tip jar I set up or by paying me a token sum for me to implement a feature they wanted in MaraDNS.

I had lost a lot of my free-software ideals at this point. I believed in 2000 that the year of the Linux desktop would happen. In 2004, I got off my high horse and started dual-booting in to Windows. In 2008, I got rid of my Linux partition altogether and started using Windows with Cygwin and a VMware virtual machine for the occasional Deadwood development I did that year. As I started developing Deadwood again, I tried putting Linux on my computer and liked it so little that I stabilized on the current setup I have for Deadwood development: Windows XP as my primary desktop OS, along with a CentOS 5 virtual machine which I use to develop Deadwood.

While this was going on, I found the girl who is today my wife in late 2008, and then had both a setup in place and some more free time to devote to working on Deadwood in 2009.

After getting most of the underlying support for having a fully recursive nameserver done (DNS compression support, integrated DNS-over-TCP support, full mararc dictionary variable and “execfile” support, “ip_blacklist” support, inflight merging, etc.), things with my girlfriend got serious and she became my fiancée. With marriage looming on the horizon, I grew up and realized it was time to make a roadmap to put closure on MaraDNS.

I was, when I made that decision, close enough to having Deadwood be fully recursive that I made Deadwood’s full recursion the point when I would declare MaraDNS done. I started work on Deadwood again in early 2010, and finally had full recursion finished in late July of 2010.

So, yeah, MaraDNS is finished. This doesn’t mean I am never going to make another release of MaraDNS. MaraDNS 2.0 is simply going to be MaraDNS 1.4 with the old recursive code thrown out, replaced by Deadwood being integrated in to the build script.

I will also update the documentation telling people how to update from MaraDNS to Deadwood. This will have to be done by hand; in order to ease the transition, I will support both MaraDNS 1.4 and 2.0 with security and other critical bug fixes for the foreseeable future. I also have no plans to stop fixing “this host does not resolve with Deadwood” bugs.

In addition, I am getting some minor sponsorship for MaraDNS, and will consider implementing features my sponsors want to implement. The only other thing I might do is add some more extensive SQA tests to test for bugs in fully recursive Deadwood (I currently only have one that tests one kind of recursive query).

Back to reality

So, yes, MaraDNS is finished. Time to get back to reality. I have been spending the last couple of weeks, along with fixing bugs in Deadwood, learning about a lot of new technologies. I have a mid-1990s book on Object Oriented programming I have almost finished (inheritance, both single and multiple, abstract classes, throwing and catching exceptions, a bit on C++ templates).

I had a phone screen for, of all things, a Javascript position yesterday. The position didn’t pan out: Even after spending all last weekend madly studying and learning Javascript, and explaining it is hardly the first scripting language I played with, my technical knowledge was not up to par with what they were looking for.

A good friend of mine told me last night I need to get more focused to get something in today’s job market. Since I have decades of C programming experience, and well over 60,000 lines of C code to show potential employers (MaraDNS), it makes the most sense to expand this with C++. There is the argument that it may make more sense for me to instead concentrate on Objective C, but the issue there is that I’m not a user of Apple’s products and don’t see too much money selling 99 cent iPhone toy applications.

I feel, if I improve my C++ programming, I will be able to get a good job, possibly with Google. Back during the dot-com days, I went to a lot of Linux User Group meetings where I met such people as Paul Vixie, Larry Wall, Linus Torvalds, RMS, as well as getting on a first-name basis with Chris DiBona. I think I will shoot Chris an email and see what ideas he has for me getting a stable corporate job.

I also have, bouncing around my head, a couple of ideas of how I can use the MaraDNS code to make a commercial product. I’m not sure how to develop the ideas and make a product from them, but I have already sent out a couple of emails to people who may have an idea how to start a business with them.

I’ve grown up. The 2000s were a good decade, since not only did I become fluent in the Spanish language and make my mark on the world with MaraDNS, an excellent high-security tiny embedded DNS server, I also found the woman who today is my wife.

There are some things I regret. I feel I spent too much time in the 2000s editing the Wikipedia, posting to Slashdot, making chess variants, or playing video games by myself; time I could have spent mastering C++ and being in a better position to get a job in the tech sector today. Indeed, I have a strict “no posts to Slashdot, no edits to the Wikipedia, and no chess variants” rule I made for myself so I can focus on the things I need to do to be a good husband for my wife.

So, yeah, even though everything seems scary right now and I wake up with these anxiety attacks when I bomb a phone screening like what happened yesterday, I know there is a good job out there for me for the 2010s that will support my wife and myself. I just have to keep trying, not give up, and not get upset every time I try and fail.

[1] A classic example of the internet dork rule. I find it rather fitting that the twit who tried to delete the MaraDNS article is not only completely anonymous (unlike my Wikipedia account which I haven’t used since March), but also is someone who has been blocked for rude Wikipedia behavior, something that hasn’t happen to me [2].

[2] Truth in reporting compels me to point out I once had a 24-hour block for violating something called the “three revert rule” back in 2005, when I thought it was worth wasting my time arguing with the kinds of people who like to pretend their kitchen is their own empire that they are the grand emperor for. Oh, how I wish I had spent the time I wasted arguing on the Wikipedia (and, yeah, /.) learning C++ or Java.

I am getting sponsorship for MaraDNS

I am letting people know that I am now getting regular sponsorship for MaraDNS. This means that, as long as the sponsorship continues, I will, contrary to the roadmap I placed in this blog entry, add new features to MaraDNS (as I said when I clarified my MaraDNS roadmap).

That’s the good news.

The bad news for the freetards is that the features I will add will be the features my sponsor wants me to add. They are not the features you want to add to MaraDNS—unless you’re willing to also sponsor MaraDNS.

Deadwood 2.6.02 released: Non-glueless recursion

Deadwood, after over two years since its initial release, is finally starting to have support for DNS recursion.

In the release of Deadwood, a subset of DNS names will recursively resolve: Names that do not require glueless NS records to be solved or incomplete CNAME records to be finished.

Here is my current roadmap for Deadwood:

• Add support for solving glueless NS records (This will be 2.6.03)
• Add support for finishing incomplete CNAME referrals (This will be 2.6.04)
• Add support for ANY records — have it so the “in bailiwick” tester understands any RR type is OK when an “ANY“ record is asked for (This will be 2.9.01 — the first feature-complete recursive release for testing)

As always:

http://maradns.org/deadwood/

Look in the “testing” directory for Deadwood 2.6.02; look in the “TCC” directory for the source code for the Tiny C Compiler the deadwood-tcc release uses.

Deadwood: Revising the hash structure

Currently, the upstream DNS servers are stored in their own special hash. However, in order to implement full recursion, the upstream/root DNS servers need to be stored in the same hash cached entries are stored in.

However, there are some things different about upstream/root NS referrals in the hash:

• They will not be part of the file we store the offline cache in
• The entries will not be part of the queue we use to delete unused entries (and put stuff in the cache diskfile)
• It will not be possible to delete the entries once they are in the hash

My next task for Deadwood is to modify the hash structure to accommodate these “immutable” elements; after that, have upstream_servers and root_servers stored in the hash.

Next in Deadwood: Glued NS referrals

The next thing in Deadwood I will implement are glued NS referrals. Here is the general plan:

• If we get a NS referral upstream, make sure it is in bailiwick (actually, this bit of code has already been written).
• Store the NS referral in the cache.
• Then, make a new query to one of the NS servers, using the part of DNS space this NS record refers to as our new bailiwick.

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.

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.

Another MaraDNS wish list item

OK, I just got another MaraDNS wish list item:

• DNS that changes one's answer based on one's location (Geo DNS)

The answer is the same as for other MaraDNS wishlist items: No, unless you pay me to implement it.

The only things I plan on implementing for MaraDNS are full IPv6 support, full thread-free recursive DNS, full Windows service support for MaraDNS 2.0's recursive resolver (Deadwood), and good BIND zone file support (via a Python script which is mostly done). After all of this is done, I have no plans to implement new features for MaraDNS unless someone steps up to the plate and compensates me for my time.

Sorry, guys, I'm getting married in under three weeks and the married lifestyle is not compatible with the lifestyle of someone writing open source software "for fun and for free".

New MaraDNS snapshot

By mistake, when I made the new MaraDNS snapshot last Friday, I called MaraDNS Deadwood in the note about * characters in zone names terminating MaraDNS. Fixed.

It can be downloaded here:

http://www.maradns.org/download/1.3/snap/200912

My plan is to release MaraDNS 1.4.01 one week from today (December 21).

MaraDNS wish list status

Here is the status of various wish list items people have requested that MaraDNS have over the years:

• IPv6 (DONE, except for Deadwood's recursion)
• Multiple views -- DNS answers vary depending on the IP sending the request (won't do)
• SQL support (won't do)
• Include other files in mararc (done in Deadwood, won't do in MaraDNS)
• DNSSEC (won't do)
• Ability to dynamically load zone files (won't do)
• DNS curve (won't do)
• BIND zone file support (mostly done; will finish up)

Note that won't do means I won't implement the feature in question without being paid.

Deadwood short-term plans

Here are my short-term plans for Deadwood:

• There is a bug where dwood2rc files that don't end with a proper linefeed cause there to be a syntax error reported on the last line of the file. Fix.
• I have updated my development system from CentOS 5.3 to CentOS 5.4; the biggest change is that the current version of GCC is now GCC 4.4 instead of GCC 4.3; update the "no warnings when compiled with the latest GCC" test to use GCC 4.4, and fix any compile-time warnings found. This needs to be done for both the 2.3 and 2.4 branches of Deadwood.
• Do full SQA recressions, then release Deadwood 2.3.05 and Deadwood 2.4.08

MaraDNS thoughts

I was having a private conversation on the internet with someone who has helped MaraDNS a lot over the years. I told them the following when I mentioned MaraDNS’ future:

I do plan on finishing up MaraDNS 2.0, which should have full ipv6 support, better recursive resolving, and then I plan on finishing up that Python script that converts BIND zone files in to MaraDNS “csv2” zone files. The csv2 zone files already have support for pretty much anything you would see in a BIND zone file; it’s just a matter of finishing up the Python script.

I don’t know when I’ll go back to working on that code, however. Other things are more important. Namely: I need to become really familiar with OO programming to stay competitive in today’s job market. I don’t plan on spending the rest of my life working in an exotic Latin country babysitting Windows computers earning only pennies on the dollar.

Poking around with Google, in addition to finding a lot of really positive things said on Slashdot about MaraDNS (thank you everyone for your kind words), I found a couple of Slashdot comments asking for full IPv6 support; one of the comments asks for BIND zone file support.

MaraDNS right now has full authoritative-only IPv6 support; zone files have native support for AAAA records and, if MaraDNS is compiled without recursion enabled, MaraDNS can bind to and listen on IPv6 sockets. Deadwood, which will some day become MaraDNS’ recursive resolver, has full IPv6 support today for non-recursive DNS queries, and I fully plan on adding full IPv6 recursive support.

I also have been working on and off for years adding BIND zone file support to MaraDNS. I have made a lot of revisions to MaraDNS’ “csv2” zone format to make it easier to convert BIND zones to MaraDNS zone files; I have a Python script that converts BIND zone files to MaraDNS zone files, but the script is incomplete and there’s a lot of corner cases it doesn’t cover. One of my goals is to finish up that script, minimize the corner cases and give MaraDNS good BIND zone file support.

“Plan” being the operative word here. I really need to update my software development skills for the 21st century, and that means mastering OO programming. My beautiful girlfriend has become my beautiful fiancée—I need to do what it takes to get a job making a living wage like I was making during the dot-com boom again. And, sorry, but making people on Slashdot happy doesn’t pay the bills.

Clarification about MaraDNS roadmap

Since some anonymous freetard responded to my last blog entry by trying to put some BS on the MaraDNS Wikipedia entry, let me clarify my roadmap:

• I have no plans to quit working on MaraDNS. “Quit working” implies I will no longer fix bugs or answer email on the list. This is false.
• My current plan is to continue to fix bugs after the 2.0 release of MaraDNS. I plan on continuing to fix bugs in 2.0 and the upcoming 1.4 release of MaraDNS for the foreseeable future.
• I will continue to monitor the mailing list and answer questions I deem appropriate to answer.
• I will still provide for-pay private email support for MaraDNS
• I will still add features to MaraDNS that people are willing to sponsor

Now, let me give you guys a rant about freetards. A freetard is someone who expects something for nothing. They feel they have an entitled right to download pirated software and media, and that companies who try to protect their intellectual property are somehow in the wrong (or that intellectual property should not exist). They feel they are entitled to free private email MaraDNS support (I get about one idiot like this a month) even though I make it clear I don’t provide this kind of support. They feel I should spend my free time writing MaraDNS “for fun and for free” and try to put untrue negative statements about MaraDNS on the Wikipedia if I don’t give them something they think they are entitled to.

One of the biggest hassles developing MaraDNS is the number of freetards out there. People who don’t lift a finger to help make MaraDNS a better server, but expect me to waste time answering their email asking for the same feature 10 other freetards have already asked for. People whose net contribution to MaraDNS has been to annoy me.

About a month ago, I had an interesting discussion on Slashdot about user’s expectations for open-source software. The conclusion: Many users of open-source software expect to be treated like customers, but are unwilling to pay a single dime for open-source software.

Bottom line: If you want to be treated like a customer of MaraDNS, you first must become a customer of MaraDNS. If you make a modest donation to MaraDNS, I will be happy to answer your email; the charge, for the record, is US $50 per private email support incident, more if I need to add a feature to MaraDNS to resolve your concern.

If you want to be a freetard and send me a private email, I’ll spend about 10 seconds scanning your email to make sure you didn’t make a donation, then send you the “Show me the money” form reply. Yes, this includes bug reports. Yes, this includes feature requests. Yes, this includes whatever discussion you want to have with me about MaraDNS in private email. All of this belongs on the list, not in my personal mailbox—unless you include a check in your email.

An open source developer grows up

A lot of open-source forums are full of naive and innocent people. People who honestly believe that software can be developed and media can be made by nothing more than people working for fun and for free in their free time. Indeed, people point to Linux and say "Look! This great software project made for fun and for free!"

That's not how software development works. Linux? It's very disorganized; there is no central authority to standardize on things like the Desktop interface to use, the ABI for drivers, and what not. This results in Linux being a mess: A hodge-podge of driver ABIs (sound is so bas that it's nay-to-unusable in Linux), desktop GUI interfaces (Qt, GTK, FLTK, Xaw, TCL/TK, Motif and its Lesstif clone, to name just a very few), programs at various stages of development, etc. The only thing Linux can seem to agree on at all is POSIX, which is so old and quaint, the only networking protocol it talks about is UUCP [1].

Linux makes a very good server OS for someone who knows what they are doing, but it is not and never will be an end-user desktop.

For example, the Linux sound system. What happened was that the main developer for Linux's sound system one day grew up and realized that the work needed to make open-source software compared to the reward he was getting was just not worth it. So he tried to make it commercial; other Linux kernel developers wanted to keep everything open source, so they threw out all of his work (never mind that his system was the standard system for doing sound with Linux for years) and reimplemented it, more poorly. Linux's sound is a mess to this very day, with dozens of half-baked audio systems in place, none of which works as good as the original system.

OK, let me go back to why this happened: The main developer grew up. He realized that open source software development for fun and for free is plain simply not worth it. He left the project. No other Linux developer was able to make the same quality of code he did.

Another example: Xconq, which I talked about in this blog posting. Summary: The principal author, after nearly two decades of work on the project on and off, finally lost interest in the project and development just came to a halt without any formal announcement. Many open source projects die like this; the developer loses interest, but never puts closure on the project. Instead of giving the project a proper burial, the project becomes a zombie, dead but pretending to be alive.

Another example: FVWM. Rob Nation realized one day that it was a far more productive use of his time to be with his wife and kids than to work on open-source software, so he stopped FVWM development. He handed over maintenance to other people who, IMHO, did not do as good of a job as Rob Nation developing the software; while FVWM2 has more features than FVWM1, the code is more unstable and more bloated. Indeed, I still use the last release of Rob Nation's FVWM1 today when I'm using Linux. FVWM1 ended with proper closure; FVWM2's development has slowed down but still appears to be actively development (albeit at a glacial pace); the last stable release was done in 2006, but a beta release was done as recently as last month.

Another example: People's Tactics. The developer made a free beer "grogger" wargame for Windows that simulates the old 1970s and 1980s wargames groggers played with hex maps and a zillion tiles on the maps (Squad Leader and other games from Avalon Hill, SPI, Axis & Allies which didn't use hexes but was probably the most popular wargame of this type, etc.) He realized that he should be paid for his work (software development, support, etc.), so removed the website for his older free game, and replaced it with a website for his for-pay Advanced Tactics game.

And, yes, I'm coming to the realization I need to put closure on MaraDNS. This means my next release of MaraDNS (MaraDNS 2.0) will be my last release of MaraDNS. MaraDNS 2.0 will have real Windows service support for the recursive code, in addition to a rewritten thread-free recursive core. I've done about two thirds of this work on and off for two years; I made a lot of progress in late 2007, and even more progress in the first two thirds of 2009, but come September I hit a roadblock when I hit the point of starting to implement full recursion. I have made some progress chipping away at that roadblock, but it's slow progress.

I also hit a point where I realized it is more fun to do things like research Chess variants that no one plays (openings, best opening setup, midgame strategy, etc.) than to finish up my DNS server. Indeed, I feel this software is holding me back; it's written in C (which is next-to-useless on a resume unless you also have C++ or Objective C; come to think of it, with all the companies outsourcing development to India, C development in any form might be useless at this point) in a day and age when the buzzwords people look for on resumes are things like "Java", ".net framework", "PHP", and "SharePoint".

I have been spending my time working on MaraDNS instead of getting my resume out there (it's pretty discouraging in this economy, but I shouldn't give up) or updating my skills. I have been spending my time working on MaraDNS instead of doing what it takes to reach my goals: To have a job making a living wage so I can support myself and my girl comfortably in the US (ideally somewhere where it is sunny like California, my home).

So, yeah, what I'm saying is that I'm taking a break from MaraDNS. I have every plan to finish up the Deadwood code and come out with MaraDNS 2.0. But it isn't going to be the end of 2009. Maybe I'll start work on MaraDNS again next week; maybe I'll just let it rest until 2010 sometime, just as I stopped Deadwood development for most of 2008 and only started development up again in early 2009.

Do I want to finish up Deadwood and release MaraDNS 2.0? Yes. Am I going to do it anytime soon? Probably not. I'm having fun downloading and trying out various turn-based strategy video games; I would rather do that right now (or research Chess variants) than develop a program which has only made a very little amount of money for the amount of work I've put in to the code.

I'm growing up and realize that there are more important things than making programs for fun and for free. Yes, I do want to finish up Deadwood mainly to put closure on the project, but I don't think I'll do any MaraDNS development besides basic bug fixes after MaraDNS 2.0 comes out.

- Sam

[1] UUCP: You don't want to know. I remember when an ISP I worked for dropped UUCP support; UUCP was a nightmare to configure and we simply no longer had anyone who could configure our UUCP servers. The *only* thing UUCP can be used for is email and Usenet.

Deadwood roadmap: Implementing recursion

I am now ready to begin implementing recursion for Deadwood.

My plan is to write functions that handle the recursion, then revamp the code that handles in-flight requests to be able to handle recursive requests.

The first code I will write is a function that can compare DNS labels in a string to see if they are the same label. If they are, return a 1, otherwise return a 0 (-1 if some error happens while doing this processing).

After doing that, I will write a function that, if given a DNS reply with NS records, converts the NS records in to IPs if there is sufficient information in the AR section of a DNS reply to do so.

Once I do that, I will make a function that sees if a given reply is complete. A complete reply is a reply where the IP or whatever they asked for is in the answer they give us. A CNAME reply is complete if it includes the requested IP/whatever. A "not there" (SOA in NS section) reply is complete. A reply with an IP is complete.

A CNAME reply without the actual IP or whatever is incomplete. As is a NS referral.

Anyway, I hope to start work on this in a day or two.

Another feature to add for Deadwood 3.0

Another feature I will need to add to Deadwood 3.0 before releasing it is giving it the ability to parse legal MaraDNS 1.x files.

This means I have to add every single variable MaraDNS 1.x has in mararc files and adding it to Deadwood. For the most past, the variables will be ignored and do nothing; the Deadwood man page will have, for each of these variables, a description of the variable and the note "This variable does not affect Deadwood and is only here so Deadwood can parse MaraDNS mararc files". For example, we will have a "dummy" csv2 dictionary variable (a pointer to a zone file in MaraDNS 1.2+) which will do nothing in Deadwood.

The most notable change I will have to make is adding support for ipv4_alias to Deadwood 3.0, which will result in the code which parses IPs being re-written.