Author: Dean

dudders: Dynamically Updating DNS Duly Embracing RSA SIG(0)

For those of us with dynamic IP addresses at home (assigned via IPCP/PPP/ADSL) it’s nice to have a stable host name for remote access. My previous solution was to use dyndns, which uses an HTTP-based protocol to update a subdomain of one of dyndns’s domains. However, I preferred to use my own domain.

As I try to use cool crypto wherever possible, the public-key based SIG(0) from RFC2931 seemed like a nifty protocol to use. The usual tool for generating keys is dnssec-keygen, and for performing updates it’s nsupdate, both part of ISC’s BIND. I set this up and tested it from my MacBook Pro, where it worked fine.

However, since a WRT54GL router running OpenWRT controls my PPP connection, and thus knows when my IP address changes, the logical place to be running nsupdate was on this router. Unfortunately OpenWRT’s nsupdate (packaged as bind-client) is relatively large at 439186 octects; add to this libopenssl and bind-libs, and I’d run out of room on my JFFS2 partition. If you have the room, it’ll work for TSIGs: Ignace Mouzannar describes how to do it. However, even when I got it installed, I couldn’t make it sign a SIG(0) request. Chip Rosenthal has also noticed problems, and came up with an HTTP-based solution to get another host to run nsupdate, called web-nsupdate.

My solution? Write my own client in C, that can read the “dnssec-keygen“ key files. Presenting dudders: my lightweight DNS UPDATE client. It even comes as an OpenWRT ipkg. It still needs a crypto library, but it can use libgcrypt which (even after dependencies) still weighs in lighter than libopenssl.

Brainfuck: a pilgrimage

This is a re-post with minor edits of a static webpage I had on an old, almost forgotten server; I’ve backdated it to match the ctime.

In the winter of 2003, my last year at high-school, I fell into the wonderful world of Brainfuck. This quickly turned from an interest, to an addiction, to a pilgrimage.

With tertiary-entrance exams due in a month, what was I to do but write a brainfuck interpreter in brainfuck. Using 8 instructions, an interpreter, and emacs, I coded myself into a state of delirium.

Ouch.
Ouch.

Yes, it took me a few hours (mostly between midnight and sunrise), but here it is: the brainfuck interpreter in 446 bytes of brainfuck. There’s a longer 456-byte version that doesn’t mind comments. Daniel informed me that he’s got a new, unreleased interpreter down to 425 bytes; and that making the same non-standard assumptions I did would shave his old interpreter down to 362 bytes. Ah well.

In doing so, I found that the ENSI Brainfuck Standard v1.3 could benefit from some reform to allow for conformant and standardised brainfuck interpreters written in brainfuck. Daniel has quite good general guidelines in his Epistle to the Implementors page. However, I’m inclined to disagree with some of the conventions there that seem to have arisen out of needless tradition rather than best practices (why, oh why 30,000?). But it will do for now ;)

Part of my disagreement with the arbitrary 30,000 comes from implementing brainfuck on platforms with limited memory. I wrote an interpreter for my TI-86 calculator.