MaraDNS snapshot update: IPs for non-existent hosts now work

I have released a snapshot of MaraDNS today. The feature sponsored by XenoBank now works; it is now possible to configure MaraDNS to give someone an IP instead of a SOA answer.

This hasn't been documented yet, but doing it is very easy. To try it out, download the 20090131 snapshot of MaraDNS then extract and compile the source code.

Next, use this version of MaraDNS to ask for a nonexistent hostname like "fooz.example.com":

dig @127.0.0.1 fooz.example.com.

You will get a standard "this host does not exist" answer (a SOA in the NS section of the answer).

Next, add a line like this to your mararc file:

notthere_ip = "10.11.12.13"

Now, restart MaraDNS and look up "fooz.example.com" again with dig.

This time, you will get a 0-ttl answer with the IP 10.11.12.13.

So, it works.

This doesn't mean we're ready to release 1.3.13 with this feature implemented. There is a lot to be done:

• Should we also have the option to create a bogus IP like this when there is no reply from a remote server?
• Are there cases where we will get this bogus IP right now when getting no reply
• I need to make a SQA test case that verifies this feature works
• I don't think the code leaks memory, but make sure it doesn't
• The bogus IP reply doesn't use DNS compression for the answer; since it's just a copy of the query, this is easily enough fixed (just add the 2-byte compression pointer and type of 1 instead of copying the query again), Should this be done?
• Document how to do this

Also, since I am devoting more work to MaraDNS in 2009 than I originally planned to, I am restructuring the snapshot directories of MaraDNS 1.3 to have a different directory each month. The "2009" link is now just a symlink to the 200901 (January of 2009) directory, so old links posted on this blog continue to work. Starting tomorrow, I will make a "200902" directory and put February snapshots in that directory.

Again, the new snapshot can be downloaded by clicking on this link and selecting the 20090131 version of MaraDNS (maradns-Q-20090131-1.tar.bz2).

MaraDNS snapshot update

I am continuing work on the XeroBank-sponsored patch. Right now, I have written the code that converts a dotted-decimal-ip in to the end of the DNS packet to send back to the user; and the code to see whether we should send this packet to the user instead of a SOA reply. The next step is to write a function to send the user this DNS pack (the IP answer to their question with a 0-TTL).

It can be downloaded by clicking on here and selecting the "20090130" tarball (".tar.bz2" file).

MaraDNS snapshot uploaded

I have uploaded a MaraDNS snapshot with the beginning of my work for XeroBank; I also have added Radio Gatun 32-bit support to the mqhash program.

It can be downloaded by following this link

XeroBank is sponsoring MaraDNS

I have some great news! XeroBank (who offers Internet Privacy, Identity Protection, Privacy Protection, Anonymous Proxy services, Anonymous Surfing, and Anonymous Browsing) has very kindly offered to sponsor MaraDNS. In particular, they will sponsor the implementation of an IP being given instead of a SOA record when someone asks for a host name that doesn't exist.

I will begin work on implementing this today and will release a snapshot (and a second blog entry for today) tonight.

Because of this offer, development on Deadwood is suspended until I get this feature implemented.

- Sam

Deadwood update

I looked over the code today; it would appear Deadwood's TCP resolver doesn't work in Cygwin.

I will test this in CentOS 5.2 and at home when I have time to do so.

Because of this unforeseen issue, there will not be a Deadwood snapshot update today.

Deadwood minor snapshot update

Minor snapshot update to Deadwood: I have fixed a one-line bug where the version number would get printed twice when invoked as deadwood --version.

It's in the usual place

Deadwood snapshot update and ToDo

This morning, I went through the Deadwood code and looked over all of the raw printf() statements. I have converted them to routines that call three different functions starting with dw_log. The reason for doing this is so we can have more or less messages printed out depending on their verbose_level setting, and so it will be easier to add daemonetization code that uses syslog() or what not instead of printf().

Before I release Deadwood, I will finish these ToDo items:

• Fix double version number when DwMain is invoked as "DwMain -v"
• Make sure DwTcp works and give it a man page

It can be downloaded at maradns.org/deadwood

Deadwood snapshot update

I have begun work on having proper log levels in Deadwood. I added a verbose_level Deadwood parameter today and have started work on converting raw printf statements in to calls to a logger that sees if the message in question is one we show at the user-selected verbose_level.

This work will continue tomorrow or later this week; there are a number of printf statements I need to evaluate in the code.

The snapshot is in the usual place.

Deadwood snapshot update

I have uploaded a new snapshot of Deadwood today. In this snapshot, I have fixed a bug where the size of the cache when loading the cache from a file was always determined by looking at the cache file. Now, Deadwood will always look at the dwood2rc (configuration file) to determine how many entries we will allow the cache to have.

If you shrink the cache size in one's dwood2rc so all the elements in the cache file no longer fit, Deadwood will do the right thing and discard "less important" cache elements. This is because Deadwood's cache starts off with less important elements and finishes with the most important elements; when reading the file, should the cache fill up, Deadwood will simply discard the less important entries as it loads more important entries.

It can be downloaded at maradns.org/deadwood.

Deadwood snapshot bugfix

I normally don't introduce two Deadwood snapshots in the same day, but I have found and fixed a bug I just introduced.

Basically, the bugfix so we could have answers that are nothing but CNAME records (which was itself a bug introduced by the fix for the "Google bug") introduced another bug: It caused all "this host is not here" answers to be cached for a year.

I've fixed this. See maradns.org/deadwood

This is why reputable software vendors take their time making bug fixes, even security patches available. Often times, a bugfix will introduce other bugs (and, in this case, we have a bugfix introduce another bug, then have the fix for that bug introduce yet another bug).

I understand why DJB basically ended up hating the DNS standard after he was done writing DJBdns.

Deadwood snapshot update

I fixed the bug I mentioned yesterday where CNAME-only DNS packets would not get processed. I also added another rule to Deadwood's coding style: the only for(;;) loops are to be the program's main loop, and made the appropriate coding changes to make sure these are the only infinite loops in the program.

It can be downloaded at maradns.org/deadwood.

Todo:

• Fix dw_cache cache entry count bug
• Streamline logging system: no raw printf routines in the code's body
• Give DwTcp a man page
• Release Deadwood 2.04

Deadwood snapshot update

I have finally fixed the "Google problem" with Deadwood. The fix is incomplete; in particular I have to add some code to remove a single compile-time warning and to make it so Deadwood properly handles DNS packets with nothing but CNAME records correctly again.

People can look at my code here:

maradns.org/deadwood

Personal condolences for fellow DNS implementor

I would like to send personal condolences to Paul Rombouts, the maintainer of Pdnsd for the family problems he has had in 2008, and hope 2009 is a better year for him.

I will keep him in my prayers.

MaraDNS support boundaries; Linux rocks as a server

To clarify the boundaries of support for MaraDNS, a memory leak has to be something where one can show that MaraDNS is allocating memory while running that is never freed, and results in MaraDNS using more and more memory while running. Memory allocated but not freed during startup doesn't count; while I cleaned most of those in 2006, there is one that I couldn't clean up because the recursive code depends on it.

Did I mention that I'll happily do other things for MaraDNS if paid? These boundaries of support only cover what I'll do for fun and for free.

---

Let me clarify something: I think Linux is an excellent server operating system. While not quite as nice as FreeBSD, if one uses a stable distribution, such as Debian stable or RHEL/CentOS on supported hardware, one has an excellent server. According to some reports I have heard, a Linux server can handle about four times the traffic as the same machine running a server version of Windows.

Indeed, just this last week there was some problem with our internet connection at work making it difficult to keep TCP connections open. What was interesting was that the problem only seemed to be happening with Windows servers; I had no problem downloading files from Linux and other servers but couldn't download a simple 100 kilobyte email from our email provider who runs Windows as a server.

However, Linux doesn't work as a desktop OS yet:

• Binary compatibility. The Linux Kernel developers do not care as much as they should about binary compatibility. I can no longer play these video games for Linux I bought a few years ago in modern releases of Linux (the sound no longer works). The ABI (and hell, the API) for kernel modules changes from version to version; forget about getting new hardware to work with an older kernel (LWN tries to justify this practice by implying it's not OK to want to run new hardware on an older, stable kernel; my response is simple: Windows has no problem with having a stable driver model allowing new drivers to be made for older OSes yet working without problem on newer OSes. Why can't Linux do this?)
• Because of this issue with drivers, I have two choices. I can have an unstable distribution of Linux (Ubuntu) that works with my hardware but has basic functionality, such as using wireless with static IPs, broken (not to mention a bug that damages hard disks and makes them not last nearly as long as they do in Windows), or I can have a stable distribution of Linux (RHEL/CentOS) that doesn't fully work with my hardware (The wireless driver has issues with crashing and sound doesn't work)
• Fragmentation. I don't like the fact that, with my open source programs, it is difficult to resolve issues like my program not starting up correctly in Linux at boot time. Different distributions of Linux have different ways of doing this and issues like this make supporting Linux applications more difficult. I actually just threw in the towel and no longer support my application except through the public list
• The user community. I don't like people who treat Linux like a religion, being someone who was the that way about Linux a decade ago. I don't think it's appropriate to declare Jihads against people who don't think Linux is God's gift to the earth, and the actions of Linux zealots (which you can see on a number of bulletin boards, such as Slashdot and to a lesser degree Digg) are pretty annoying at times
• Applications. Since Linux isn't a friendly environment for binary-only applications, a large number of quality applications are not ported to Linux. This even includes things like being able to transfer files to and from my cell phone from my computer--Nokia makes a nice software suite that lets me transfer files to and from its internal memory, send text messages using my computer's keyboard, make changes to my cell phone's addressbook, etc. Forget about doing any if this in Linux.

So yeah, Linux sucks...on the desktop. But yeah, Linux rocks (and kicks Windows' ass) in the server back room.

MaraDNS update; the last one for a while

OK, I have uploaded another snapshot of MaraDNS today. This should be the last MaraDNS snapshot I will upload in a while; I am going to concentrate my work on Deadwood for the time being.

Basically, only critical bugs in MaraDNS will be handled during 2009. A critical bug is:

• An Alexa top 500 site not resolving with MaraDNS
• A bug that makes MaraDNS terminate
• A memory leak in MaraDNS
• A bug that makes it so MaraDNS will not compile in any version of GCC 3 or higher
• Any other bug that I deem to be a serious bug (it'll be my call)

I have looked at how MaraDNS handles zone files with incorrect DNS delegations and it appears MaraDNS can usually handle these kinds of zones; I have discussed my research and workaround in previous blog entries.

The only change in today's snapshot is that I forgot to close the quote in the URL to Unbound; making the page look weird in Firefox. I have added this quote, resulting in a one-character change to the tarball, and have uploaded it here:

www.maradns.org/download/1.3/snap/2009

This should be my last MaraDNS release for a while.

Now I will get back to working on Deadwood again. My next project is to fix the "Google problem".

Invasion of the Linux fanboyz

Linux sucks.

It sucks because of its fanboyz. Let me give you one issue.

Some young lady ordered a computer from Dell. For whatever reason, the computer ended up being a computer with Linux instead of Windows. This lady tried using it, and ended up completely lost, unable to take her classes at college, and wants to have Windows on her computer again.

So, how to Linux users react to it? With extreme hostility. A comment calling her an "airhead" gets moderated as a positive, helpful comment on Slashdot.

Pathetic. Someone tries Linux, decides they don't like it, and wants Linux removed from their computer. Linux fanboyz react to this person by calling her every name in the book.

Disgusting.

There's a reason that Linux is a failure on the desktop. It's not because anyone who doesn't like Linux is an idiot. It's because Linux has some serious issues that they need to resolve before Linux is ready for the desktop.

In the meantime, I will continue to use Windows XP as my primary desktop operating system, and a VMware image of Linux for development work.

MaraDNS snapshot update

I have done a number of updates this last day in preparing my snapshot update. One issue is that I have fixed the timestamps the VMware server creates; I will discuss the timestamp issue and possible workarounds in a future blog. The timestamp for the last snapshot was off by a day or so; the current snapshot has correct timestamps.

In addition, I took the rg32hash program (which recursively calculates Radio Gatun 32-bit sums, given a list of files and folders), removed all compile-time warnings, and am adding it to the next MaraDNS release. It's in tools/misc.

I have also added a "borked zone" test; this is a test that reproduces the bug mentioned in yesterday's blog entry. The results I get from this testcase is that MaraDNS initially reports a "server fail", but will correctly resolve a hostname when a second query is sent. This "server fail" message, if it causes problems, can be resolved by setting the mararc variable handle_noreply to have a value of 0.

This test is in the directory sqa/regressions/borked_zone.

OK, some MaraDNS todos:

• Update the list of other DNS servers to mention unbound and dnsmasq
• Update the FAQ to add a workaround for the borked zone issue
• Add a man page for rg32hash
• Add Radio Gatun support to mqhash

Since there is a reasonable workaround (set handle_noreply to 0), I see no reason to try and fix the borked zone issue; I don't like making changes to the recursive resolver.

The snapshot can be downloaded at http://www.maradns.org/download/1.3/snap/2009

MaraDNS snapshot update

Since a bug with MaraDNS' recursive resolver has been found, involving handling poorly done DNS zone files (click on the "bug" link for the details), I have been in the process of setting up a Vmware virtual machine for developing and testing MaraDNS while in Windows (I have a number of rants which detail why I use Windows XP instead of Linux for my desktop OS).

The Vmware virtual machine is a "guest" operating system for Vmware player which I downloaded from a repository called Thought police. The OS I chose is CentOS 5.2, since CentOS 4 doesn't have a working ethernet interface allowing it to interact directly with Windows or the internet, and since 5.2 looks to be the most supported branch of CentOS 5 (maybe the only supported branch). I'm using CentOS instead of Ubuntu or Fedora since it's a good deal more stable and less prone to change breaking things at some developer's whim.

I have been spending the last couple of days getting this virtual machine set up as a MaraDNS testing platform (removing X, adding a compiler, applying security updates, etc.) then getting MaraDNS to work with this stock CentOS install. Mostly everything worked, except one of the regression tests, which I fixed to work without needing non-standard tools like the "ip" program.

I also updated the script that makes the tarballs for me to use less non-standard programs. Notably, we will no longer have a ".lzma" version of MaraDNS; while the compression is better, the format never caught on except in the Busybox community, and using fewer formats that are more standard for the release makes maintenance simpler.

I have also updated the version of Deadwood 2 included with this program to be the latest Deadwood 2.03.

Now that things work in my Vmware image of CentOS 5.2, I hope to have time to look at that resolving bug later on this week.

The file can be downloaded here (the word "here" is a link to click on).

Digital signatures for Deadwood 2.03 now available

Just letting people know that digital signatures for Deadwood 2.03 have been made, and are signed with the same key I use for signing MaraDNS releases. You can see the sigs here (click on the link).

I have gotten the CentOS 5.2 Vmware virtual machine running again, and am currently in the process of making the regressions work correctly.

I will work on MaraDNS some possibly later on this week.

Deadwood 2.03 released

Well, I spoke too soon about not updating Deadwood until I can get my CentOS Vmware image up and going again. I discovered a bug in Deadwood this morning. The bug is pretty minor: Should Deadwood not be able to bind to all IP addresses it tries to bind to, it would end with a deceptive error message.

I just changed the code to have Deadwood still run as long as it binds to at least one IP address. Yeah, I should add code to warn the user which IP addresses we did not bind to, but the whole messaging system needs an overhaul.

This version of Deadwood has otherwise worked for me without problem for over four months. I am declaring this stable and Deadwood 2.03.

It can be downloaded here:

maradns.org/deadwood

The md5 sum is 9490d474a4a25b01297ce58e019c5994.

The sha1 sum is cb1e4dffb3e110208ea03b42345fa1adb4c56654.

The Radio Gatun 32 sum is
9d16f8e2d2a33fd5fc37f787d770cfd7a21309e97734862098cadf7b18be4d1f.

Deadwood update

I have released a new snapshot of Deadwood today. This snapshot makes no changes to the code, but rearranges files, fixes a typo in the DwMain man page, and adds an INSTALL document which details how to compile and install the program.

It can be downloaded in the usual place (click on the link, guys)

This will be my last release of Deadwood until I can free up some hard disk space to run Linux as a VMware guest operating system.

You can still buy Windows XP

One little delusion Linux advocates like to spread is that Microsoft is somehow forcing people to upgrade to Windows Vista, that it is impossible to get Windows XP, that you have to buy Vista. If only it were true.

I just went over to shopping.google.com, did a search for "Windows XP home edition Spanish" and "Windows XP pro Spanish" and right away found a number of dealers selling legal copies of XP Home for about $100 and XP Pro for about $150. Amazon's software store also has it, albeit in a harder-to-find form: I had to ask for "Windows XP professional Spanish".

What was this about Windows XP being hard to get from Microsoft again?

Now, yeah, I will admit that Microsoft did phase out XP and replaced it with Vista on new computers a little more quickly than they should have; I know there has been a lot of consumer dissatisfaction with this (people have been grumbling about Vista, my mother doesn't like how Vista is really slow to boot up on her computer, my girlfriend doesn't like how it's difficult to have MSN and Skype open at the same time on her computer with 1 gig of ram, etc.). Vista was a mistake because, you know, your average user doesn't care for all of that eye candy, but they do care that their applications that ran fine under XP in their old computer are now dog slow under Vista.

That said, it still is possible to get XP, and, yeah, Microsoft and most OEMs still support XP. For example, Microsoft made one patch that gives XP SDHC support available; another to give XP WPA2 support. The only problem I have had getting new hardware to work with XP is with the sound driver; there is a bit of a song and dance one has to do to get sound to work.

Now, compare this to CentOS 3.x, the only Linux from the same era as the first release of Windows XP that is still supported. Support is very limited: Security patches only. Forget about getting new drivers. Forget getting your new computer to work with CentOS 3.

Linux is far worse when it comes to forced upgrades. I really wish CentOS 3 could run fine with full driver support on my 2007-era laptop, the way XP can. I really wish it was still possible to play the late 1990s/early 2000s Loki games for Linux on a version of Linux that fully supports my laptop from 2007.

But, no, Linux forces you to upgrade, whether you want to or not. I spent good money getting commercial games for Linux; those games no longer run in Linux. I finally broke down and bought the Windows version of a game I bought for Linux back in 1999 (Heroes of Might and Magic III) this last winter so I can continue to play this game. And, yes, the game runs fine in Windows.

Deadwood minor update; djb software rant

I have made a minor update to Deadwood; I have updated the DwMain man page (manual page; "man page" is *NIX-ese for "manual") and added a Makefile to automatically convert the man pages from MaraDNS' internal documentation format to text files and *NIX's standard documentation format.

It can be downloaded at maradns.org/deadwood.

---

Using DJB software is harmful.

If you're looking to use a DNS server, use anything besides DjbDNS. DjbDNS sucks, frankly.

The first problem is that it hasn't been able to compile on Linux for years. Yeah, there's a fix for it, but what use is it to download a program where you have to look online for help just to compile the program.

The second is that the program has a nasty remote denial of service security bug. It is possible to remotely restart DjbDNS' cache unless you apply the security fix.

The third problem is the userbase. DjbDNS advocates do not acknowledge the remote denial of service problem, and go out of their way to cover it up and pretend the problem does not exist. Instead, they will continue to repeat the same lies about how DjbDNS is "100% secure" and "has never had a security problem".

Indeed, I got in a nasty edit war on the Wikipedia when I unsuccessfully tried to put accurate information about DjbDNS' security problems there; the Wiki's acceptance of these kinds of lies getting published there disgusted me so much I have left the Wikipedia. The Wikipedia entry still has the same old BS about about DjbDNS is "highly secure".

DjbDNS has a number of other problems, which I have detailed in older blog entires (just look for older entries tagged "DjbDNS"), which its advocates respond to by either blaming the user for DjbDNS' problem, or by pretending the problem doesn't exist.

Don't waste your time with a program with security problems (that DJB and DJB advocates try and cover up instead of acknowledging and patching) and that won't even compile unpatched. There are a lot of other currently maintained DNS offerings, such as BIND, such as Power DNS, such as Unbound, such as dnsmasq, and, yeah, such as my own MaraDNS (and Deadwood).

On a related topic, Qmail has a nasty security problem called "Backscatter spam". Netqmail, which is the maintained branch of Qmail, doesn't fix this problem. Yes, there are fixes, but they require people to go out of their way to find and install patches. Which is something people shouldn't have to do in 2009.

Just use sendmail, postfix, exim, courier MTA, or another currently maintained MTA that doesn't pretend issues like backscatter spam aren't security problems.

Some interesting links: Rick Moen on DJBware How one person handled legitimate criticism of DJB's software