Chortle 0.24 released

Now that I have a little bit of a breather after releasing Deadwood 2.6.03 (we’re getting pretty close to having Deadwood 2.9.01 with full recursive DNS support), I am wrapping up a couple of little projects I put on the back burner while working on 2.6.03.

One project was backporting the memory leak fix to the 2.5 branch of Deadwood, which I did this morning. My next little project has been to make a monospace version of the Chortle font; this isn't a true monospace font; all I have done is run a script that squashes the wide letters and centers the narrow letters so they are all the same width.

In addition, I have removed the Bold Italic version of Chortle. In all honesty, Chortle has a regular weight, a bold weight, and an italic version, as well as the monospace version; it doesn’t need a bold + italic weight.

Chortle 0.24 can be downloaded here:

http://samiam.org/fonts/Chortle/

Deadwood 2.5.03 released: Memory leak plugged

While working on Deadwood 2.6.03, I found a memory leak that affects the 2.5 “stable” branch of Deadwood (but not the 2.3 branch); I have backported the plug for this memory leak to the 2.5 branch of Deadwood and have just released Deadwood 2.5.03:

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

As an aside, the 2.5 stable branch of Deadwood is going to no longer be maintained when Deadwood 2.9.01 is released, hopefully in a week or two. I only made the Deadwood 2.4 and 2.5 stable branches because the fully recursive Deadwood code was taking longer than I expected, and I wanted a version of Deadwood taking advantage of all of the infrastructure I was building up for use until I had a fully recursive Deadwood out the door.

Now that I am very close to having Deadwood be fully recursive, there soon will no longer be a need to use Deadwood 2.4/2.5. I will maintain Deadwood 2.3 for the foreseeable future, since it nicely fills the niche of an open-source tiny (32k) little non-recursive caching (or non-caching if you prefer) DNS server.

That in mind, this release of Deadwood does not include a TCC version for easy compiling on Windows; people who want to compile Deadwood in Windows without installing MinGW (or Cygwin, for that matter) should compile Deadwood 2.6.03.

---

Google search fail: Around 2007, Stephen G. Hartke made some freely available fonts and put them up on a Geocities page. These fonts were then rounded up by the various “download this font” websites out there (Font Squirrel, etc.). Because of how Google indexes pages, the sites that mirrored the font appear first in the Google’s search results.

This would not be a problem, except for the fact that the GeoCities page has since been taken down. It took me 30 minutes of searching to find the official page for Stephen G. Hartke’s fonts (most notably Aurulent Sans).

My general experience is that Google has not handled the expansion of the internet in the first 2000s decade very well. It used to be that search results would quickly put you on interesting pages made by enthusiasts with truly useful content. These days, searches for things like obscure video games or what not will pop up a list of pages for the topic in question on the same small list of websites which happen to have a high Google ranking, regardless of whether the page in question has any interesting content. It often times takes a lot of digging around to find actually useful information.

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/

Why C programming experience is relevant

One thing I have noticed in American culture and the US
job market is that you really can't get experience without a job, and you can’t get a job without experience. It’s even worse in the technology sector: There are a lot of, quite bluntly, clueless HR and headhunters out there who don’t understand that someone who has programmed in C for over 20 years but has programmed in PHP for three months is probably a better programmer than someone who has programmed in PHP for a year, but has no other programming experience. Or heaven forbid, if a job candidate tells someone “OK, I’ve never programmed in Ruby, but I have programmed in C for 20 years, Perl for over 10 years, PHP for a couple of years, as well as a number of other programming languages. I’m sure I can pick Ruby in a day or two”; to a clueless HR person, the person can’t do the job if it has “Ruby” in the job title.

The fact of the matter is this: C is hard (free the mallocs, close the open sockets, no native string handling, etc.). DNS is hard. Recursive DNS is really hard. Thread-free recursive DNS is even harder. Thread-free recursive DNS in pure C is a downright pain in the butt. I have done some of the work that is in vogue right now: PHP and other scripting, as well as some GUI development. All of that is a cakewalk compared to the work I am doing in MaraDNS right now.

Asking someone who has written a fully recursive DNS server in C (and, for added benefit, is almost done rewriting said fully recursive DNS server to not use threads) whether they can write a PHP script or a GUI application is like asking someone who can drive a large truck with a manual transmission if they can drive a compact family car with an automatic transmission.

That said, one reason why some companies don’t like programmers with a lot of old-school experience is that they want younger people (it lowers health insurance premiums), or they feel that they can’t teach an old dog new tricks. In my case, I program in C (not C++, not Java, not Objective C, but plain old C) not because I like the language (I don’t; PHP and Python as well as Java are far easier to program in) but because there is a tradition in the open-source world of writing programs in plain C: It proves that the developer can do the truly hard programming.

I am an old dog, yes, but I can learn new tricks: I very quickly picked up PHP when I needed to use it, do use Python in MaraDNS (the BIND zone file converter is written in Python, and MaraDNS’ as well as Deadwood’s configuration files use Python-compatible syntax), and have been using Perl for over a decade. Programming languages have been getting easier to program in (I’m glad I don’t have to program in 6502 assembly any more), not harder, and a good programmer is a good programmer. Regardless of the language he is programming in.

Another cheap netbook

Another cheap netbook out there is the Augen E-go (available in Blue, Red, and Silver), which is available for $109. It appears to come with a demo version of Softmaker Office, which quite frankly, is the best office suite you will get on this computer.

The only low-cost non-x86 netbooks which one can purchase appear to run Windows CE. There was, at one point, a “Elonex One T” which ran Linux, but that computer is no longer available.

chain_id actually will not work

Thinking about it some more, chain_id will not work. The problem is this: Let us suppose we have the following process for resolving example.com:

• The root servers at 127.0.1.1 says the .com servers are at 127.0.1.2
• The .com server at 127.0.1.2 (ns.com) says the example.com server is ns1.example.net
• The root server at 127.0.1.1 says the .net servers are at 127.0.1.3
• The .net server at 127.0.1.3 says the example.net server (ns2.example.net) is at 127.0.1.4
• The ns2.example.net server at 127.0.1.4 says the ns1.example.net server is at 127.0.1.5
• The ns1.example.net server at 127.0.1.5 says that example.com is at 127.0.1.6

Let us suppose that we, at the same time, ask for both example.com and ns1.example.net.

We will now have ns1.example.net in the process of being resolved; this process continues when we get the glueless NS referral ns1.example.net in the process of resolving example.com.

So, at this point, the example.com resolution process has its own chain_id (lets make it “1”) while the process to resolve ns1.example.net has another chain_id (lets make it “2”). For our “use chain_id to stop resolution loops” idea to work, both resolutions now need the same chain_id. Since these chains can be fairly long and since multiple resolutions (such as resolving “www.example.com”, “blog.example.com”, and “ftp.example.com”) can use the same glueless resolution, we potentially might have to change a number of different chain_id values.

This is getting hairy.

It is far simpler to not use chain_id. We can stop loops by simply using recurse_depth; if recurse_depth exceed 32, we give up on solving a given query. Every time we follow a glueless NS referral or an incomplete CNAME chain, we either:

• Create a new resolution process with its recurse_depth being the “parent”’s recurse_depth + 1
• Connect to an already existing resolution process; when this happens, we increment both the parent’s and child’s recurse_depth.

Doing things this way is far simpler than trying to use chain_id.

Another thing: We need to add a “ns” dw_str to the resolution process; this will store the particular glueless ns record we are in the process of resolving.

(As an aside, the latest Deadwood snapshot can resolve glueless NS referrals if the A record in question is already in the cache)

How Deadwood will do glueless NS referrals

“Glueless NS referrals” is when a DNS servers gives us the name, but not the IP, of a given DNS server which is “closer” to the answer we seek.

In order to handle glueless NS referrals, we will have to perform some recursion to resolve them. Since Deadwood uses the select() model, the recursion has to be handled by hand. In addition, since we do multiple in-flight merging, things are a little more complicated.

Here is my current plan:

• We will add three numbers to each outgoing recursive request: recursion_depth (int; can be 16-bit or bigger), parent_id (int 16-bit or bigger), and chain_id (32-bit)
• recursion_depth is how many times we’ve followed a glueless NS record (or incomplete CNAME referral); if this exceeds 32, we stop.
• parent_id is the ID of the request that needs to be solved before we can continue solving this DNS name. For example, if we ask for www.example.com, and the .com DNS servers tell us, without giving us an IP, that the nameservers for example.com are ns1.example.net and (say) ns2.example.net, we hold the current request, and make the parent ID one solving ns1.example.net. Called “parent_id” because multiple recursion attempts might be trying to solve the same name at the same time, but a given recursion attempt only has a single parent_id
• chain_id This is a unique 32-bit number. When we spawn a “parent” request, we first make sure there isn’t a request already in-flight which would cause a loop. This is done because, when spawning a “parent”, the parent has the chain_id as the “child” request; if we find a request already in-flight with the same chain_id, we consider it a loop and give up.

Glueless NS referrals will be a little complicated to implement with Deadwood, but this is the last major hurdle before we have full recursion (we will also use the same code to handle incomplete CNAME referrals).