MaraDNS progress report: Documentation updates

I am continuing to update MaraDNS 2.0’s up and-coming documentation to correctly reflect the fact that all recursion is now done by the separate daemon Deadwood. I have also updated Deadwood’s manpage to state that Deadwood is a fully recursive DNS server.

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

New MaraDNS 1.9 snapshot

I made some progress with updating the documentation for MaraDNS 2.0; I have updated the mararc man page to remove parameters that are used for MaraDNS 1’s recursion, as well as adding a section in the update document on updating from MaraDNS 1.4 to MaraDNS 2.0.

I plan on adding a couple of details from the Deadwood FAQ to MaraDNS’s upgrade document, as well as updating MaraDNS’ tutorials to discuss using Deadwood for all recursion.

I am considering MaraDNS 1.9.x releases “snapshot” releases since I am making them fairly quickly right now.

They can be looked at here:

http://maradns.org/download/1.9

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.

ObHack 007.0 released

Fritz has made a release of ObHack 007.0, which I have uploaded to my web site:

samiam.org/slump

More information and support for this release is here:

http://www.doomworld.com/vb/doom-editing/52407-obhack-007-0-released-random-map-generator/

Deadwood update: No news is good news

No news is good news.

And, there’s no news for Deadwood this week. The only updates since 2.9.05 released a week ago today are documentation updates. I haven’t seen a single site not resolve in Deadwood that can resolve with other DNS servers.

I encourage users to continue testing Deadwood and reporting bugs on the MaraDNS mailing list.

Blog update: Comments disabled

I have had to disable comments because people were using the comment system for MaraDNS/Deadwood support concerns. Unfortunately, I do not have the time to use this blog to support MaraDNS and ask that people who have bug reports or whatever to take the time to join the MaraDNS mailing list and share with the list their concern. I have updated the FAQ for this blog to explain my thinking in more detail.

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.

New Deadwood snapshot; allowing anonymous comments

I have just uploaded a new Deadwood snapshot; this release does not change the program, but it has updated the INSTALL.txt file to be current and all compile-time flags Deadwood has are now documented.

It can be looked at here:

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

This may be my last snapshot announcement for Deadwood snapshot updates when the actual Deadwood program has not been changed.

---

I have enabled anonymous comments in my blog again, since it looks like Google has enabled comment spam protection. As always, comments posted here are moderated and Deadwood/MaraDNS support requests will not be published, nor will flames, trolling, and spam.

New Deadwood snapshot: mkSecretTxt added; doc/internals updated

In today’s snapshot of Deadwoood, I have added the mkSecretTxt program I made for the 1.4.04 release of MaraDNS. When adding it to Deadwood, I have added a test to make sure secret.txt does not exist before overwriting it. The thinking is that Windows shies away from potentially dangerous commands more than *NIX does; since overwriting secret.txt without prompting is an example of the old dangerous (and, IMO, obsolete) *NIX way, mkSecretTxt no longer does this.

In addition, I have gone through the doc/internals folder and updated the files there. In the case of a couple of files, I just added a note that the file in question is out of date.

It can be downloaded here:

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

OK, back to learning C++.

Deadwood snapshot update: Working around aplus.net’s broken DNS server

Aplus.net’s DNS server is broken.

Let’s contact their DNS server for the A record for bookride.com:

$ dig @64.29.144.70 www.bookride.com

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> @64.29.144.70 www.bookride.com
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10397
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;www.bookride.com. IN A

;; ANSWER SECTION:
www.bookride.com. 3600 IN CNAME ghs.google.com.

;; AUTHORITY SECTION:
google.com. 86400 IN SOA ns1.aplus.net. hostmaster.aplus.net. 1007 86403 3600 3600000 86400

;; Query time: 304 msec
;; SERVER: 64.29.144.70#53(64.29.144.70)
;; WHEN: Sat Aug 14 01:18:15 2010
;; MSG SIZE rcvd: 119

This is an invalid packet: It is marked as a NXDOMAIN (complete with a SOA record in the NS/Authority section), but it is actually a CNAME.

I have updated Deadwood to treat these broken packets like ordinary CNAME packets. The snapshot can be downloaded here:

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

I am also in the process of trying to file a bug report with aplus.net.

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.3.06 released

I released Deadwood 2.3.06 today. This is a minor update to the older caching-only branch of Deadwood; most users of Deadwood will want to use the current 2.9 branch of Deadwood which has full recursion.

The update is one with possible (but not readily exploitable) security implications. There is a potential null pointer dereference in Deadwood’s underlying string library that the four-line patch assures never happens. As far as I know, there is no way to exploit this issue in Deadwood 2.3 (the bug only popped up when stressing the string library more in the recursive code in Deadwood 2.9), but it is prudent to update the older tiny branch of Deadwood.

Most of the work making this release was updating the tests to work with CentOS 5.5. CentOS 5.4 → 5.5 was supposed to be a bugfix-only update, but, not only did they update Valgrind to a newer version with different output, they also broke select(). The SQA tests have been updated to pass in CentOS 5.5.

The main advantage of the tiny branch of Deadwood is that its binary is only about 32 kilobytes in size, as opposed to Deadwood 2.9’s 64 kilobyte binary. There may be certain tiny embedded systems where this matters. Another advantage is that it can be optionally compiled without caching, making it act as a DNS load balancer. The main disadvantage is that it is a non-recursive cache; it needs another recursive server (like Deadwood 2.9) to do the “heavy lifting” of recursively solving DNS queries.

It can be looked at here:

http://maradns.org/deadwood/tiny

Since this is a maintenance update to an older branch of Deadwood, I have not made Windows binaries. Windows users: Please compile it yourself or, better yet, just use Deadwood 2.9 instead. Really, I can’t think of a machine out there that can run Windows XP (Deadwood won’t run on 95/98/Me because it is a service) where it matters whether the DNS server is 32 or 64 kilobytes in size. The 90s are, like, so over.

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.

New Deadwood snapshot: neustar.biz fixed

While doing my own “dogfood” testing for Deadwood, I discovered that the host name “neustar.biz” did not resolve. The issue was that I never bothered to make DNS queries case-insensitive.

The solution is to convert all DNS queries in to their lower-case form before looking them up in the cache or sending another query out to resolve a glueless NS/incomplete CNAME (in the case of “neustar.biz”, the issue was that the CNAMEs were in upper case). In addition, since there may very well be some stub resolvers out there that won’t accept an answer unless it’s in the same case as the question, I now have Deadwood preserve the case in the original form of the query to give back to the stub resolver, using a variable called “orig_query”.

It can be downloaded here:

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

The patch can also be looked at.

I can see the program is getting some attention by the number of clueless emails I am getting asking for private Deadwood support. It would be nice if these people would pay me once I give them the usual form reply asking for money. That has not happened; people who do not have enough courtesy to heed multiple disclosures that email is only for paying customers are not courteous enough to decide to pay for support. It’s a form of the internet dork rule: The anonymity of the internet coupled with the ease of getting on a soapbox attracts all kinds of unpleasant people; the corollary to this rule is that any unmoderated forum is soon overrun by unpleasant people, since anyone who doesn’t want to waste time getting in to a flame war is soon chased away by the trolls and flamers.

Hopefully this attention will soon translate in to a job with a living wage. Things are tough in this economy, and looking for work is sometimes very frustrating. The only serious interest I have gotten is from people who know about MaraDNS or from connections. Simply putting my resume out there on Monster or Dice so far hasn’t resulted in anything.

RadioGatún[32] even smaller

While going through the source code for the tiny version of RadioGatún[32], I realized the code had some unneeded bloat which I was able to remove, in order to make the program more lean and not be wasting precious bytes. The current version of the program is as follows:

/*Placed in the public domain by Sam Trenholme*/
#include <stdint.h>
#include <stdio.h>
#define p uint32_t
#define f(a) for(c=0;c<a;c++)
#define n f(3){b[c*13]^=s[c];a[16+c]^=s[c];}k(a,b
k(p *a,p *b){p A[19],x,y,r,q[3],c,i;f(3)q[c]=b[c*
13+12];for(i=12;i;i--){f(3)b[c*13+i]=b[c*13+i-1];
}f(3)b[c*13]=q[c];f(12){i=c+1+((c%3)*13);b[i]^=a[
c+1];}f(19){y=(c*7)%19;r=((c*c+c)/2)%32;x=a[y]^(a
[(y+1)%19]|(~a[(y+2)%19]));A[c]=(x>>r)|(x<<(32-r)
);}f(19)a[c]=A[c]^A[(c+1)%19]^A[(c+4)%19];a[0]^=1
;f(3)a[c+13]^=q[c];}l(p *a,p *b,char *v){p s[3],q
,c,r,x,d=0;for(;;){f(3)s[c]=0;f(3){for(q=0;q<4;){
if(!(x=*v&255))d=x=1;v++;s[c]|=x<<(q++*8);if(d){n
);return;}}}n);}}main(int j,char **h){p a[39],b[3
*13],c,e,g;if(j==2){f(39){a[c]=b[c]=0;}l(a,b,h[1]
);f(16)k(a,b);f(4){k(a,b);for(j=1;j<3;++j){g=a[j]
;for(e=4;e;e--){printf("%02x",g&255);g>>=8;}}}}}

There may some more bloat that needs to be removed from this code, however, for the time being, it appears to be a fairly lean implementation of the 32-bit version of RadioGatún. Certainly more efficient that the rather bloated RadioGatún implementation included with Deadwood (which, horror beyond horrors, has comments and other completely unnecessary pieces of code).

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.

NanoDNS updated

I’ve updated NanoDNS to work (in theory) on 64-bit machines, and to handle EDNS packets a little better:

/*Placed in the public domain by Sam Trenholme*/
#include <arpa/inet.h>
#include <string.h>
#include <stdint.h>
#define Z struct sockaddr
#define Y sizeof(d)
int main(int a,char **b){uint32_t i;char q[512]
,p[17]="\xc0\f\0\x01\0\x01\0\0\0\0\0\x04";if(a>
1){struct sockaddr_in d;socklen_t f=511;bzero(&
d,Y);a=socket(AF_INET,SOCK_DGRAM,0);*((uint32_t
*)(p+12))=inet_addr(b[1]);d.sin_family=AF_INET;
d.sin_port=htons(53);bind(a,(Z*)&d,Y);for(;;){i
=recvfrom(a,q,255,0,(Z*)&d,&f);if(i>9&&q[2]>=0)
{q[2]|=128;q[11]?q[3]|=4:1;q[7]++;memcpy(q+i,p,
16);sendto(a,q,i+16,0,(Z*)&d,Y);}}}return 0;}

This is a little bigger than the last version of NanoDNS I posted, but it’s still the world’s smallest useful DNS server. The above code handles a problem people frequently ask on serverfault: “How can I set up a DNS server to always return the same IP in reply to any query?” The program takes one argument: The IP we return. This program binds to all IP addresses a given machine has on the DNS port (port 53).

I’ve also updated MicroDNS (NanoDNS’s big sister, with fancy features like selectable IP to bind to) to better support EDNS packets:

http://samiam.org/software/microdns.html

Update: For people who wonder how NanoDNS does its magic, I now have a page that explains its source code line-by-line.

On the AES instruction set

I mentioned, in a recent blog entry, how much I like the Rijndael cryptographic primitive and why I was very happy when it became the official AES standard.

Once Rijndael was chosen for AES, it did not take long for VIA to add hardward support for it via their VIA padlock (which also included other cool things to have, such as fast SHA support, fast RSA support, and, nicely enough, a true hardware random number generator).

Unfortunately, VIA does not have a prominent enough position in the mindset of people who buy x86 processors to lead the way in terms of x86 extensions (for example, Lenovo for a while was selling a low-cost 12-inch netbook using a VIA instead of an Intel processor, but now all of Lenovo’s netbooks are 10-inch netbooks with the Intel Atom N455, a very nice little processor). So, when Intel decided to implement AES, they used their own instruction set called, simply, the “AES Instruction Set”.

What the AES instruction set does is perform an entire round of the AES encryption process on a 128-bit block. This can be used for AES encryption, of course, or for any related cipher that can use AES’ round function in its core. The SHAvite-3 hash function, for example, uses 128-bit AES for its code. It’s fairly easy to adapt the output to perform 256-bit Rijndael; as well as allowing Rijndael variants with different block sizes, a round transformation of the proposed hash/stream cipher LUX-224/256 uses [1] is Rijndeal-256.

The AES Instruction set is supported by the following CPUs by Intel:

• Core i7-610E, i7-620M, i7-620LM, i7-620LE, i7-640LM, i7-620UM, i7-620UE, i7-640UM, i7-660UM, i7-970, i7-980X, i7-990X
• Core i5-520M, i5-520E, i5-540M, i5-520UM, i5-540UM, i5-650, i5-655K, i5-660, i5-661, i5-670, i5-680
• Xeon E5620, E5630, E5640, E5667, L5609, L5618, L5630, L5638, L5640, W3680, E5645, X5650, X5660, X5670, X5677, X5680

[1] I understand the original LUX was broken, but there is a revision to LUX that hasn’t been broken (yet)

Deadwood snapshot update

I have updated Deadwood to fix two bugs:

• Large packets that needed DNS-over-TCP were not working when Deadwood was using full recursion. Fixed.
• It is now possible to have a recursive_acl without the recursive_acl having a netmask (there is a mailing list posting with a description of the issue)

The updated snapshot can be downloaded here:

http://maradns.org/deadwood/snap/deadwood-H-20100802-2.tar.bz2

Some cryptographic primitives I would like to see

There are some symmetric cryptographic primitives the currently don’t exist or are very rate that I would like to see more of:

• Ciphers which can change the fundamental word size used.
  
  There are a few of these: Keccak can work with 64-bit, 32-bit, or even 16-bit words (or smaller, but there isn’t any real security with going below 16 bits). RadioGatún, Keccak’s predecessor, also allowed any word length between one bit and 64 bits. RC5 and RC6 can work with either 32-bit or 64-bit words (but are, alas, patented until at least 2015). The stream cipher ISAAC exists in 32-bit and 64-bit variants.
  
  But, besides those, there really aren’t that many cryptographic primitives with word size flexibility, which is a disappointment right now, since 32-bit and 64-bit systems are currently very common.
  
  I’m not the only one hungering for this; observe halfskein.js, which is an unofficial Skein variant using 32-bit words (Skein normally uses 64-bit words). I should also point out that LUX has both a 32-bit and a 64-bit mode (unfortunately the original LUX specification was broken; hopefully the revised version will not be.)
  
  
• A block cipher with a 2048-bit or larger block size.
  
  The largest block size out there in an unbroken cipher is Threefish, which includes a version with a 1024-bit block size. There was Mercy, with a 4096-bit (512-byte) block size, but that was unfortunately broken. XXTEA, which also allowed really large blocks has also been broken; and the Hasty Pudding Cipher has also this ability, but I remember reading somewhere that HPC doesn’t pass standard randomness tests, and weaknesses with the key schedule have been found with this cipher (it was also criticized by Brian Gladman as being difficult to implement).
  
  Yes, it is possible to make, say, an AES variant using 128-bit sized words and a 2048-bit block size, but it hasn’t been officially proposed as a block cipher. It should also not be too difficult to make a Skein variant with 2048-bit blocks (or 1024-bit blocks when using 32-bit words), but again this has not been done.
  
  A 2048-bit cipher, for example, would be useful for making a Cryptographic sponge with a 1024-bit rate and 1024-bit capacity, which could be used for either a stream cipher or for a 512-bit cryptographic hash primitive.
  
  
• More tweakable block ciphers. There is only one unbroken block cipher primitive with a tweakable core out there: Threefish. The only other tweakable block cipher is the original: Hasty Pudding Cipher (as discussed above); unfortunately, HPC appears to be broken (or at least have weaknesses)
  
  
• A cipher using playing cards with no known weaknesses.
  
  The strongest cipher designed specifically to be implemented using a deck of cards is the Solitaire cipher; but it has some bias in its PRNG. There has been proposed Mirdek, which is broken, as well as John Savard’s playing card cipher, which also is broken.
  
  The most secure playing card cipher out there appears to be a RC4 variant using playing cards.

One of the frustrations of not having more cryptographic chops is that I can not comfortably design a cryptographic primitive with any of the above desired traits. As a mere programmer, all I can do is hope to someday have the time to learn about differential cryptanalysis and what not so I can design one of these primitives, or have someone else do the work for me.

So, hey, if you’re one of the very few people in the world with the intelligence and chops to make a strong cryptographic primitive, this is my wishlist! And, yes, I really appreciate that most cryptographic primitives out there are public domain. AES was perfect when I was making a secure random number generator for MaraDNS 1.x, and RadioGatún was perfect (tiny, able to easily compress entropy from various sources with variable amounts of entropy-per-bit, fast, 32-bit compatible and easily adapted to 64-bit environments, and derived from PANAMA with a proven record as a secure stream cipher) for my needs when I originally designed Deadwood back in 2007.