I'm trying new colors for MaraDNS.org

I am designing a new color scheme for the MaraDNS website. I have decided the contrast on the current website is a bit harsh and am striving to have something with less contrast and brighter colors. It can be previewed here.

Thoughts?

I will look at it over the weekend to see if the colors work; if they do, I will update the web page early next week.

I'm taking a break from Deadwood/MaraDNS

I'm just letting everyone know I'm taking a break from Deadwood and MaraDNS this weekend and will not start development again until next week sometime.

People can use Deadwood 2.3.03 (stable) or 2.4.02 (testing) in the meantime.

Some more research with OOP in C

OK, it is possible to do some crude OOP-type coding in C. This page discusses the basic technique. That in mind, I am going to have to go through DwHash.c, and separate out the code that adds stuff to the hash from the code that puts new hash elements in the fila and deletes elements if they are expired, sets the expire time of the hash element, etc.

The advantage is this: If I can pull this off, it will make it so the DwDict and DwHash both use the same code; we just add a dwd_autogrow() function to DwDict and use the simplified hash/dictionary managing routines in DwDict.c.

This is going to take a few days; I am planning things out right now.

Blue Ray: Prices dropping like a rock

The prices for both blue ray burners and blank blue-ray media is both dropping like a rock. A couple of years ago, a blue ray burner set you back about $500 and a blank disk (25 GB) was at least $10. Doing some research today, blue ray burners are under $200 and blank disks are between $3-$5 each, depending on which brand you get.

Dual layer blue ray discs (50GB) are still well over $20 each. Speaking of dual-layer, it looks like dual-layer DVD blanks are slowly dropping in price; a dual-layer DVD blank is between 80 cents to $1.25 in price. I've seen generic single layer DVDs for as little as 15 cents a blank; the price is usually somewhere between 20 or 30 cents a blank when bought in spindles of 50 or 100.

CDR blanks are between 15 and 20 cents a blank; single layer DVD blanks is the cheapest price per byte to store data, but dual layer is quickly catching up and Blue Ray should be the way to go in a couple of years.

I'm really glad Blue Ray won myself; I can't think what advantages HD-DVD had. It's big disadvantage was less capacity; an HD-DVD blank could only fit 15 GB of data, but a blue ray fits 25 GB of data.

Deadwood roadmap

My next phase of Deadwood development consists of some significant under-the-hood changes to the code that handles "dictionary" variables. Right now, the code is a simple list that doesn't scale; indeed, upstream_servers can only have a maximum of 96 elements.

My plan is to take the hashing code used for Deadwood's cache, and adapt it to be usable for the simpler cache used for upstream_servers and other dictionary variables:

• This is a variable sized dictionary, not a fixed-sized cache. This in mind, I need to add the ability to grow the dictionary as more elements are added to it, and not use any code that removes elements as the cache fills up.
• There is no ability to remove elements from the hash, just add elements
• Hash entries do not expire; once an entry is in the hash, it stays in the hash

The fact of the matter is that I'm hitting the point where I would be better off writing this in C++ instead of just regular C; in C++ I could make a generic hash an abstract class, then add the methods to make the dynamic "dictionary" used for things like upstream_servers as one derived class, and the methods to remove elements when the cache is full and what not as another different, but similar derived class.

Deadwood 2.4.02 released

OK, Deadwood 2.4.02 has passed all CentOS Linux 5 regressions (I had to increase the timeout in the sqa_tcp test; all other tests were OK), and has been compiled and runs in Windows. That in mind, I have just released Deadwood 2.4.02.

This is a testing release of MaraDNS; testing releases have been internally tested, appear to work, but the emphasis is on adding new features, not fixing bugs while otherwise leaving the codebase unchanged.

The stable branch of Deadwood is Deadwood 2.3; Deadwood 2.4 is where the lion's share of development is happening. Compared to Deadwood 2.4.01, the following features have been added:

• upstream_servers can now let one have different servers process subtrees of the DNS space (such as having one's internal DNS server handle names ending in ".local")
• DNS-over-TCP is now, by default, disabled, and needs to be enabled with tcp_listen = 1 if desired
• The Windows build of Deadwood can now run without being a service (mainly for my own debugging)

It can be downloaded at maradns.org/deadwood/testing.

I found the problem

I have found and fixed the problem in Windows.

I had to make sure, when tcp_listen was disabled, to not look at possible TCP sockets when deciding which socket number was the highest socket number to select() with. Took a couple of hours to hunt down and fix this problem.

It's a good thing I keep daily snapshots around; I tried different snapshots until I figured out where things broke, looked at the changes I did (add tcp_listen support, namely), then fixed things so we can disable tcp_listen without breaking Deadwood on Windows.

While debugging this, I set things up so it is now possible to run Deadwood as a non-service as "Deadwood.exe --debug dwood2rc.txt". This is so I can more easily debug Windows-specific problems.

Anyway, I just posted a snapshot where things work in Windows. Now, it looks like the DNS servers for example.com have changed, so I have to revise that particular test. Once I do that, I will run the full SQA battery on the CentOS Linux version of Deadwood, then make the Windows binary of Deadwood (making sure things work in Windows, of course).

I should be able to release Deadwood-2.4.02 today or tomorrow.

Deadwood Windows update

For whatever reason, in Windows select returns -1 (error) with an ERRNO of "No error" in the snapshot branch of MaraDNS, but acts as expected and returns 0 in Deadwood 2.4.01.

I just have to figure out why select isn't happy. I'm sure I initialized sockets in Windows (it would have filed a while ago if I hadn't); but I'll try doing that again.

I'll release another snapshot once I figure out why select() doesn't work in Windows (it works just fine in Linux).

Deadwood update: Windows broken in snapshot

After starting up some tests to make sure the Windows version of Deadwood works, I discovered that, for whatever reason, the Windows build of the snapshots do not work. 2.3.03 and 2.4.01 work just fine in Windows; and the latest snapshot works just fine in CentOS Linux 5. It's only in Windows it doesn't work.

I will figure out what's broken and fix it; once I do that, I can release Deadwood 2.4.02.

And another Deadwood snapshot today

I got rid of the cryptic-looking error message and now have a fairly clear error message posted when people do something like upstream_servers["example.com"] = "192.168.99.98". I also make it clear in the documentation that the domain name in upstream_servers must end in a dot.

Took me maybe ten minutes, but makes life a lot easier for my users and potential users. Good code is easy to set up and get going. Deadwood suffers here because it uses a CLI instead of a GUI, but at least it's not a case of the documentation being deficient or the error messages being useless.

Deadwood snapshot update

We now show the user which domain name has problems when telling them upstream_servers has a bad value.

The error message is still a little cryptic, and the documentation doesn't point out that the dictionary index for upstream_servers must end in a ".", but at least it's a pointer to the offending name.

Next: Test in Linux and Windows, then release Deadwood 2.4.02

Deadwood snapshot update

The tests have been updated and all run. During testing, I realized that randomly choosing an upstream server makes it a little less likely we will get a reply when an upstream server is down, so I have increased the default number of times we try contacting an upstream server before giving up from two to three.

At this point, I am almost ready for Deadwood 2.4.02. All I have to do is add that error message.

More fantasy campaign settings

Some more fantasy campaign settings:

• NeoExodus (Free)
• Dwarven Halls
• Wilderlands of High Fantasy (New version)
• Endless Sands
• Aventuria
• Sovereign Stone
• Blackmoor

Deadwood snapshot update

I'm in the process of updating the SQA tests to work with the 2.4.01->2.4.02 changes I have done. Once all of the SQA tests are updated, I need to improve that one error message. Once that is done, I can release Deadwood 2.4.02.

I'll probably release Deadwood 2.4.02 tomorrow. In the meantime, I just uploaded a snapshot with the work I've been doing revising the tests.

- Sam

Fantasy campaign settings

A fantasy campaign setting is an entire world created for the purpose of playing a role-playing game (a game like Dungeons and Dragons). There are a number of these out there, some of which are listed in the Wikipedia.

I would like to expand that list with the following published fantasy campaign settings I found over at rpgnow.com:

• The Kyngdoms
• Castlemourn
• Crown
• Kitsunemori
• Legacy of Maela
• The Great City
• Aihrde
• Maelstrom
• Dark Horizons (SciFi, but it’s free)
• Fantasia
• Scarred Lands
• Kingdoms of Kalamar
• Ados: Land of Strife

There's a lot more out there; in future blogs I will post more lists like this one, and may even posts lists of non-fantasy RPG campaign settings.

Deadwood snapshot update

I've updated the documentation to reflect the new behavior for upstream_servers. I have also updated one test: dwood2rc_d_upstream_servers.

Now I have to update all of the tests to use the upstream_servers = {} line. Any test that depends on Deadwood's old round-robin rotating behavior needs to be updated to not depend on that behavior anymore; Deadwood now chooses at random one of the upstream servers before sending a packet upstream.

Since the tests to see that Deadwood is caching data are based on the old behavior, those tests will have to be redone. I will probably do this by getting a packet from upstream, stopping the upstream server, and seeing if Deadwood still answers the hostname in question.

After revising the tests, I need to improve the error messages so when the user has something like upstream_servers["example.com"] = "192.168.72.3" in their dwood2rc file, the program gives a somewhat helpful error message. I also need to make it clear in the documentation that DNS names for upstream_servers must end with a '.' character.

Then I can think about releasing Deadwood 2.4.02.

The snapshot, as always, is at maradns.org/deadwood/snap

Deadwood 2.3.03 released and snapshot update

Since MaraDNS requires lines like upstream_servers = {} before any lines like upstream_servers["."] = "10.1.2.3", I have fixed both Deadwood 2.3 and the current snapshot to be able to parse the upstream_servers = {} line without thinking it's a syntax error.

This hotfix only makes the above line parse without error; it's a 3-line change to the source code. The line doesn't do anything and I will not make it mandatory in Deadwood 2.3, so that this bugfix-only update doesn't break current existing configurations.

Note that Deadwood 2.1 will not be updated with this fix.

This release can be downloaded at maradns.org/deadwood

Some changes I will make to Deadwood's parser

One feature people have wanted for a while is the ability to include other files in MaraRC files. I will add this feature to Deadwood's parser. The syntax will be Python-compatible:

execfile("filename")

Speaking of Python-compatible syntax, here is the correct way to handle upstream servers:

upstream_servers = {}
upstream_servers["."] = "10.1.2.3, 10.1.2.4"

Unfortunately, the first line results in a syntax error in Deadwood. So, I now have the following "to do":

• Make the above syntax not cause an error in Deadwood, including Deadwood 2.3 (I won't fix Deadwood 2.1)
• Mandate the above syntax in the development snapshots of Deadwood
• Add documentation pointing out this line is now needed
• Start work on a Deadwood 2.3 upgrade guide, including a note that the above will now be needed

Deadwood snapshot update

This now works in Deadwood:

upstream_servers["."] = "10.1.2.3, 10.1.2.4"
upstream_servers["example.com."] = "192.168.199.21"

Here, anything ending in "example.com" (like "www.example.com", "www.foo.example.com", etc.) is resolved by the DNS server at 192.168.199.21; everything else is resolved by 10.1.2.3 or 10.1.2.4.

It can be seen at maradns.org/deadwood/snap

Next:

• Document
• Test
• More helpful error message when there is something like upstream_servers["example.com"] = "192.168.199.32" (no dot after "com")
• Release Deadwood 2.4.02

Deadwood snapshot update

Well, instead of implementing new features, I looked at the new code I have written and did some auditing and hardening of it. I made sure the new string manipulation functions don't write to memory without bounds checking; I have also added a new dwood2rc parameter, tcp_listen, that must be set to 1 in order to have DNS-over-TCP.

DNS-over-TCP is very rarely used; it's best to disable it by default because having DNS-over-TCP does increase the surface of vulnerability the daemon has.

I have also spell checked the changelog and DwMain man pages.

Tomorrow, I will continue work on allowing separate upstream DNS servers for subtrees of the DNS space. This should be done later this week.

The latest snapshot, as always, can be downloaded at maradns.org/deadwood/snap.

Deadwood snapshot update

Some more improvements to the infrastructure for MaraRC dictionary variables and string functions to handle DNS-style strings.

version.h now has correct version again.

Deadwood snapshot update

OK, it's time to abstract the code a little more. I need to use the same kind of "dictionary" (as it's called in Python; it's called an "associative array" in AWK, a "hash" in Perl, and a "table" in LUA) elsewhere in the code, so I'm taking the currently very simplistic [O(N) instead of O(log N) (btree) or O(1) (hash)] code and putting it in its own file (DwDict.h and DwDict.c).

I'm abstracting the data, so when I want to make the code use a different structure (probably a hash so I can reuse a lot of stuff in DwHash.c), I can fairly easily change things.

Right now, DwMararc.c still duplicates the same code, so I need to take the functions that deal with dictionaries in DwMararc.c and have them call the appropriate functions in DwDict.c (and make header files and so on and so forth).

You know, one of these days, like soon, I need to learn C++ and its templates. I know C++ has some handy dictionary code in place so I don't have to deal with this stuff. C truly is portable assembly; it's small (32k binary for the non-recursive cache), it's fast, but it's a pain in the butt to code.

Deadwood will probably be my last old-fashioned C programming project. The next language I will use will probably be C++, and might possibly be Java. We'll see.

In the meantime, people can look at this snapshot at maradns.org/deadwood/snap.

Deadwood snapshot update

I've added some more functions to handle upstream_servers being a dictionary variable, and am starting the debugging process to make sure these functions work as I intend them to work.

Some feature requests I have gotten over the years

Here are some feature requests I have gotten over the years for the recursive resolver:

• The ability to include other files in a MaraRC file
• Thread-free full recursion (Being worked on)
• The ability to take a "NXDOMAIN/Not there" reply and make it an IP
• The ability to take a response with a given IP and make it a "NXDOMAIN/Not there" reply
• More BIND-like recursive replies

I've already implemented "resurrections" and saving the cache to and from disk, in addition to thread-free operation in Deadwood.

Deadwood snapshot update

DwMararc.c overhaul; dictionary variables are now real dictionary variables with a simple API in place to have other pieces of code use dictionary variables in the dwood2rc configuration file.

Available at maradns.org/deadwood/snap

Desert Island Business card CD

One game people like to play is the "Desert Island Discs" game; basically, if you were stuck on a desert island and could only bring a limited number of discs or video games, which video games would you bring. For example, here is a "only one video game" version of this game

My version of the "Desert Island Discs" game is the "Desert Island Business Card CD" game; the rules of the game are:

• I am on a desert island that has electricity (must be a bank of solar panels), air conditioning, and an unlimited food and fresh water supply
• On said island, I have a computer with 3d video acceleration, but no software installed except a basic install of Microsoft Windows (without games)
• I am allowed to bring one CD-R with me, but the CD-R must be a 50 megabyte "business card CD" (to be exact, said CD has 26099 2048-byte sectors, or 53,450,753 bytes, the size of some batches of Ritek Business Card CDs)
• The desert island disk must be formatted as an ISO-9660 filesystem
• All music and audio must be encoded as fixed-rate MP3 files (the reason for this is because I sometimes put my business card CD-R in friends' MP3 stereos, which can only play MP3s and can't play variable bitrate MP3s)

This is a project I've been doing for a couple of years. Just yesterday I burned my latest incarnation of this desert island disk. Here is what I put on it:

• A modified version of the World English Bible
• A memory tester and Windows password reset tool
• A Cartomancy guide
• The TrueType version of my Chortle font (derived from Carter's Bitstream Charter), and two of Jos Buvivenga's excellent fonts
• The Ultimate Doom data file, using version 1.8.6 of Doomsday to play the game, and ObHack to make random maps
• David Teach's Gin Rummy program (I removed the installer since the installed files compressed are about about 5% the size of the full installer)
• 7-zip, to make other files smaller
• Deadwood 2.3.02, a DNS non-recursive cache I wrote
• MaraDNS 1.3.07.09
• MSys 1.0.10, which gives me a good subset of *NIX in a Windows environment
• A portable version of TextMaker from the free Soft Maker 2006 office suite; by getting rid of everything but the word processor, the 7zip compressed file is about 5 megs in size, and includes Spanish-language and English-language spelling dictionaries
• The songs Glyder and Muroc by Jonn Serrie from his album Flightpath (Glyder encoded at 192kbps, Muroc at 160kbps)
• A song I wrote in 1995 called Distant Vision, encoded at 160 kbps
• Some pictures of myself and my life, including a picture of me with my girlfriend
• A version of Radio Gatun and RG32 sums (sums generated using the 32-bit form of RadioGatun) of all files to verify the integrity of the CD

New Deadwood snapshot

I'm starting work on getting it so upstream_servers can take values for domains besides the root servers, allowing people to use alternate roots or have spam/phish domains use another nameserver pointing to a "this page is spam/phish" page.

It can be downloaded at maradns.org/deadwood/snap

Deadwood 2.3 and testing partial TCP sends

I tried to the tests that test TCP buffering for Deadwood 2.4 in Deadwood 2.3 and can't get Deadwood 2.3 to, at least over the loopback interface, be in a situation where send() sends less data over the TCP pipe than the amount of data we just got from a recv().

For whatever reason, the recv() call receives less bytes if doing a send() over the localhost interface would only be able to send fewer bytes. This may be a Linux kernel bug, or some side effect of doing everything over the localhost interface.

Bottom line, I can't trigger a partial send() in Deadwood 2.3. Since I still haven't come up with a testcase to test partial sends, I can't fix the issues Deadwood 2.3 may or may not have with partial sends.

It looks like partial sends work without problem in Deadwood 2.4, since the testcases here actually triggered partial sends which I was able to test and get to work.

Since DNS-over-TCP is very very rare, this issue isn't a priority right now.

So, without further ado, here's the current Deadwood 2.4 TODO:

• Make it possible to have upstream_servers for hostnames besides the root hostname (".").
• Then I should take MaraDNS' DNS compression and decompression code and port it to Deadwood's codebase.
• Next, I can think about TTL aging and resource record rotation.
• Then I can concentrate on real recursion.

- Sam

Deadwood 2.4.01 released

I have released Deadwood 2.4.01 today. This release is a complete revamp of Deadwood's DNS-over-TCP handling; instead of having a separate daemon/service handle DNS-over-TCP, the same daemon listens on both UDP and TCP, and only sends TCP queries upstream if upstream gives us a "truncated" reply and downstream is using TCP to get the DNS data.

Note that these oversized DNS packets that need TCP are not cached.

In addition, I have added full buffering to the DNS-over-TCP code and a number of tests that test this code.

For the record, now that I have made this release, I am changing the snapshot naming scheme. Instead of using deadwood-Q-YYYYMMDD-N.tar.bz2 (Q: The letter Q; Y: Year; M: Month; D: Day; N: Release number for the day), I will use two different schemes: deadwood-S-YYYYMMDD-N.tar.bz2 for snapshots of updates to the stable (2.3) code, and deadwood-H-YYYYMMDD-N.tar.bz2 for snapshots of updated to the testing (2.4) code.

Next: Backport the TCP buffering tests and add full TCP buffering (partial send support) to the 2.3 branch of Deadwood.

Deadwood 2.4.01 can be downloaded, either as source code or as a Windows binary at maradns.org/deadwood/testing

New Deadwood snapshot

I've added the tests to make sure Deadwood's TCP code buffers correctly if there's a delay sending the DNS request from the client, a delay getting the DNS reply upstream, or a delay sending the upstream reply downstream. Deadwood passes with flying colors.

Next: Deadwood 2.4.01; I just need to do some 64-bit testing, and make a Windows binary.

More on TextMaker

Now that I'm starting to use TextMaker as my main word processor, I am getting a sense of how to use it.

First of all, the UI is not always intuitive for people used to using Word. I've been using Word 2003 for a while, and there are a number of differences.

For example, when I open a new document in Word 2003 while editing another document, the Document opens as a new window. In TextMaker, the first document I'm working on is hidden and there is no indication the document is even open.

There are two ways I can see other documents open in TextMaker:

• I go to the "no longer maximize" button that is part of Textmaker in the upper right hand corner underneath Windows' own "hide"/"maximize"/"close" buttons. At this point, I can see all open documents, but they are sub-windows of TextMaker's own windows and not stand-alone windows.
• Another way to see other documents open at the same time is to go to the "window" pull-down menu at the top.

There are other things different about TextMaker's UI; to find out how many words a document has, I have to go to file -> properties and choose "statistics", instead of Tools -> Count Words.

As mentioned before, inline spell checking (red lines under misspelled words) is not enabled by default.

TextMaker doesn't have macro record capabilities the way Word 2003 does. One workaround is to download and use AutoHotKey.

It helped a lot to download the TextMaker manual and use it as a reference when editing documents.

The correct way to install foreign-language dictionaries in TextMaker is to download the dictionary add-on package for SoftMaker 2006, which, annoyingly enough, not listed on TextMaker's free download page.

SoftMaker has a forum to get technical support for their programs; there is a forum for TextMaker 2006 Windows.

New Deadwood snapshot

After looking at the code for a couple of days, I have finally got TCP buffering working to the point that the server works when getting data from a test upstream server that pauses while sending a TCP packet to Deadwood.

This version of Deadwood passes all SQA tests (including the new one that tests TCP buffering), and can be downloaded here

Next: Make sure Deadwood works when both the upstream server pauses while sending the DNS-over-TCP reply, and the downstream client pauses while getting the DNS-over-TCP reply.

Then: Release Deadwood 2.4.01

Then: Work on getting TCP partial sends working in the 2.3 branch of Deadwood.

Free office software

When people think of office software (Word Processor + Spreadsheet + more), they instantly think of Microsoft Office. However, Microsoft Office isn't the only office suite out there. There are a number of other office suites one can use.

A brief look at a few programs that are free downloads:

• Open Office. The largest most full-featured office suite out there. It's a big download, takes up about 300 megs of hard disk space, but it's the most well-known free office suite
• Lotus Symphony one well-known derivative of Open Office
• StarOffice, the commercial version of OpenOffice
• AbiWord, not an office suite but a stand-alone word processor. Open-source; The software is quite buggy (its ability to change the document's language doesn't appear to work) and I don't care for it myself
• SoftMaker Office Word processor and Spreadsheet program; free to download and use.
• Jarte, which is essentially Wordpad with spell checking (but not inline spell checking without getting the $20 "plus" version)
• Easy Office, a free open-source office suite for Windows; very old and doesn't even support long file names. Strange user interface (you right-click to change text formatting). Not recommended.
• E-Press EasyOffice (not to be confused with the other EasyOffice) Fairly large package, but the license only allows this program to be used at home; it can not be freely used at work or for work-related activities.
• Atlantis Nova, another stand-alone word processor. Crippled freeware version; doesn't even have spellcheck.

Of all of these office suites, the one I like the most is SoftMaker.

SoftMaker is not perfect; its inline spell-checking (red lines under misspelled words) has to be explicitly enabled (other -> settings -> language).

To get Spanish-language spelling dictionaries for SoftMaker is somewhat of a pain in the butt. I went to the download page for the handheld version of the office suite, downloaded the additional dictionaries .exe file, and used 7zip to extract the Spanish language dictionaries from the .exe, which I put in the "SoftMaker Office 2006\spell" directory. Once I did this I had full Spanish-language support.

SoftMaker is a nice small office suite. I will use it for a while.

Alexa top 500 list

I have made a list of the Alexa top 500 websites; any "this site does not resolve with MaraDNS" bugs with hosts that aren't on this list will not be fixed. I am in the slow process of rewriting MaraDNS' recursive code; once this code is ready for testing, I will happily deal with "this site does not resolve with MaraDNS 2.0" bugs for any and all sites on the internet (provided the sites can resolve with BIND).

- Sam

Deadwood snapshot update

I have changed the sqa_bigpacket test to no longer need BIND; it now uses the code I worked on this weekend to do the test. This will allow me to run a version of the test that adds pauses to the TCP transmission, allowing me to test TCP buffering.

As an aside, the code I have been working on this weekend doesn't work when compiled with -O3; since this is a SQA test, I will not resolve this issue but simple compile the code without any optimization.

All SQA tests work, and the code can be looked at by going to maradns.org/deadwood/snap

New Deadwood snapshot

Some more work on the SQA tools for Deadwood:

Added new SQA tool, truncated, which always returns, over UDP, a "truncated" reply.

send_packet_stdin SQA tool should now be able to have pauses in the TCP packet it sends.

Starting tomorrow, I should have more time to dedicate to Deadwood development again and actually set up and run these DNS-over-TCP tests.

Deadwood snapshot update

show_packet_stdout now has support for sending the DNS packets in parts, so we can test TCP buffering.

Deadwood snapshot update

At this point, the DNS-over-TCP testing tools allow me to test DNS over TCP without using BIND; there is one tool that reads a DNS packet over TCP, outputs that packet to standard output, then reads a packet from standard input to give back to the client (changing the ID of the reply to
be the same as what the client sent us).

The other tools reads a DNS packet from standard input, sends that packet to a DNS-over-TCP server, and outputs the reply it receives on standard output.

The next step is to have it so these tools can have pauses in their TCP sending, so I can test Deadwood's ability to fully buffer DNS-over-TCP packets.

It can be looked at here

New Deadwood snapshot

Now that I have full DNS-over-TCP support in Deadwood (we can return a DNS packet from the cache for DNS-over-TCP queries; we only send TCP packets upstream if we get a truncated packet; we send TCP packets from upstream to the downstream DNS client), I want to fully test this code. I want to make sure that the buffering code I have in place works.

The problem with my current testing setup is that sending all packets over localhost doesn't need buffering, so the buffering isn't properly tested.

Since it's difficult to find DNS packets in the real internet large enough to require DNS-over-TCP, the way I am testing things is by writing a series of tools that will (hopefully) simulate DNS servers on the internet well enough to find and fix any problems with DNS-over-TCP buffering code. This code is currently incomplete.

Note that I have a number of personal commitments this weekend and may not be able to make another Deadwood snapshot update until late Tuesday; we'll see how things go.