I recently plugged in the old KORG Poly800. One of the early mass produced polyphonic Synths.

Unfortunately the batteries had drained, and the sound settings were completely gone. Now it is possible to restore the sound settings from the 20 year old cassette tape, if you a) would be able to find the original tape, and b) would have a cassette player. Unfortunately I have neither.

There are two ways you can go about this. Either you can restore all original sound settings manually from the documentation (pdf here) or you can download a “wav” file with the original program from the POLY800 cassette. Connecting the Poly800 to your computer and fiddling a bit with the output level took me about 5 minutes.

I gave in.. after mucking around with LifeType for a few years I decided to migrate my blogs to wordpress. Dan Rooke’s plog import plugin helped me to port all the posts. While I managed to get both the net-dns blog as well as this one running from the FreeBSD port install using the Virtual Multiblog plugin.

After the usual tweaking of themes I’m done and I hope I can stay away from the actual install and configuration for a while.

In Geoff Huston’s recent ISP Column “Roll Over and Die?”, Roy Arends made a thorough analysis of the behavior of Unbound in the face of increased traffic towards authoritative servers after a failed key-rollover.

Key of Roy’s analysis is the observation that Unbound holds back after finding a bogus DNSKEY but does that on a per query instead of a per zone basis.

The default value of 60 seconds causes UNBOUND to restrain itself. However, since its a per-message cache, it only restrains itself for that qname/qclass/qtype tuple. Hence, if a different query is asked, UNBOUND needs to validate the response, sees a bogus DNSKEY in the cache and starts to re-fetch the dnskey keyset. In other words, a lame root key will cause DNSKEY queries for every unique query seen per 60 second window.

We will address this using a caching mechanism that will treat DNSSEC validation failures on a zone wide basis instead of treating them as intermittent RR-set failures. That should reduce the traffic to authoritative servers significantly.

The reason why this particular problem is interesting is that, as developers, we are constantly trying to make the tradeoff between the ability to recover from failure and the costs that those recovery mechanism impose on third parties. Failure to validate a signature can have many reasons, varying from misconfiguration or synchronization failure at the authoritative side, to on-path failure or attack, to misconfiguration a the receiving side. In this case we have not been conservative enough when making the trade-offs.

The fact that these sort of issues are identified are a healthy sign of what is still early deployment and we are eager to learn from these experiences. We use two resources for gathering experience that can help us making implementation choices: the IETF DNSOP working group and OARC. OARC is an organization where data is collected and shared so that impact of certain implementation behavior is quantified. We would like to ask people to contribute measurement data and share experiences.

Back to the particular issue of stale keys. The column points out that there are mechanisms to prevent stale keys being retained after a key rollover: the mechanism described in RFC5011. As of version 1.4.0 Unbound has native support for maintaining the trust-anchor for key-rollovers based on RFC5011. We have also made “autotrust” <link> available for cases where trust-anchors need to be maintained and Unbound is not used.

In the particular case described in the columnm, RFC5011 methodology might not have worked; an old OS distribution carrying a stale key that is several generations old cannot be tracked using RFC5011 techniques. Wijngaards and Kolkman have been working on a proposal to fix that particular issue: “DNSSEC Trust Anchor History Service

Beef Wellington is a dish made with a fine piece Tenderloin (‘Ossehaas’ in Dutch). It is a good piece of meat for days with festivities because part of the preparation can be done in the morning (they take about 30 min) and part of the preparation can be done approximately one hour before the dish is to be served. Since it needs to sit in the oven for about 30 min+ 5-10 min resting time. You have a time slot to prepare for your vegetables.

Early in the day.

Clarify butter.

Starts off by preparing ‘Duxelles’. A dry mixture of finely chopped shallots and mushroom.

500 gr finely chopped mushrooms

3-4 shallots finely chopped shallots

4 tablespoons of Madeira (you can use Port wine too)

4 tablespoons of cream

Fry the shallots and mushrooms in the clarified butter until all moisture has evaporated from the mix. Then add the Madeira and the cream. Keep steering until the mix occurs dry. If the mix is to wet it will interact badly with the dough in bad ways later.

Next step is to brown the beef (a Tenderloin of 1-1.5 kg). As always with beef use a heavy pan (high heat capacity), make sure you use plenty of fat (also heat capacity) and keep moving the meet around while browning it. In about 5 minutes your beef will be golden brow. Let it rest for at least 10 min (but you can allow it to cool down until the afternoon).

Timewarp

About 1 hour before serving you will need to finish the Duxelles by mixing it with about 125 gr of Pate de Foix Gras d’Oi. Then take your beef and cover the lot with the Duxelles.

Now take sufficient leaves of prefab (ouch) puff pastry and stick them together with egg-whites. You should have sufficient area to cover the whole beef. Put the Beef on top of the pastry and close the pastry. Put the lot on a piece of baking paper with the puff pastry seams down.

Cut a few figures and put on top. Cover with egg-yoke in order to achieve a nice color. Bake in the oven for about 30 minutes and let rest for another 10 minutes.

Although the result is seemingly trivial this cartoon was a bit of a challenge as I was trying to get a Manga look and feel. Both sketching and inking and the digital post-processing took some practicing and a few retries.

The puny-code and the two big characters represent the word “Manga”. The name of the protagonist in this cartoon ‘Ringo Kun’ is written in the head band. The name is a obscure reference… a bit of a bad joke actually.