Late last year, Mike StJohns transcribed one of his DNSSEC-related rants into Internet-Draft form (recently expired). The name of his proposal, “Signature Only DNSSEC” has been referred to as “DNSSEC SO” in shorthand. Mike’s idea was soundly rejected by the IETF working group that it was presented to, DNSEXT. I’ll outline some theories why in a bit. But, its rejection was not because it was a horrible idea. In fact, from some points of view, it is a pretty good idea. In a nutshell, DNSSEC SO says:

• Drop the NSEC (née NXT) or NSEC3 records, and just concentrate on being able to positively verify records, and
• because successful chains of trust through zones don’t actually involve NSEC records, this can coexist with standard DNSSEC.

The draft certainly talks about other things (like off-tree chains of trust) which are interesting too, but this is the main thrust. By eliminating the NSEC records (what MSJ calls “Provable Non-Existence”, or PNE), you’ve simplified DNSSEC and, in one fell swoop, eliminated all of the angst generated by the NSEC records (leading to things like NSEC3 and on-line NSEC generation).

This isn’t to say that DNSSEC SO removes all of the Hard from DNSSEC, but it does go a long way. However, let’s take a look at the main purposes of DNSSEC:

1. Protect legacy and security-unaware Internet applications from DNS spoofing attacks, and
2. Enable new applications to use DNS as security scaffolding.

Purpose #1 is why (I believe) that DNSSEC was pursued in the first place. Purpose #2 was thought of later as a compelling reason to continue. Or rather, #2 is the reason why we would have wide-scale deployment of DNS in the absence of a highly publicized attack on the DNS.

And now we can see why DNSSEC SO was rejected: it is utterly useless for purpose #1. And, since most new applications have to live an world without universal DNSSEC deployment (SO or otherwise), DNSSEC SO isn’t as useful for purpose #2 as it might be.

Let me explain.

Standard DNSSEC (including things like NSEC3) says that DNS responses, after being validated, fall into one of three states (actually four, but never mind): SECURE, INSECURE, and BOGUS. That is: it validated and was signed; it wasn’t signed, but that was proven to be OK; and it failed to validated (for any reason). When a response is BOGUS, the response is withheld from the application. Thus, an unaware application is spared from the effects of the spoofing attack.

DNSSEC SO says that responses, after validation, only fall into two states: SECURE and NOT SECURE. That is: it validated and it was signed; or it wasn’t signed or didn’t validate. So spoofing attacks just get passed on the unaware client, which can’t distinguish them from normal DNS responses.

OK, so what about purpose #2? Imagine an application that might be aware of DNSSEC and might really want to use it for security scaffolding. Let’s call it DKIM, an application that looks up cryptographic keys in DNS for the purpose of deciding to accept or reject email. It might decide that it is only going to use DKIM keys that have been signed and verified by DNSSEC. This is great, and, in fact, DNSSEC SO works here just fine. However, at this point in time, DKIM cannot afford to restrict itself to only using keys signed with DNSSEC. Even with DNSSEC SO, it is going to take a while to get enough infrastructure in place so that any zone that wants to can be signed and trusted. And DKIM needs as many email senders and receivers to use it as possible.

…So why was DNSSEC SO rejected by the IETF? I suppose that everyone who spoke up saying “No” has his/her own reason, but my belief was that it was because DNSSEC SO rejects the initial requirement for DNSSEC, and that the initial requirement (purpose #1, above) is still valid. Also, the working group was obviously tired of working on DNSSEC, and DNSSEC SO represented another 6 to 12 month round of effort for what seemed like little gain. In other words, “too little, too late”.

That is, if you consider looking up crossword puzzle clues on oneacross.com to be cheating. Or even if you think that looking up stuff in imdb and wikipedia is cheating. I haven’t spend a whole lot of time on crossword puzzles before, mostly because I sort of suck at them. But a few days ago, I discovered Black Ink. I never tried the previous (java-based) version, but this version is pretty good. But it makes looking up stuff in oneacross (which I didn’t even know about before) ridiculously easy. And you are one command-tab stroke away from your browser and the crosswordy goodness of wikipedia, google, and imdb. I haven’t laid down the cash-money for this application yet, but if I keep going I’m going to have to.

After an afternoon of painting trim, I headed over to the nearby Chinese restaurant, Fortune of Reston. I can walk to it, and as I approached it, I realized that the sign for it was gone. Indeed, the whole restaurant was gone, stripped to the concrete floor. A little Google research later, I discover that is has actually been closed since January 7th. I guess it says something that it took me until March to notice its absence. Ah, Fortune, you will be (somewhat) missed. On my way back, I noticed that the bagel shop in the same shopping center (Manhattan Bagel) was also gone. The same Google research indicated that it had been gone for over a year. Clearly, my powers of observation need work.

I finally noticed that my TiVo was in the “Pending Restart” state. I restarted it, and bang! new version of the TiVo software (8.1.1-something!). And this version (among other things) fixes the sound issue that I was having with Comcast SportsNet DC. Of course, this happens exactly one day after the last thing I wanted to see on this channel was aired. Figures. Now my current issue (which I hope resolves itself) is that Verizon is in the process of moving all the channels around, and I’m currently in the state where some of the channel changes have been applied by TiVo, but not yet by Verizon. And (I think) some changes have been applied by Verizon but not yet by TiVo. The new TiVo software adds a bunch of features, the most interesting which are “TivoCast” and the “Recently Deleted” folder that now shows up. TivoCast is (I think) the broadband video download service that Tivo is rolling out. I can’t tell how to use it yet. If I ever visited tivo.com, I would have found it obvious how to use it. However, I guess I’m on the cutting edge of this software update, since Tivo Central Online doesn’t seem to realize that the S3 now supports TivoCast.

A few months ago, I switched to Verizon FiOS TV, using two CableCARDs in my S3 Tivo. Mostly just because it was an option, and the FiOS service was at least $10 less than my other option, Comcast. Sorry, Comcast, competition prevails! Overall, I’ve been pretty happy with this setup.

However, I have this strange problem: two channels in my lineup don’t have any sound. They look OK, but no audio, ever. Now digital cable in general, and FiOS is no exception, comes with so damn many channels that there is a significant chance that these two channels might go completely unwatched, thus, no problem. And, in fact, this is largely the case. However, it turns out that one of these channels, there are basketball games that I want to watch. Of course, sound is not strictly necessary for watching a basketball game, and, sometimes, is a hinderance. Nevertheless, it sort of bugged me that I couldn’t, even if I wanted to, listen to the audio. Enough of the mystery: the two channels (for me) are Comcast SportsNet DC (CSNDC) and Mid-Atlantic Sports Net (MASN). They are consecutive, and, suspiciously, both channels from a different cable operator (Comcast).

So, I called FiOS tech support. The friendly tech on the other end of the line tried resetting my CableCARDs (which also apparently had the strange side-effect of disconnecting my phone call), but nothing changed. After some more internal kibitzing, she decides to send a tech out my way the next day (that being MLK day). I agree to meet the tech in the afternoon. The idea is that CableCARDs are so weird and crappy, that this might be because of bad cards. This seemed unlikely to me, since both cards exhibited the problem. What are the chances that two cards fail in the exact same bizarre way? Nonetheless, I was game.

The tech, Mike, is basically on time, and pretty friendly and helpful. He swaps out my cards, and we spend a terribly long time on the phone getting a remote tech to activate the cards. Eventually, this gets done, but: no dice. No surprise there, but what now? Mike calls in to see if they can test this in the CO – Nope, no S3 Tivo there (yet, I think). Eventually the remote FiOS people blame the Tivo. Mike leaves promising to look into it further. After he leaves, I call Tivo (I wanted to confirm my service level anyway), and report the problem. The Tivo support person has never ever heard of this problem, but promises to move it up the chain. The next day (this would be…yesterday), Tivo tech support calls me and own up to the problem. It actually is a Tivo problem, that, reportedly, will be addressed in the next software update. No promises on when that will be, however. I am so amazed by the call from Tivo, that I save the voicemail indefinitely.

Check the new home page at blacka.com! Up until now, this page was about as boring as possible. In fact, I don’t know if anyone ever went there intentionally. But now it has a snazzy new look, designed by my sister. All of the photos are mine (well, taken with my camera, anyway). They represent a somewhat random sample of my meager photo collection. Mmmm, I should take more photos…

DNAME, if you are not aware, is a DNS record type defined in RFC 2672. If you are familiar with the DNS’s CNAME record, then think of DNAME as a sort of super CNAME. If not, well, I’ll try to explain how DNAME works.

A Brief DNAME Tutorial

Whereas CNAME is used to alias a single domain name to another, DNAME aliases an entire subtree to another. It accomplishes this in one of two ways: either it acts as a CNAME generator, or it is understood by the client and the client implements the same behavior without all the generated CNAMEs.

So, some examples. Imagine that this record exists in its proper place in the DNS:

www.bar.com IN CNAME www.foo.com.

This means that queries for www.bar.com, of any type (A, AAAA, MX, etc.) will get aliased to the same query for www.foo.com. But queries for mail.bar.com (for example) do not. Nor do queries for yyy.www.bar.com. Now imagine a similar usage of DNAME:

bar.com IN DNAME foo.com.

Now, the DNAME record will synthesize a CNAME for any query below bar.com. A query for www.bar.com will get aliased to www.foo.com. mail.bar.com will be aliased to mail.foo.com. x.y.a.b.c.bar.com will be aliased to x.y.a.b.c.foo.com. Everything. But, queries for bar.com won’t be aliased at all. DNAME only matches below the name, not at the name.

All in all, a pretty clever idea.

Using DNAME to Create IDN TLDs

So, let’s think of some ways that DNAME might be used. One idea that has been bandied about is to create IDN aliases for TLDs. So, for example, imagine a DNAME that maps ‘xn–c4m’ (somebody feel free to suggest a real punycoded com equivalent) to ‘com’:

xn--c4m. IN DNAME com.

The idea being that while the world wants native language versions of com, net, etc, the world doesn’t actually want them to be new TLDs (where amazon.xn–c4m could be different than amazon.com.) So, using DNAME in this way looks great: somebody who registered xn--b7r.com now gets to advertise their domain as bår.cøm (or whatever; I’m too lazy to actually use real unicode here, people). When somebody queries for www.bår.cøm, this gets converted to www.xn--b7r.xn--c4m IN CNAME www.xn--b7r.com. Not bad, not bad at all. However, what happens when the owner of xn--b7r.com starts thinking of his domain as actually “xn–b7r.xn–c4m” (or bår.cøm, since people don’t actually think in punycode…), and creates a subdomain:

xn--su9b.xn--b7r.com. IN NS ns1.xn--b7r.xn--c4m. xn--su9b.xn--b7r.com. IN NS ns2.xn--b7r.xn--c4m.

Well, what happens is that this delegation actually doesn’t work. And it doesn’t work because ns1.xn–b7r.xn–c4m doesn’t actually exist as a name in the DNS. Instead, it is gets converted into a CNAME, and NS record targets cannot be CNAMEs (This is pointed out in RFC 2181, but the real point is that resolvers won’t generally handle this case.) Note that it isn’t that the owner can’t have subdomains. It is that he can’t use the IDN TLD version of his domain the same way as the real one. So, the DNAME based IDN TLD is a second-class citizen, and will probably lead to operational problems as end users fail to realize that this IDN TLD isn’t actually a real TLD, and what the consequences of that are.

Using DNAMEs for Variants

OK, so how about another potential use, instantiating IDN variants? This is slightly different from the case above in that the idea here is to create aliases to existing second level domains as a courtesy. It isn’t really nearly as likely that someone down the road will mistake the DNAME for a real name; this is just to help people who enter a variant get to the right place.

Actually, this idea isn’t really about IDN variants at all. Imagine that you have a bunch of domains of which one is the “real” one, and the rest were just registered to keep other jackasses from registering them and defaming you. Or just registered because people might try to find you under the other domains. For an example, let’s imagine that Amazon has amazon.com (the main zone), amazon.co.uk, and amazonsucks.com, all of which Amazon wants to behave the same. Instead of maintaining a bunch of copies of the amazon.com zone, couldn’t you just leave one “real” and have the rest be DNAMEs? This would make managing these copies so much easier, wouldn’t it?

Well, yes, but…. Since the DNAME doesn’t match at itself, you haven’t aliased the entire zone, since you haven’t aliased the name “amazon.com” itself. Alas, there are always critical records stored at the apex. At the very least, an MX record. So, you haven’t really saved yourself much work, since you will (most likely) have manage the variant zones anyway, just to keep the zone apex in sync.

Another way to accomplish this task is to use the same zone file for all of the variants. BIND, at least, makes this easy: just make sure that everything in the zone is relative to the “origin”. When the file is loaded against different zones, the origin will be set to each zone in turn. (This is a bit like using all relative paths in your HTML and then having the freedom to move the pages around without changing the HTML.)

The Good News

So what is DNAME good for? The canonical use for DNAME is to move zones around in the reverse tree, typically for renumbering. This works better, because the zone apexes in the reverse tree aren’t used much (or at all). It is also useful (although not perfect) in cases where you do not control the zone that you wish to mirror.

I won’t say that DNAME is completely useless: a few people have certainly successfully used it. But, it doesn’t work adequately in situations where no other good solutions exist (IDN TLDs), And even where it does work, there is always another way to accomplish the same thing that, generally, isn’t much more work.

Also, that it has been around for six years and hasn’t seen any sort of widespread use is, at least, an indication that DNAME doesn’t solve any pressing problem.

Ever since I sprung for the (awesome) TiVo Series 3, getting two CableCARDs (and digital cable) for it has been on my “to do” list. I’d been avoiding it because of the various horror stories that I’d read about during the Series 3 launch. I figured I would give the cable companies time to come to grips with the new demand for CableCARDs.

So, earlier this month, I figured enough time had passed, and I called Verizon to order the CableCARDs and ditch the (long since unplugged) DVR/cable box. Note that to call Verizon and get anything useful done, you essentially have to call them during business hours. Otherwise you get stuck in their maddening voice response system. So I finally remember to call them during business hours, and after being transferred a few times, actually get to tell somewhat what I want: 2 CableCARDs for a TiVo. I get scheduled for 11/14. So I work from home that day. Even though it takes me most of the morning to stop swearing at my work laptop, I actually am pretty productive.

However, after 3 p.m. (you know, long after the point where you could have salvaged your day), the Verizon tech calls and informs me both that he doesn’t know what I need, and when I tell him, that he doesn’t have CableCARDs on the truck, so he can’t get to me. Grr.

I reschedule with him for Friday.

I call Verizon directly to try and connect all the dots. This is futile. That is, it appears to work, but, as you will soon see, it doesn’t work.

I spend Friday actually on vacation, but feel trapped in the house, since I have zero idea when the techs will arrive. It turns out, I needn’t have bothered. By 3:30, no one has showed, so I call the 1-800 number that I have. I’m informed of something to the effect that the order was screwed up, and could they try again on Monday (today). “Sure,” I say, already pretty annoyed. I was going to be home anyway (more vacation time). I also meant to call them in the morning to find out if anyone driving a Verizon truck even knew about me, but I forget.

Fast forward to now. Around 4, once it is somewhat clear that once again no one was going to come, I call again. This time, the human on the other end is a bit aghast at how screwed up my order is. She calls the dispatcher (this has happened every time I’ve called, except the first time, actually), and eventually tells me that all she can do is escalate. About 30 minutes later, someone from Verizon calls (apparently this is the escalation), and essentially, puts me on hold. Whee!

Currently, I’m yet again scheduled for tomorrow (11/21), this time for the morning (i.e., not an all day window). My decision tree now looks like this:

1. If techs arrive without CableCARDs, they get to take the DVR with them, and I cancel FiOS TV. They are fired.
2. If they arrive with CableCARDs and they work, then they remain hired.
3. If they do not arrive, I stop asking for CableCARDs, and just tell them to cancel, they are fired.

I actually have no reason to believe that getting CableCARDs from Comcast (my other choice–I feel lucky that I even have one) will be smooth, but it is possible that they will, at least, know how to enter an appointment into their system.

Update: SUCCESS! At the outer edge of the installation window (8am to 11am), an installer came and the TiVo is now working with 2 CableCARDs. w00t!

It was harder than it should have been because, at first, the Tivo weirded out, and I had to remove the card and reboot. Next, the installer was unable to initialize the cards via his fairly nifty ruggedized laptop with built-in EV-DO due to some sort of (office-side) configuration issue. After making a few phone calls to find the right person, he got someone on the phone who could initialize the cards, and it was fairly smooth sailing from there on out. About 40 minutes after that, I’ve re-run “guided setup” on the TiVo, and deleted all of the duplicate, spanish-language, and stupid channels.

A few weeks ago, I went to dinner with a coworker of mine, George. George is the most serious connoisseur of sushi that I’ve ever met (not counting sushi chefs themselves). We just went to the sushi place across the street, but George has developed a relationship with one of the chefs there, and that transformed the experience into something different. For one thing, this was the first time I saw someone hand-annotate the a la carte sushi menu to request a combination of sashimi, sushi, and hand rolls. Plus, we wrote in a sushi roll that wasn’t on the menu. A whole new world! Afterwards, George and I discussed our various theories of what consisted of levels, or dividing lines between various sushi eaters. First, I present my general theory of sushi diner progression:

1. Cooked sushi. Basically california rolls, cucumber rolls, and the like.
2. Raw fish (not sashimi). This starts with tuna and salmon and progress from there.
3. Differently textured raw seafood. Octopus, squid, clam, flying fish roe.
4. Sashimi.
5. Salmon roe.
6. Uni.
7. Fried shrimp heads

Basically, this is a progression from the familiar to the unfamiliar in the American palate. Obviously, it isn’t a hard and fast progression, but it roughly corresponds to my own progression and to that of other friends that I’ve seen. YMMV. George basically agreed with my theory, but insisted that it was only half the picture. The key, he said, was saba (mackerel). Now, in my progression, typical Americans will eat saba fairly early on – it is just another form of raw fish, after all. But they won’t like it. But once it becomes your favorite, and you can convince the sushi chef that it is your favorite, then the relationship with the sushi chef changes, and they start to take you seriously. Saba is apparently the first step to the Japanese sushi progression. We had saba (sashimi) that night, and I have to admit, I thought it was pretty good. Of course, we started the meal with the fried shrimp heads.

My new toy arrived about a week ahead of schedule:

(It is the thing on the bottom. Above it is the old toy that this thing is replacing). I apologize for the horrible photo. I’ll try to get a better one when I can photograph during the day. Well, at least a less gloomy day. Anyway, I bought a Tivo Series 3 to replace my aging (6+ years old!) series 1 TiVo. Of course, my series 1 still works and I was still using it, but I became gripped by The Fear, so I’ve gone ahead and replaced it. It is probably mostly that I’ve switched from a series 1, which hasn’t had a software update in 5 years, but I love this new Tivo. I don’t have it hooked up the digital cable yet, however, so there is more exploration of this thing to do.

Update: I have at least ordered CableCards from Verizon, so I may be able to get my TiVo to realize its full potential. The cards will apparently be $2.95 per month, each.