Saturday, July 31, 2010

MaraDNS 1.4.04 released

Now that Deadwood is feature-complete, I have released MaraDNS 1.4.04. This is the most current stable release of MaraDNS; if using an older MaraDNS, please update to this release (yes, I ran a bunch of SQA tests so anything that worked before should work in 1.4.04).

While the old recursive code is still in place to allow people to slowly make the transition to using Deadwood as their recursive DNS server, Deadwood 2.9.02 is included. The Windows version of MaraDNS has had its documentation updated to encourage people to use Deadwood for recursion instead of MaraDNS; I will also start nudging *NIX users along.

I have also, as blogged about yesterday, made a tool for getting entropy from the OS and putting it in a file. This is currently a very simple tool; it makes a random 64-byte file called secret.txt which MaraDNS and Deadwood can use. It acts like a UNIX command: There is no user interface; when it is run, it just silently creates the 64-byte random secret.txt file, overwriting any already existing secret.txt, and only outputting something if something goes wrong.

It’s a lot better than the old “just type in some random text to make secret.txt” directions I have given. I plan on making it a little more friendly (failing if secret.txt already exists, and stating the secret.txt file has been created, and always pausing and having the user hit a key so they know what the program is doing if called from the GUI.)

In addition, I fixed the bug with delegation NS records and ANY queries, as well as incorporating a NAPTR bugfix I made a few months ago in to the code. There is a full changelog.

It can be looked at here:

Or here:

Friday, July 30, 2010

Deadwood and MaraDNS now have a Windows tool for making secret.txt

Deadwood and MaraDNS now both have a tool for getting entropy (random numbers) so that the file secret.txt is automatically generated. I call the tool "mkSecretTxt", and its source code can be looked at here:

Or downloaded as a C source file here:

The file is a Windows port of the following *NIX command:

dd if=/dev/urandom of=secret.txt bs=64 count=1

In English: My program creates a 512-bit (64-byte) file called “secret.txt” using CryptGenRandom() to acquire the entropy from the Windows operating system.

This tool will make it easier for people to install and use MaraDNS and Deadwood in Windows, since they only have to run this program once to get some entropy for the servers’ random number generators.

Thursday, July 29, 2010

Deadwood 2.9.02 released ; keep on testing guys

I have released Deadwood 2.9.02 today. This is Deadwood 2.9.01 with bugfixes and documentation improvements. In more detail, here are the changes since 2.9.01:
  • Script to apply patches against one version of Deadwood to make the next Deadwood release made (based on similar MaraDNS script; this is something I have implemented now that the code is feature-complete and ready for general testing)
  • INSTALL.txt updated to not mention DwMain (Deadwood's older name; issue reported on mailing list)
  • DW_MAXIPS increased to 128 (issue reported on mailing list)
  • Spurious debug message removed
  • Documentation updates (root_servers more fully described in man page; more questions and answers added to FAQ; fixes things I saw myself and reported on mailing list)
  • Bug reporting policy update (you better have a stack trace or be able to reproduce a crash; otherwise I can’t use the bug report. No current issue; but I have had stuff like this with MaraDNS. Any joker can pretend Deadwood is crashing, but I won’t believe you without proof)
  • Issue getting “SERVER FAIL” when AAAA query points to non-existent AAAA fixed. (Reported on mailing list)
  • Issue when we get a “ CNAME ; A” packet (where “” is a CNAME for “”) fixed. (Found this one during my own “dogfood” testing of Deadwood)
  • Deadwood for Windows now built using MinGW 3.4.2 instead of MinGW 3.1.0 (issue found by myself and discussed on mailing list)
It can be downloaded here:

As an aside, now that I’m visibly actively working with users again so we can find and fix bugs together, I have been getting a lot more private email asking for MaraDNS support. I don’t mind this email (I’ve come to accept it’s a natural consequence of MaraDNS becoming popular), but you’re going to get the “pay me or take it to the list” form reply (I’ve come to accept people will occasionally get all worked up I don’t provide free support; I forward such lusers [1] on to the list, like I warn people I may do in my form reply, for our collective amusement).

I hope some of the people sending me this kind of email pay me for MaraDNS support; I can use the money. Or better yet, get me a real job with a living wage. Now that MaraDNS 2.0’s recursive resolver is feature-complete, I hope to have time to master OOP, Java, and whatever other buzzwords I need on my resume to get the job to support my beautiful wife.

[1] Someone who doesn’t read the “no free private email support” disclaimer at the bottom of the MaraDNS web page, as well as on the webpage with my email address, not to mention at the bottom most postings I make to the mailing list, and then flames me in response to my form reply asking for money [2] gets a LART in the form of me going public with their email. Especially since the form reply says, very clearly at the top, that I may forward their email to the MaraDNS mailing list.

[2] It doesn’t just ask for money. It also lets them know they can get free support by posting it to the MaraDNS list.

Wednesday, July 28, 2010

Deadwood snapshot update

Since Deadwood is in beta-testing, the changes at this point will by and large be bug fixes. That in mind, I am going to start announcing Deadwood snapshot updates on my blog again, since they are more interesting for end users than “I’ve started work on converting the code to handle NS referrals”, “I’m making more progress on converting the code to handle NS referrals”, “I’m making more progress on converting the code to handle NS referrals. No, it doesn’t work yet, but, really, I’m making progress”, “Yet more progress on converting the code to handle NS referrals”, etc.

Today’s snapshop fixes the bug reported in a mailing list posting. [1]

I have fixed the bug, but I’m not 100% happy with the way I’m fixing it, as described in this mailing list posting.

Anyway, people can look at both the patch (in the “update” directory) and the patched Deadwood here:

Update: I have updated this with a better patch that, instead of deciding all SOA records are always “in bailiwick”, has it so bailiwick tests are only done if the record is determined to be a NS referral. See here:

- Sam

[1] The guys at need to fix things to recognize a name on the From: line is UTF-8 encoded when it says it’s UTF-8 encoded. “From: =?UTF-8?B?U2ViYXN0aWFuIE3DvGxsZXI=?=” is “Sebastian Müller”, not “Sebastian Müller”.

Friday, July 23, 2010

Upstream replies to Debian bugs

Since a number of MaraDNS users use the Debian bug tracking system to report MaraDNS bugs, I have just gone through a number of old Debian bugs. The ones with distribution-specific issues I have ignored, but here are my replies to issues I, as upstream, are responsible for:

Bug 477787: MaraDNS 2.0 will have full IPv6 support. I have just made a beta-test release of the relevant code (MaraDNS 2.0's up-and-coming recursor, Deadwood) and encourage people to test it and report bugs on the MaraDNS mailing list.

Bug 484466: If MaraDNS is run using the duende daemonizer, sending MaraDNS a HUP signal will stop and restart MaraDNS, reloading all configuration and zone files.

Bug 486497: It's a really bad idea to bind MaraDNS to, but if you insist on doing it, it can be done if csv2_synthip_list is set.

Bug 507591: This issue was never present in MaraDNS 1.2, and has been fixed in MaraDNS and MaraDNS 1.4.03. If Debian versions of MaraDNS still have this bug, they need to incorporate my fix, or, better yet, upgrade to or 1.4.03.

Bug 525188: Just this last day, I have released Deadwood 2.9.01, which is the daemon that will become MaraDNS 2.0's recursive resolver. This daemon fixes a number of long-standing issues MaraDNS 1.0's recursive resolver has, including CNAMEs pointing to AAAA records.

This particular issue is one that I will not fix in MaraDNS 1.x (IPv6 does not have wide adoption yet, and MaraDNS 2.0 should be out there by the time it does), but it has already been fixed for MaraDNS 2.0.

Bug 573970: There are no plans to add this to the authoritative MaraDNS code, but the up-and-coming MaraDNS 2.0 release will use a separate daemon for recursion called Deadwood (I just released the first beta-test version of this daemon this last day), which does support "includes" via Python-compatible execfile("filename") syntax.

All other bugs appear to be Debian-specific OS issues. The next time I look at Debian bugs will probably be in a year or two.

Thursday, July 22, 2010

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 (, 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:

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.

Firefox does pretty agressive DNS pre-fetching

As I am performing some real-world testing with the (hopefully) soon-to-be-released Deadwood 2.9.01, I discovered something interesting that Firefox does.

The copy of Firefox 3.6.4 I have [1] in CentOS 5 looks at all of the links on a given page I am reading, and uses DNS to look up the hostnames of all of the links. This way, if I click on a given link, I don’t have to wait for the DNS lookup to be performed. I can see why Firefox implemented this.

Anyway, I usually don‘t announce snapshots here, but I am very pleased that Deadwood is finally, after nearly three years, a fully recursive DNS server. Snapshots are here:

Look in the snap directory for the latest snapshot.

Todo before releasing Deadwood 2.9.01:
  • Make a quick Deadwood FAQ
  • The usual Deadwood SQA regressions I do before any release
(Footnote follows)

[1] Yes, I know, the current version is Firefox 3.6.7, but I’m using CentOS 5, whose most current version of Firefox is 3.6.4. Out-of-date versions of programs is a very common problem in Linux, since the distributor of a given program has to approve and then send a program downstream before the users of the distribution get the update. It’s worse with CentOS, where a given update has to get approved by RedHat, then, in turn, processed by CentOS before it gets here.

One issue I have had a lot with MaraDNS is that people sometimes email me or post to the mailing list bug reports for issues I have already fixed, but the user in question is using the version of MaraDNS that comes with Debian or whatever, which hasn’t been updated.

Monday, July 19, 2010

Some thoughts on Rijndael

When I heard that the Rijndael block cipher was selected as the algorithm for the Advanced encryption standard, I was so excited I sent one of the creators of Rijndael a very excited email.

OK, I should probably explain this in more layman’s terms. AES—the advanced encryption standard—is the standard cipher people use when people get a clue and realize they need to use strong cryptography and not ad-hoc schemes to protect data. WEP used RC4 instead of AES, and was soon broken; this has been replaced by WPA2, which does use AES. Indeed, the wireless packets being sent to publish this blog are encrypted with AES. The blu ray discs sitting on the player in the other room are encrypted with AES (this is another form of cluelessness, since cryptography only makes it inconvenient, not computationally infeasible, for the intended user of a piece of media to copy said media. The way you stop piracy is by teaching freetards integrity and morals, not with cryptographic ideas that will never work). AES is the most secure way to make web sites encrypted with https.

I liked Rijndael more than the other contestants because it was a good deal more flexible. Rijndael was designed with something called the wide trail strategy that allows components to be readily replaced or modified. For example, it is possible to change its block size; all other AES candidates (with the exception of HPC and possibly RC6) had a fixed block size of 128 bits; Rijndael can have a block size of 128, 160, 192, 224, or 256 bits. Or, if desired, it is relatively straightforward to make an unofficial Rijndael variant with a 32, 64, or 96 bit block size.

It is also possible to change its S-box if one feels Rijndael is somehow too algebraic.

Another thing that is possible to do is to make a Rijndael variant using 64-bit instead of 32-bit integers. If this is done, the variant’s “natural” block size is 512 bits; this can be adapted to have a block size of any multiple of 64 bits from 64 to 1024 bits (64, 128, 192, 256, 320, 384, 448, 512, 576, 640, 704, 768, 832, 896, 960, or 1024 bits). The dirty work of coming up with magic constants for a 64-bit Rijndael variant has already been done with the Whirlpool hash; the only constants we need to pull out of the air are the “shift row” constants.

The Rijndael/Whirlpool variant with a 1024-bit block size has a large enough block to be used in a “sponge function” mode of operation. A cryptographic sponge allows any significantly large random-looking permutation to be used as the code of a hash function or stream cipher (it’s a hash function with an arbitrarily long output). We can use a 1024-bit block size cipher as a sponge to generate a 256-bit hash, or by having things be twice as slow, a 384-bit hash (For people familiar with sponge constructions: The 256-bit hash is done with a “capacity” and “rate” of 512 bits; the 384-bit hash is done with a “capacity” of 768 bits and a “rate” of 256 bits).

Another idea that has been implemented is both 64-bit and 128-bit Rijndael variants where the encryption and decryption operations are identical—useful for minimizing code size in implementations where encryption and decryption are both supported. We give up block size flexibility when we do this (the 32-bit version needs a block size of 128 bits, but the 64-bit version can have a block size of either 64 bits or 512 bits). This has been implemented with Anubis (32-bit words, 128-bit block size) and Khazad (64-bit words, 64-bit block size; can be modified to be a 512-bit block). In addition, there is a proposed 128-bit word size primitive (PDF file) that could be used to make either a 128-bit or 2048-bit Rijndael variant using the same operations for encryption and decryption.

Rijndael has a couple of issues. One is that the key schedule is not as strong as it could be; this has resulted in their being an academic weakness called a “related key attack”. This does not result in any practical security problems; a related key attack is one of the hardest to utilize in the real world (cipher keys are usually hashed using cryptographic hashes). Indeed, the website describing this attack on Rijndael uses, of all things, Rijndael to encrypt traffic.

The other issue is that in an optimized implementation, Rijndael uses a lot of table lookups, which make it vulnerable to an attack called a “cache timing attack”. A cache timing attack could be used by an adversary with limited access to a system running Rijndael encryptions to determine a Rijndael key used elsewhere on the system. The attack is right now a purely academic attack; no one has seen it used by a real-world adversary, and some processors (such as the ARM) series can thwart it with cache lock-down. With the AES instruction set now a reality, these attacks will soon be a non-issue.

So, yes, Rijndael is a very nice, very flexible cryptographic primitive.

Saturday, July 17, 2010

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
  • Poor handling of unresponsive name servers (,
  • 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:

Friday, July 16, 2010

Wesnoth's RNG has statistical weaknesses

All of the people playing Battle for Wesnoth complaining about Wesnoth’s random number generator (RNG) having problems were right.

There is a test used called the “minimum distance” test which tests a random number generator by filling up a volume of space with points determined by the random number generator and determining the minimum distance between any two points. Or, in other words, we take a cube, fill it with points “randomly” by using the RNG we are testing, and make spheres of each point and the point closest to that point. The smallest such sphere is our minimum distance. We do this a number of times.

There is a range of minimum distances we should have. But, with Wesnoth’s random number generator, we don’t get that, especially in four dimensions (it also fails in three dimensions) [1]. A good randomness tester like Dieharder can readily distinguish Wesnoth’s RNG from a good RNG (such as RadioGatún).

The reason for this is because Wesnoth’ random number generator is as follows:

static int32_t state;
uint32_t mask;

state = (state * 1103515245) + 12345;
mask = (state >> 16) & 0x7fff;
return mask;

(The actual code uses division and modulo where I use a shifter and a logical and above).

This is a very simple Linear congruential generator, and is considered a rather poor RNG.

One of these years, I should submit a patch to replace Wesnoth’s junk RNG with RadioGatún. Although I have a feeling the developers will not accept it. It would, after all, be a pretty big blow to their pride to admit the RNG Wesnoth has been using for years has significant, measurable problems.

I should, before signing out, point out that Wesnoth is an excellent game and I appreciate all of the hard work done on it. I just wish the Wesnoth FAQ would stop pretending the random number generator is any good with nonsense like “programmers have examined the random number generator. No flaws have been found”. Because I found significant flaws in under an hour with Dieharder.

I should probably point out that Wesnoth’s RNG also flunks the “Diehard DNA test”.

[1] To properly test Wesnoth’s random number generator in three dimensions with Dieharder, I had to modify the random number generator to use a 32-bit unsigned integer and take the top 16 bits from the generator state (instead of using a 31-bit integer and taking 15 bits). The stream is identical if we remove the high bit from these 16-bit numbers to make them 15-bit numbers.

Wednesday, July 14, 2010

sudo in CentOS

I finally got sick and tired of having to, in CentOS, type in su, followed by the root password, just to run Deadwood (which needs to run as root since it needs to bind to port 53), followed by exiting the root prompt. So, I finally did a simple RTFM with the “sudo” man page and edited /etc/sudoers so that my user account can use sudo to run the program. Just like how things are done in Ubuntu.

Come to think of it, I could have used dns_port to have Deadwood bind to a unprivileged port and then just connect to that port. But, then again, I would have to add selectable port numbers to askmara (my command-line utility in MaraDNS for making DNS queries from the command line). Nah.

Now, if only there was a sudo get_me_a_job and sudo get_my_wife_a_US_visa (well, there is the second one, but it supposedly takes about a year; I need a sudo nice -20 get_my_wife_a_US_visa so they will do it faster).

Monday, July 12, 2010

RadioGatún[32] passes all Dieharder tests

Dieharder is a series of tests to test the quality of random numbers. I have installed Dieharder 2.27.12 on my CentOS virtual machine (by virtue of the fact that this is the most recent version of Dieharder with handy precompiled 32-bit binaries) and then started running RadioGatún[32] as a stream cipher through this battery of tests.

The first time I tested RG32 (my shorthand for “RadioGatún[32]”), a couple of tests were marked as poor—which is not surprising, since the full battery is some 74 tests. When a tests is marked as being “poor”, that indicates that the stream of random numbers generated have a 1% or smaller chance of not being random. A good set of random numbers will occasionally fail a randomness test, since well-made random numbers sometimes do not quite look random.

I re-ran the tests that were “poor”, first with the same RG32 seed at a different point in its stream (which resulted in having a “possibly weak” result—a 5% chance the test was not random—for a different test, which is not surprising since there are 20 tests in this section of Dieharder), then with a couple of other RG32 seeds. With the third RG32 seed, none of the 20 tests were marked “poor” or “possibly weak”.

Conclusion: RG32 shows no biases when used as a pseudo-random number generator (PRNG). In practical terms: Deadwood is using a strong random number generator.

While I was testing the quality of RadioGatún’s random stream, I tried to run the tests at, but the server gave me an “Internal server error” instead of test results. I tried with two different sample sizes (one about 130 megs in size; the other about 18 megs in size).

I should note that RG32 is quite fast, even with the code-size-optimized implementation I made for Deadwood. Compiled with -03 in GCC, I got 20 megabytes of numbers in three or four seconds. cat /dev/null gives me 200 megabytes of zeros in the same amount of time.

Update: Using the rg32 seed (hash input) of “dieharder7&rdquo, Dieharder 2.27.12 passes all tests; again, random numbers should sometimes fail a randomness test, but they don’t with this particular seed and particular version of the full Dieharder test suite.

Sunday, July 11, 2010

Windows does have /dev/random

You know, I spent too many years reading Slashdot. I somehow got the impression that Windows did not have a good source of cryptographically strong pseudo-random numbers. While true for Windows 95 and Windows 98, this has not been true for years.

Microsoft Windows has had, since Windows 2000, a form of /dev/random/ called CryptGenRandom(). Indeed, it appears that MinGW/Msys have the required wincrypt.h header file for supporting this function.

I will have to, once I get the DNS resolution bugs fixed, set things up so Deadwood uses CryptGenRandom() for some of the entropy for random query IDs and ports, and not require a secret file.

Saturday, July 10, 2010

ObHack 006.9 released

Fritz and I have made another release of ObHack. Fritz has done all of the hard work updating the program; my contributions consist of verifying there are no viruses in the Windows binary (with AVG) and making the .zip file and source code .7z file.

It can be seen here:

Since Andrew hasn't come out with an OBLIGE release in a while, this should whet people's appetites for having an updated Doom random map generator.

As always, I do not support ObHack; please do not post to this blog ObHack support concerns--they will not be approved.

Update: A more detailed changelog and support for ObHack 006.9 is available in this Doomworld discussion.

Friday, July 9, 2010

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.

Wednesday, July 7, 2010

Deadwood update: I have found some bugs

Just letting you all know that I have, from a single day of casual web surfing, found a number of host names that don’t resolve correctly with Deadwood 2.6.04. I will be working on fixing those this week.

There is no need to send me bug reports about Deadwood 2.6.04. I am already aware of its bugs.

I should probably note that Deadwood has much more solid code that MaraDNS 1.0’s recursive resolver did at this point back in 2001; the bugs I’m seeing are SERVER FAILs and hostnames resolving incorrectly. The bugs MaraDNS 1.0 had during this phase of development (good enough to start using on the real internet for recursive resolution) caused crashes.

Tuesday, July 6, 2010

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:

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; 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.

Sunday, July 4, 2010

On CNAME records

I thought handling incomplete CNAME records would be really easy once I had support for glueless NS referrals.

I was wrong.

I can understand why DJB took some shortcuts with CNAME records in DJBdns. CNAME handling is pretty much the last thing I’m adding support for in Deadwood, MaraDNS 2.0’s recursive resolver. It’s like I have been running a 40 kilometer marathon and I’m within 50 meters of the finish line. I just want to run as fast as possible to the finish line and end the marathon.

So, yeah, I’m making some shortcuts with CNAME referrals. DJB has it so that CNAME records are not stored at all in the cache. Deadwood right now stores CNAME records in the cache, but only when the CNAME record is completed. For example, if I ask for, which is right now an incomplete CNAME record that points to, Deadwood stores the completed version of with the IP for in the entry for, but only when we get all of the information.

In addition, the CNAME records before the final answer ( in the above example) have a fixed TTL of 60 seconds (which doesn’t mean anything); the final answer has a fixed TTL of 3600 seconds (one hour).

Right now, incomplete CNAME records only work if the record the incomplete CNAME points to is already in the cache. Resolving this is hopefully easier than getting CNAME records already in the cache working was; I think I have mostly done this when I got glueless NS referrals to work.

Another thing: If the resolution of an incomplete CNAME record is needed to handle a glueless record, the resolved record will not be used to help solve the parent query that needed the glueless record until that query is sent to Deadwood again. I may or may not fix this before releasing MaraDNS 2.0.

OK, back to finishing up incomplete CNAME referral support. I will hopefully have Deadwood 2.6.04 out in a few days.