I feel sick, but not as sick as I could feel. Update: Duke 67, WVU 73. Sigh.

Ben Laurie celebrates the publication of RFC 5155. I hadn’t gotten around to blogging about it, but I’m also pretty happy that this RFC finally made it out. Ben says:

It turns out that in general, to prove the nonexistence of a name using NSEC you have to show at most two records, one to prove the name itself doesn’t exist, and the other to show that you didn’t delegate some parent of it. Often the same record can do both. In NSEC3, it turns out, you have to show at most three records. And if you can understand why, then you understand DNS better than almost anyone else on the planet.

One of the fascinating things about working on NSEC3 was that it forced us to really understand how existence in DNS works. Basically, we had to develop the general form of the theory when we already had a special case (in NSEC). So, after we figured out how NSEC3 had to work, we actually knew more about how NSEC worked. For me and our co-editor Roy, this RFC culminates the 2nd round of working on the some of the problems that NSEC3 solves. The first effort was “DNSSEC Opt-In”, now published as an experimental RFC, RFC 4956. (That effort was also tied up in DNS minutiae and political wrangling and ultimately failed to make the IETF standards track). For us, it feels more like the culmination of 7 years of work.

I’m at the IETF this week, and so I get to turn my brain to thinking about IETF-y things, like Internet Drafts that I think should (and could) be written.

Idea #1: Cache Poisoning Resilience

This would be a draft that describes steps beyond RFC 2181 that a resolver must do to protect itself from cache poisoning. (RFC 2181 addresses this problem by introducing credibility rules in section 5.4.1.) Modern caching resolvers need to do more to protect themselves from name poisoning attacks like malicious CNAME chains. I would expect this draft to be able to lay out a few simple rules like:

• Discard any RRs in a response that are “irrelevant” (i.e., answer RRs that do not match qname/sname, addtional RRs that don’t match names in the RDATA of answer and authority RRs, etc.)
• Discard any RRs in a response that are not at or below the queried zone.

Update: A draft similar to this was written in 2009 by my friend Wouter: draft-wijngaards-dnsext-resolver-side-mitigation-01. However, it doesn’t appear to address my suggested rules.

Idea #2: Authoritative Servers Should Not Chase CNAMEs

This is a draft discouraging authoritative servers from chasing CNAMEs out-of-zone (or, optionally, at all), based on conclusions presented in draft idea #1. This draft could either side-step or confront other possibly controversial things about CNAME processing, like whether or not the authority section should apply the head or the tail of a CNAME chain.

Idea #3: DNS Name Compression Standards

A draft mandating the DNS name compression only be done in one direction. Virtually all (or perhaps even actually all) implementations have DNS compression pointers only pointing to earlier in the message. This draft would propose that forward-pointing compression pointers should be treated as format errors. This would accomplish two things:

1. Simplify what implementers need to support when parsing messages, and
2. Outlaw any possibility of having to deal with a compression pointer loop.

And, in the process, effectively codify standard practice.

It has been ages since I’ve blogged, and at least one of my four subscribers reminds me of this regularly. So, here goes. I’ve come home pretty late from work, and I’m pretty uninspired when it comes to assembling some sort of dinner. After staring at the fridge fruitlessly for a while, I’m struck by an inspiration of sorts. I’ll make bachelor chow.

Now, I have no idea what is in the original bachelor chow (nor do I want to know), but my bachelor chow is just the name I’ve given to the worst thing that I cook for myself on purpose. So, here is the basic recipe:

Makes one serving:

3-4 oz. pasta, preferably penne, but anything will suffice.
1/4 jar pasta sauce, any tomato-based variety.
Shredded cheese. I use Sargento’s 4-cheese mexican.

1. Cook the pasta. You can salt the water, but I’ve been running periodic experiments with not salting the water, and so far, I can’t really tell the difference. It is even less important with this recipe, since taste is clearly not high on the agenda.
2. Prior to completely cooking the pasta through, drain the pasta. Overcooking it is OK, undercooking it sucks, though, so err to the side of too long. Deposit the pasta into a microwave-safe plate or bowl. You know, the dish you are going to serve this on.
3. Optionally stir in a little bit of olive oil and salt (preferably kosher or sea salt). You can stop right here and have a pretty good dish, even if it is nutritionally unbalanced. It is only going to get worse from here.
4. Pour the (cold) pasta sauce over the pasta. Do not stir it in, just let it sit on top.
5. Sprinkle the shredded cheese on top. Again, no stirring.
6. Microwave on high for 2-3 minutes, until the cheese has melted.
7. Enjoy. Or, at least, Tolerate.

This recipe violates almost every thing I’ve learned about cooking, but it takes me back to my just-out-of-college days when I was equally as lazy and less polluted by cookbooks, Cooks Illustrated, and Food Network.

In contemplating a move back to Linux for my day job, or at least a future where more of my work is done directly on my Linux box, I began to pine for decent anti-aliased fonts for Emacs. Both the windows and mac builds of Emacs 22 have this support built-in. Although, good luck trying to figure out how to change the font to what you want, at least in Carbon Emacs. Fortunately the default font of Monaco is pretty good (albeit not perfect). I don’t have a lot of experience with EmacsW32, even though I do have it installed somewhere. At first, I was puzzled as to why Emacs just didn’t come with anti-aliased fonts on Fedora 7 by default. Some web searches led me to believe that support was to be merged in before Emacs 22.1, and there I was, running 22.1. Alas, I had misread the interweb. If support has been merged in, it has been merged in after 22.1. Since 22.1 is the latest stable version of Emacs (as of this writing), it isn’t all that surprising that Fedora 7 doesn’t have this. Ah, well, time to move to the bleeding edge. Concise instructions for building a CVS version of Emacs with anti-aliased fonts can be found on the XftGnuEmacs page. I didn’t have a whole lot of trouble building and installing this version, but what I really want is a Fedora 7 package to replace the delivered packages. If I were running Ubuntu, this wouldn’t be much of a problem. So far, my attempts to hack the existing source RPM for Emacs haven’t met with much success. It doesn’t help that emacs take a while to compile, and I keep having to completely start over. I’ll update this entry if I ever get an rpm built.

Update: I’ve managed to work through the major issues, so here is the source RPM for Fedora 7. I’ve put some actual binaries here. This version doesn’t replace the stock Emacs-22.1. Instead it installs into /usr/local, but can easily be made the default version via the alternatives command:

alternatives --set emacs /usr/local/bin/emacs-23.0.0

Now that I have a working version of Emacs with anti-aliased font support, I’ve been hunting down what font to actually use. Bitstream Vera Sans Mono is a good default, but at the moment I’m trying out Anonymous. For the curious, the bit of elisp that I’m using to set the fonts is this:

(if (eq window-system 'x)
    ;; if we have the Xft-enabled version of emacs...
    (if (>= emacs-major-version 23)
    (progn
      ;; note: Anonymous doesn't come with Fedora.  You can get it here:
      ;; http://www.ms-studio.com/FontSales/anonymous.html
      (set-default-font "Anonymous-10")
      (setq bvsm10 "Bitstream Vera Sans Mono-10")
      ;; unfortunately, anonymous doesn't have bold or italic
      ;; so, use bitstream vera sans mono for that
      (set-face-font 'bold (concat bvsm10 ":weight=bold"))
      (set-face-font 'italic (concat bvsm10 ":slant=oblique"))
      (set-face-font 'bold-italic
             (concat bvsm10 ":weight=bold:slant=oblique"))
      ;; ...and no proportional font, for that matter
      (set-face-font 'variable-pitch "Bitstream Vera Sans-10")
      (add-to-list 'default-frame-alist '(font . "Anonymous-10")))
      ;; otherwise...
      (progn
    (set-default-font
     "-*-lucidatypewriter-medium-r-*-*-14-140-*-*-*-*-*-*"))
      )
  )

I’m doing it this way (instead of in X resources) so that launching Emacs-22.1 will still work. If you stick with Bitstream Vera Sans Mono (or DejaVu LGC Sans Mono which is very similar), then you won’t have to bother with overriding the bold, italic, and bold-italic font settings as those will basically just work once you set the default font. You would still have to deal with overriding the proportional font, however.

Meaningless stream of comments here.

Over the past few days I’ve read not one, but two articles expressing the hate toward bluetooth headsets. And for both articles, I realized that it was misplaced hate. The authors (and commenters) actually hate the way that some people use them. That is, the whole standing around and talking to yourself thing. Fair enough, but some of us just want bluetooth headsets so we don’t have to keep buying special, vendor specific headsets, and yet also don’t want to hold the phone up to our ear for the whole hour-long conference call.

Since I was thwarted in my one lame attempt to get an iPhone, I ended up getting a standard-ish Nokia flip phone. This was supposed to be my “backup phone”. I’m not sure when I would have used the backup phone (when I sent my iPhone in for service? When I didn’t want to take the iPhone with me to a dangerous neighborhood?), but it didn’t seem too wasteful to have a unit to use when the primary phone wasn’t working. Of course, now that I’ve had this Nokia for a few days, I keep liking it more. It fits in my pocket. I can sync it with the Mac via bluetooth. It gets decent reception. It sounds fine. I can use a custom ringtone. (I’m not at the moment, however). It ain’t perfect, but it is working for me. I do miss the calendaring, password safe, and games from the Treo. But, I never did really use that thing to its full potential, so stepping down from the smartphone is working out fine.

Yesterday, my trusty Treo 650 decided to go crazy. OK, I think, I had it for two years, time for something new. Time for an iPhone! Alas, today is a day when the iPhone appears to be mostly out of stock. So, let me describe the particular form of crazy that my Treo has become. I first noticed it last night. I was outside, and it was raining (although not directly on me). I look at the Treo, and it is, for some reason, trying to sync via cable. Cancel. It tries to sync again. It is in an endless loop of syncing. It is acting like it has the sync cable plugged in, and the sync button permanently pressed. After several resets to no avail, I give up and remove the battery for a few hours. Now it doesn’t try to sync all the time (although, it still tries sometimes), but it also doesn’t turn on when asked, either. I’ve tried everything up to and including the data-erasing hard reset with no change. Hopefully, I’ll be able to get an iPhone soonish. I don’t want one bad enough to get it from ebay…

Update: instead of getting an iPhone, I’ve gotten a Nokia 6102i with no contract. Nothing at all like an iPhone, but it is a credible phone. I may change my mind if I’ve got to take it overseas, though. By paying for the phone and not getting a new contract, I do still reserve the right to get an iPhone in the not-too-distant future.

Step…

1. Discover Black Ink. It has a 30-day trial period
2. Try for 30 days. Like in the beginning, like at the end.
3. Buy it. I go the the online store and pay via paypal.
4. Wait for 3 days. See credit card charge go through.
5. During this time, fail to check the spam traps.
6. Wait for 4 more days. Nothing from Red Sweater Software.
7. Send email to support@red-sweater.com asking for actual registration code.
8. Wait 3 more days. Silence.
9. Discover that somehow, searching for “red-sweater” in Mail.app doesn’t find mail in the spam folders.
10. Eventually find 3 emails from Daniel Jalkut with your registration code.

Hmm.. The online store page says “…usually within a few minutes”. Is two weeks to wait long enough? I guess after that I’ll be reversing the charges. Or something.

Update: All fixed now. I am somewhat amazed that posting to my blog was an effective means of communication. I’m guessing this reflects more on Red Sweater Software’s customer service diligence than anything else.

Update[2]: So my friend Sean summed this whole event up as: “You posted to your blog, Daniel Jalkut read it, said ‘check your spam box, dumbass’, and now you look like an idiot.” Yep.