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.