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

OK, there’s still a few people using UUCP

As I mentioned yesterday, I was going to send an email to see if UUCP is still being used.

Mike @ MV communications promptly replied and let me know that, yeah, they still have a few active UUCP accounts around, but admitted their UUCP users probably have the accounts mainly for nostalgia purposes.

So, yes, UUCP still exists, and is still being used. A little. A very little.

Why MV offers UUCP access

The reason why MV communications still offers UUCP access is because, in their words:

We continue to offer this because it's how we began, but truly we don't expect much interest here. But if you know what it is and want it, we still offer it!

I have to email them and ask them if anyone actually has a UUCP account these days.

Deadwood 2.6.02 released: Non-glueless recursion

Deadwood, after over two years since its initial release, is finally starting to have support for DNS recursion.

In the release of Deadwood, a subset of DNS names will recursively resolve: Names that do not require glueless NS records to be solved or incomplete CNAME records to be finished.

Here is my current roadmap for Deadwood:

• Add support for solving glueless NS records (This will be 2.6.03)
• Add support for finishing incomplete CNAME referrals (This will be 2.6.04)
• Add support for ANY records — have it so the “in bailiwick” tester understands any RR type is OK when an “ANY“ record is asked for (This will be 2.9.01 — the first feature-complete recursive release for testing)

As always:

http://maradns.org/deadwood/

Look in the “testing” directory for Deadwood 2.6.02; look in the “TCC” directory for the source code for the Tiny C Compiler the deadwood-tcc release uses.

I wonder if anyone still uses UUCP

Once upon a time, a dedicated connection to the internet was very expensive. You needed a serious military contract to afford it. So, universities and home users used something called UUCP to access the internet.

This was when the most commonly used services on the internet were e-mail and something called “Usenet”. Yeah, sure, there was other stuff like something called “IRC” (like MSN, but text-only and not as friendly), and, yeah, FTP, but the cool stuff on the internet happened via email or over Usenet. UUCP allowed you to cheaply access the internet, but only for e-mail and Usenet news.

UUCP was cheap because it allowed you to call up your internet provider and download, in one batch, all pending email and Usenet messages for you, while uploading any email you sent or Usenet articles you posted. If you didn’t subscribe to any high-traffic newsgroups, you could upload all of your email and Usenet “news” in a single five-minute or at most ten-minute daily modem session with your internet provider.

It was a simple way of accessing the internet, and until the explosion of the World Wide Web in the mid-1990s, gave a full internet experience.

Looking around on Google, it looks like a couple of internet providers might still provide UUCP access to the internet. This page looks promising, although I wonder how many active UUCP accounts they still have. There is also this listing, which is nearly a decade old, as well as this page, which, again, looks like an out of date webpage that probably needs to be purged.

I have made a number of references to UUCP over the years, including this blog posting or this recent posting to the MaraDNS mailing list. While I have never actually used UUCP for internet access (it was considered old-fashioned and out-of-date 16 years ago), I had something similar for a short while when I set up Leafnode to read Usenet offline in the early 2000s.

The cheapest new netbook out there

Browsing through shopping.google.com, there is one, and only one, really affordable netbook out there: The LY-EB01. This is a tiny 7 inch netbook with an ARM processor running Windows CE, complete with an ancient version of Internet Explorer and a version of Word that doesn’t even include a spell checker.

A number of $100 netbooks have been promised over the years (starting with the computer that inspired the Netbook revolution, the OLPC computer); this is the first $100 netbook to make it to market.

I think this netbook would make a nice little platform for running Linux. It might not be possible to run Firefox on this critter, but Dillo should run fine (heck, Dillo runs reasonably well on a mid-1990s netbook-sized Gateway Handbook 486 with only 20 megs of ram and 150 megs of hard disk space). FVWM1 should run just fine; I wouldn’t try running Gnome on this critter.

This would be a good little computer for editing documents with vi and posting to Usenet using your favorite text-based Usenet client (wait, no one uses Usenet anymore...), as well as reading email using Pine, or Alpine these days.

Unfortunately, no one has bothered making a Linux port for this platform yet. NetBSD might get a port before Linux has one.

There are a number of used and “refurbished” netbooks in the $100-$200 range; the next price point for a brand new Netbook is $230 for an eMachines Netbook.

Deadwood milestone reached: Recursion is starting to work

Finally, well over two years after starting the Deadwood project, recursion is starting to work. The operative word is “starting”; Deadwood is not ready for general testing yet. However, I was able to resolve “google.com” starting from the root name servers with the latest Deadwood snapshot today, since no glueless NS referrals need to be followed to resolve that name.

That in mind, here is a TODO list for releasing Deadwood 2.6.02:

• Make sure we don't follow any referrals if we're following an upstream server. Make sure RD is set to 0 if talking to a root server, and 1 if talking to an upstream server.
  
• Show an appropriate error message if we try to follow a glueless NS referral or CNAME referral.
  
• Run all of the SQA regressions in the 32-bit and 64-bit compiles of Deadwood, starting with the 32-bit compile. Fix things.
  
• Make a good default hash value for the tarball, and which will be in our source release.
  
• Make sure it compiles in Windows, both under MinGW and with TCC.
  
• Once all of this is done, make the 2.6.02 release: Source tarball, Win32 binary (.zip, .7z), and TCC .7z source release.
  

As always, snapshots can be looked at here:

http://maradns.org/deadwood/

A cool Windows stopwatch application

After wasting my time with a couple of nagware or otherwise annoying stopwatch applications, I finally found a no-nagging free (complete with source code) simple stopwatch program:

http://www.keithv.com/software/stopwatch/

Perfect for keeping track of how long I’ve been on the phone with my wife (we have a plan where we can call each other for free — but only if we talk for under five minutes per call; this application makes sure I don’t go over).

Placing text ads on samiam.org or maradns.org

Every now and then, I get someone who sends me an email wanting to participate in a "link exchange program" or to pay me a little to place a text ad on one of my websites.

For example, about a year ago, during the worst of the recession, I had someone offer to pay me a little money to place a text ad up on maradns.org and samiam.org. The person insisted that the ad be permanent. I told him I wasn’t going to do that; he got agitated and I finally handled it by ignoring the person. Nothing is forever.

I finally have come up with a policy and pricing structure for these people (the price is, yes, a little high, but that is a case of giving invoice therapy):

The fee for a simple text-based ad on samiam.org is $50 per month. The fee for a simple text-based ad at maradns.org is $100 per month. This fee is paid by sending money to my PayPal account; the text ad will be placed after 100% of the first month's fee is paid. This fee is to be paid in full one week before the first day of the month when the text ad appears. The fee is not prorated; if you wish a text-based ad to be placed immediately, you must pay for the entire month.

Please allow up to seven calendar days for a given text ad request to be processed.

Multiple months can be paid for, but fractional months are not allowed (I would just pocket the extra money). There is a 10% discount if you pay for an entire year's worth of text-based ads.

Anyone willing to pay this fee will be listed as a sponsor on the MaraDNS list of sponsors for the foreseeable future; this listing will include the content of your text-based ad.

Simple text-based ads will be placed at the top of the content area of the "portal" page before my main content, and separated from my content with a <hr> HTML tag. Text based ads can include links, but the only other markup allowed is italics.

All text-based ads must be approved by me before being placed on my site; any changes to text-based ads are subject to prior approval. Text ads for pornography or advocating any illegal activity (as per US law) will not be accepted. Fees paid for rejected text ads are non-refundable.

Why I don’t do free private email support

Every now and then, I get someone who gets really angry at me when I give them the “pay up or take it to the mailing list” form reply from me after sending me a request for unpaid private MaraDNS support. This is not very good for the user in question; since the form reply makes it clear I can make replies to my form letter public, they end up publicly embarrassed when I forward their rude email to the MaraDNS list.

The reason why I don’t do unpaid support is because MaraDNS is an open-source project. Open source fundamentally changes the customer-supplier relationship; the thinking behind open source is that I supply something that benefits the community as a whole. The community, in return, benefits MaraDNS.

If I answer a private MaraDNS support email for free, I am not doing anything to benefit the MaraDNS community. I am only benefiting one particular user of MaraDNS.

MaraDNS users with support concerns should help MaraDNS by either paying me (which encourages me to work harder on MaraDNS), or by making their support concern public; this way any reply to their email is public and the next person with the same concern can quickly find the answer to their question in the MaraDNS mailing list archives.

MaraDNS and Deadwood now use RFC4193-compliant example IPv6 addresses

MaraDNS and Deadwood now use RFC4193-compliant example IPv6 addresses:

http://maradns.org/download/1.4/snap/2010/
http://maradns.org/deadwood/snap/

The prefix I use for all examples is “fd4d:6172:6144:4e53”, which is 0xfd followed by “MaraDNS” in ASCII.

New MaraDNS snapshot: NAPTR record bugfix; IPv6 examples changed

You know, it’s always a little embarrassing for me to have a bug in my code. A part of me wishes I was perfect and did not make mistakes, and has the notion it reflects poorly on me if a piece of code has a bug in it — even though it plain simply is not humanly possible to make a program as complex as a DNS server without any bugs.[1]

There was a bug in the code that parses NAPTR records that makes it impossible to parse NAPTR records unless the ~ is not used to separate records. The workaround is to not use the ~ to separate records in zone files with NAPTR records; the fix is available here:

http://www.maradns.org/download/patches/maradns-1.4.03-naptr_parsebug.patch
http://www.maradns.org/download/1.4/snap/2010/maradns-Q.20100512.1.tar.bz2

In addition, today’s snapshot of MaraDNS now uses fecf:aff0 as the prefix for all example IPv6 addresses instead of 3ffe:ffff; fec0::/10 was once assigned to “Site-Local scoped” addresses and there is no way the IANA is ever going to use this space for IPv6 Unicast addresses; I use fecf:aff0 for loopback IPv6 addresses for Deadwood testing (why they didn’t assign an entire /16 or /32 to loopback in IPv6 is a mystery to me; multiple loopback addresses are useful).

- Sam

[1] If you’re an ignorant DJB fanboy who still thinks DjbDNS is perfectly secure and has no bugs, you’re wrong.

New MaraDNS snapshot: NAPTR records documented

I have finally documented NAPTR records in MaraDNS, and made a new snapshot with NAPTR records documented:

http://www.maradns.org/download/1.4/snap/2010/
http://www.maradns.org/tutorial/man.csv2.html

This resolves the issue brought up here:

http://woodlane.webconquest.com/pipermail/list/2010-April/000535.html

Luffa: Another SHA-3 candidate hash that’s also a stream chiper

I have listed before some hash functions that also work as stream ciphers; it would appear that the SHA-3 submission Luffa is a hash function that can output an arbitrarily long hash and be used as a stream cipher.

Also, LUX and MeshHash appear to have some cryptographic weakness and neither made it to round two of the SHA-3 competition; Luffa, however, did make it to round 2.