rob
This user hasn't shared any biographical information
Homepage: http://www.spoofedpacket.net
Posts by rob
spoofedpacket.net signed (again)
Mar 2nd
For real this time
My previous attempts at signing spoofedpacket.net fell into disrepair and the zone expired soon afterwards, since I was doing everything manually. However, the whole lot is automatically managed by OpenDNSSEC now, apart from the KSK rollover of course. But there are some clever things you can do to fix that, with the DelegationSignerSubmitCommand.
So here’s the current trust anchor for spoofedpacket.net in DNSKEY format, and in
DS format.
Unfortunately, joker (my registrar) don’t appear to be accepting DS records at this point. So neither of the above are in the wider DNS even though .net is now signed. However, I did register mechazawa.net with godaddy, who are currently accepting DS records through their somewhat clunky interface.
Stub/local zones and DNSSEC in Unbound
Dec 17th
I have a couple of local DNS zones on my home network that are served from a BIND running on the same machine as my Unbound resolver. It listens on a different address, so Unbound, being the default resolver for the network, is configured to forward all requests for that particular zone to BIND.
This has worked fine, until I enabled the signed root in Unbound. Suddenly, the entire local zone was being treated as bogus, since, obviously, it appears nowhere in the root. This was manifested as SERVFAIL responses and general badness on the network – including my NAS losing it’s DHCP address whilst I was watching an episode of Full Metal Alchemist: Brotherhood….not good.
After scanning down through the sample unbound.conf, a simple solution presented itself:
domain-insecure: "localdomain"
This tells unbound to put up with the fact that a particular domain may be bogus/insecure, and life goes on. It could be argued that it’s not a good idea to let some domains be treated differently than others when it comes to DNSSEC, but I think it’s good that the developers of Unbound had the presence of mind to include a solution to this particular corner-case.
exim vulnerability
Dec 13th
Here’s something I haven’t seen in a while, a remotely exploitable root hole.
Debian and Ubuntu ship exim as their default MTA, so there could potentially be a lot of vulnerable machines out there.
The fixes are detailed here. Both Debian and Ubuntu have since released updated packages that fix (one part of) the vulnerability, so it would be a good idea to do a quick “aptitude dist-upgrade” if you run either of these OSes.
The unstoppable Yamato
Nov 18th
There’s been a lull in this blog recently, I’ve had a few draft posts queued up but haven’t quite gotten around to finishing them. So, I thought I’d post a quick capsule review of the new (ish) Space Battleship Yamato : Resurrection movie. This is mostly nicked from a post I made to the “What are you watching…?” thread over on the Eirtakon forum.

Apparently, this is the first Yamato movie in about 26 years and one of the last things made by the series’ co-creator Yoshinobu Nishizaki before he was killed in a boating accident a few weeks ago. Ironically, after falling overboard from a ship called “Yamato”.
For those who may not know, Nishizaki and Leiji Matsumoto created Space Battleship Yamato in the mid 70s. To say it was a hit would be a huge understatement. The show went on to spawn 2 sequels, 5 (?) feature-length films, a ton of merchandise and a huge cult following outside Japan in the form of Star Blazers, as it was called for the english-dubbed version. Crucially, it inspired a new generation of anime fans who went on to become creators themselves. For a better insight into the whole phenomenon, Corn Pone Flicks have recently produced a fantastic documentary.

But, back to the film at hand. After Yamato/Star Blazers’ phenomenal success throughout the 70s and into the 80s, at some point Nishizaki and Matsumoto had a falling out, the rights to the show became disputed and several court battles ensued. However, Nishizaki seemed to remain obsessed with the idea of re-making Yamato, for monetary or artistic reasons…or both, sometimes with horrifying results. Things finally came to fruition late last year.
The plot would be familiar to anyone who’s seen either the series or the films – a space-born menace threatens to destroy earth, in this case an oddly purposeful black hole. In the face of the approaching black hole that threatens to gobble up the entire solar system, the citizens of Earth are slowly being evacuated to a friendly planet in gigantic fleets of “emigration ships” that can carry 100s of millions of people. Unfortunately, an alliance of aliens (who look pretty much like humans) aren’t too happy with the prospect of new neighbours and have been ambushing the colony fleets. Which means that the World War II battleship Yamato needs to be pulled out of retirement to guard the emigration ships on their long journey, in order to save mankind. Honestly, you’d think the old crew would throw their hands in the air at this point – it’s about the fifth time this has happened.
Despite the oft-recycled plot, I was very impressed. It’s been in the works, in one form or another, since about 1994. The legal battles may have delayed its completion. But as is sometimes the case with troubled productions, a superior product has been delivered.

We’ve got gigantic fleets of emigration ships performing slingshot maneuvers around the edge of a black hole, battles with trans-dimensional beings, noble enemies, even nobler deaths and of course the Yamato back on the big screen – one of the most iconic symbols in anime. All this is done in CG that can be a little jarring at times, but certainly not as intrusive as it could have been.
It just goes to show you can’t keep a good series down, even if it takes 26 years.
dwm and swarp
May 27th
One thing that I really like about dwm is that if you have multiple monitors it treats them somewhat like independent instances of the window manager. So you can keep your mail client open on one monitor and switch between your terminals and web browser on another, and vice-versa.
However this also applies to the mouse pointer, it does not move across when you switch monitors. Of course you may not always want this, but it’s sometimes handy to have the option. I believe that the gottox branch of dwm had this pointer-switching functionality, but dwm-gtx doesn’t seem to be actively maintained these days.
Enter swarp, another tool from the suckless bag of tricks. It’s a simple utility that “warps” the mouse pointer to a given coordinate on your screen.
To get it working with dwm, simply download the tarball, uncompress, compile and install. Like everything else from suckless the dependencies are tiny. Test it out from the command line by specifying different coordinates. Once your happy with the locations that the pointer jumps to, you can add these commands to your dwm config.h to switch from screen to screen:
static const char *warpleft[] = { "swarp", "100", "500" };
static const char *warpright[] = { "swarp", "1500", "500" };
Now you need to bind the commands to a key, I use the Windows key as a modifier for a lot of things since it is generally unused:
{ WINKEY, XK_w, spawn, {.v = warpleft } },
{ WINKEY, XK_e, spawn, {.v = warpright } },
Because my monitors vaguely face west and east, I chose w & e as the switching keys
As usual, compiling, reinstalling and restarting dwm will apply the changes.