MaraDNS 1.4.05 and MaraDNS 1.9.09 released

I have, these last couple of days, made new MaraDNS releases which update their version of Deadwood up to Deadwood-3.0.01:

http://maradns.org/download.html
http://sourceforge.net/projects/maradns/files/
http://maradns.org/download/1.9/

Deadwood 2.9.07 released: Faster resolution, better security

I have released Deadwood 2.9.07 today. Compared to Deadwood 2.9.06, this release offers:

• Faster resolution speeds. I have fixed two significant bugs which measurably slowed down Deadwood’s resolution performance; now Deadwood has, on my home internet connection, performance better than Unbound (it took Deadwood 2.9.07 159 seconds to resolve a list of names; Unbound 1.4.6 needed 169 seconds to resolve this list).
• Better security. The underlying hash compression function uses a “secret” number in its core that is usually only changed whenever a new Deadwood release is made. I have updated this code to now have another “secret” number that is changed every time Deadwood is started.
• Spam zombie protection. For over a year, there was a bug in Deadwood that broke MX records. Not only have I fixed this bug in Deadwood 2.9.07, I also have set up Deadwood to disable MX records by default, since they are generally only used by email hubs and “zombie” computers spewing spam.

This release can be downloaded here:

http://maradns.org/deadwood/testing

Deadwood 2.9.06 released

I have just released Deadwood 2.9.06. This is Deadwood 2.9.05 with its handling of empty DNS packets tweaked to handle the corner case of a DNS server giving out an empty packet better. It’s been two weeks since the last Deadwood testing release and it looks like I’m getting down to the nitty-gritty corner cases that only affect a tiny percentage of DNS resolutions (properly configured DNS servers do not give out empty DNS packets).

My plan is to release Deadwood 3.0.01 in a little over two weeks.

Meanwhile, Deadwood can be downloaded here:

http://maradns.org/deadwood/testing/

Deadwood 2.9.05 released

As long as I find bugs that stop sites from resolving, I will continue to make weekly releases of Deadwood.

I’ve added a workaround for one particular broken DNS server as well as fixing resolution of ANY queries that point to CNAME records.

It can be looked at here:

http://maradns.org/deadwood/testing/

There is also a change log available.

Deadwood 2.9.04 released

I have released Deadwood today. This is the recursive resolver that I recommend all MaraDNS and Deadwood users use unless they have a compelling reason to use an older release of a recursive resolver; all other MaraDNS recursive code will now only be updated to address critical security problems. For example, if MaraDNS 1.0’s resolver stops being able to resolve www.google.com or www.microsoft.com tomorrow, I will not update it; I will tell people to update to Deadwood.

That said, this is still a beta-test release of Deadwood. The code has only been beta-tested for under a month and I want to get two full months of beta testing before declaring it stable. I really appreciate all of the bugs and issues Sebastian Müller has reported and hope other people also test this software and report issues.

It may seem unusual that I am not fixing bugs with the stable 1.0 recursive resolver while the Deadwood (MaraDNS 2.0) recursive resolver is only undergoing beta-testing. This isn’t entirely true; if someone reports a bug with MataDNS 1.0’s recursive resolver and wants it fixed, I will fix it. For a price. My business model with MaraDNS is to use the program as my resume (since I was having fun in Mexico during the first decade of the 2000s, it’s how I have been keeping my computer skills up to date), as well as accepting donations and selling service and support. [1]

Right now, the kinds of bugs I want people to look for and report in Deadwood are host names that do not resolve. If there is a host out there that correctly resolves in BIND or whatever, but doesn’t resolve in Deadwood, I want to know about it. I also want to know about any memory leaks people find in Deadwood. I welcome reports of crashes, but only if accompanied by a stack trace or recipe to reproduce the crash (ideally both). Valgrind errors are OK to report, but only if Deadwood is compiled with “VALGRIND_NOERRORS” defined (export FLAGS='-g -DVALGRIND_NOERRORS' ; make from the src/ directory of Deadwood). I would love people to test IPv6 compatibility with Deadwood; the SQA regressions tell me Deadwood works with IPv6, but I would love reports from users on IPv6 networks to see if they are any real-world problems with it (IPv6 needs to be explicitly enabled when compiling Deadwood: export FLAGS='-O3 -DIPV6' ; make ).

Deadwood 2.9.04 can be downloaded here:

http://maradns.org/deadwood/testing/

[1] I find it incredibly naive when people tell me I work on MaraDNS because I want to tweak things or what not. No, sorry freetards, the amount of work I do on MaraDNS is far greater than tweaking around and installing a new Linux distribution or compiling a program with different optimization flags. The reason I worked so hard on MaraDNS is because I wanted to make my mark on the world, have my Wikipedia page. I did that. And it was a nice way for me to pass the time during slower moments in Mexico when there weren’t girls around to flirt with. But, now I’m married and I need to think about the bottom line. Amazing how a wife changes my priorities.

Deadwood 2.9.03 released ; some thoughts on EDNS

I have released Deadwood 2.9.03 today. This is Deadwood 2.9.02 with a number of bug fixes added, as described in the Deadwood change log.

It can be downloaded here:

http://maradns.org/deadwood/testing/

---

One of the bugs I have fixed in Deadwood 2.9.03 is to change how EDNS (RFC2671) packets are handled. It used to be that Deadwood would just discard such packets, since Deadwood’s policy is to ignore anything that looks unusual.

RFC2671, in section 5.3, says that these packets should be handled by sending an error message back; I use the error message NOTIMPL (“not implemented”), which RFC2671 suggests as a possible error to give back when an EDNS request is sent. However, thinking about it some more, it may make more sense to what MaraDNS and DJB’s dnscache do: Treat a DNS packet with an EDNS section as if the packet were an ordinary DNS packet, ignoring the EDNS information.

The advantage with this approach is that poorly written non-RFC-compliant DNS servers which aren’t smart enough to try with a non-ENDS packet after getting a “not implemented” reply will still work with Deadwood. Considering that MaraDNS and dnscache have done this for years, it looks like this approach won’t result in any problems.

Update: I just uploaded a snapshot of Deadwood which by default ignores the EDNS part of a EDNS query. The old RFC-compliant behavior of sending a NOTIMPL can be enabled by defining STRICT_RFC2671_COMPLIANCE when compiling Deadwood. It can be downloaded in the usual place.

Deadwood 2.9.01 released: Full recursion

I have just released Deadwood 2.9.01. This is the first release of the fully recursive Deadwood; Deadwood no longer needs an upstream server performing the “heavy lifting” of recursive DNS.

I have done a lot of “web surfing” testing with Deadwood; I have fixed enough bugs that Deadwood can be used for casual web surfing. Indeed, I am using Deadwood to post this blog right now and the issues I saw before (tagged.com, etc.) are no longer a problem.

This is a testing release. That now has a different meaning than my previous definition of a testing release. All of the features Deadwood 3.0 (MaraDNS 2.0) will have are already implemented. At this point, the program needs testing (expansion of the SQA regressions to handle recursion, etc.) and documentation (root_servers hasn’t been documented yet) updates.

It has been a long road to get here. I have wanted to rewrite MaraDNS’ recursive resolver since 2002; I started writing Deadwood in 2007 and it’s finally feature-complete here in 2010.

Deadwood 2.9.01 can be downloaded as source code and Windows binaries here:

maradns.org/deadwood/testing/

I encourage people to test Deadwood and make bug reports. Some things to keep in mind:

• Valgrind-reported memory leaks can always be reported. Valgrind-reported errors are only valid if Deadwood is compiled with -DVALGRIND_NOERRORS
• The only officially supported OSes are Windows XP and CentOS 5. OS-specific issues such as startup, daemonizing, sysloggin, and /etc/resolv.conf setup are only supported on these two OSes.
• Bugs need to be reported to the MaraDNS list, not to my email account nor as blog comments. I hope to have time to set up a web forum for MaraDNS/Deadwood support for people not comfortable with mailing lists, but no promises.

Deadwood 2.6.05 released: Feature complete

Deadwood is now feature complete.

However, it does not pass the “browsing” test. In other words, when I start to surf the net with Deadwood, my web surfing experience is hindered because of issues in the code. I have found the following issues to resolve:

• CNAMEs pointing to nothing broken (e.g. AAAA for mail.google.com).
• Poor handling of unresponsive name servers (samiam.org, kintera.com)
• Use CryptGenRandom() as entropy source in Windows.

I hope to get these issues resolved. In the meantime, I have released Deadwood 2.6.05 today, which is a working recursive nameserver. It is in the testing/ directory here:

maradns.org/deadwood

Deadwood 2.6.04 released: CNAME support

I’m almost at the finish line.

Deadwood is almost feature-complete for the (hopefully very soon) up-and-coming 2.0 release of MaraDNS.

This morning, I wrapped up support for resolving incomplete CNAME entries. The only thing I have to do at this point is have Deadwood do the right thing for ANY records, then the testing cycle begins.

In plain English, this means Deadwood is ready for people who do not need to run an email server with it (email servers need to do a lot of ANY queries); it is OK to test it by browsing the web with it.

As I was doing the regression tests for the release (a series of tests I run before any release to make sure nothing breaks between releases), I discovered that one of my tests, which works fine in CentOS 5.3 and 5.4, no longer works in CentOS 5.5. This is an issue with the OS, not Deadwood. If I have time and feel charitable, I will isolate the bug and make a bug report. I still run this test in CentOS 5.3 when I do Deadwood’s 64-bit testing.

In addition, I had to revise the tests using Valgrind, since CentOS 5.5 has updated Valgrind to a version with slightly different output. I have set up these tests to have two successful outputs—the output in Valgrind that comes with CentOS 5.5, and the old output for when I do 64-bit testing in CentOS 5.3.

This release of Deadwood is available here:

http://maradns.org/deadwood/testing/

I am using its recursive resolution to write this blog entry right now. Web surfing around, the only website I have seen problems with is tagged.com; some host name needed to load Javascript here isn’t resolving. I will look at this when I have some time.

Another known bug is that Deadwood makes unneeded multiple upstream DNS queries when resolving an incomplete CNAME record.

OK, I have a lot to do, but encourage users who aren’t running MTAs (email servers) to test out Deadwood 2.6.04 and report any bugs as comments here or on the MaraDNS mailing list. Please do not email me bug reports, unless it’s a Bugtraq-worthy security bug report.

Deadwood 2.6.03 released: Glueless NS referrals now implemented

I have just released Deadwood 2.6.03. This release implements Glueless NS recursion; in other words, approximately 90% or 95% of domains should now recursively resolve with Deadwood.

This is a testing release of Deadwood; while I am fixing bugs (and making sure there are no regressions between releases), the emphasis is on implementing new features.

The next thing I will implement is handling incomplete CNAME referrals.

It can be downloaded here:

http://maradns.org/deadwood/testing/

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 2.6.01 released

Deadwood 2.6.01 released.

This is a Deadwood release with a significant part of full recursion implemented: The code that analyzes an incoming DNS packet to determine what the next course of action should be (send the reply to the stub resolver, contact another NS server, look up a different hostname because we got a CNAME referral, etc.), complete with security checks like bailiwick verification, has been done.

Right now, the code that caches an entry runs this code to massage a DNS packet; this results in the packets Deadwood returning from cache looking different (anything that isn’t an answer to our question is now removed from a DNS packet). Indeed, I had to overhaul the SQA tests to reflect this change.

This is an important step in giving Deadwood full recursion so I can get MaraDNS 2.0 out the door.

It can be looked at here:

http://maradns.org/deadwood/testing/

Deadwood 2.5.01 released

I have just released Deadwood 2.5.01. This is a testing release; while bugs will be fixed, the emphasis is more on adding features.

This release adds the filter_rfc1918 parameter, which is enabled by default. This filters out all DNS replies with IP addresses that are non-global (RFC1918) addresses; in other words, 10.x.x.x, 192.168.x.x, and 172.{16-31}.x.x addresses. This is done for security purposes.

In addition, this release can be compiled with the tiny TCC compiler, and there is a Windows .7z file which includes the Deadwood source and the TCC compiler for people who wish to compile Deadwood on Windows without installing MinGW/Msys.

It can be downloaded here:

maradns.org/deadwood/testing