Distributing files via DNS

After publishing my Storing ASCII art in the DNS post last year, I’ve been thinking about using the same method to distribute files.

While transmitting data over DNS is not a new concept, I believe it has never been done using NAPTR records. The well known iodine DNS tunnel uses NULL resource records to transmit binary data, but I wanted something which can be used with standard tools like dig. On this topic, I’ve recently read the Internet Draft defining the SINK resource record and it seems like it could be used and abused for some fun hacks.

Back to today’s topic though. The idea behind this experiment is to encode a given file in base64, and then create a NAPTR record for each line of the ouput.

I used the following shell script to produce the zone file :

base64 rrda-1.01.tar.gz -b 64 | while read line;
	echo $1 'NAPTR' $counter '10 "" "'$line'" "" .'
	let "counter++"

Please note that this snippet was created and tested on Mac OS X. On Linux, the -b option needs to be replaced by -w to wrap encoded lines.

We can query the zone to check the content of NAPTR records :

dig rrda.statdns.org NAPTR +short +tcp

Once we get the NAPTR records content, we can strip the leading and trailing data to get our lines back in the original order, and decode the base64 data to recreate the file.

And here is a one-liner to get the original file back and pipe it through tar :

dig rrda.statdns.org NAPTR +short +tcp | sort | sed -e 's/[0-9]* 10 "" "//g;s/" "" .//g' | base64 --decode | tar xvfz -

For extra points, the zone used to distribute files can be signed with DNSSEC, in order to create a secure file distribution channel. This is left as an exercise to the reader.

RDing TEMPer Gold USB thermometer on OpenBSD

A few weeks ago, I ordered a RDing TEMPer Gold USB thermometer from PCsensor, a cute little device allowing to easily perform room temperature measurements.

As mentioned on the package, an USB cable should be used unless the goal is to measure chasis temperature.

TEMPer USB thermometer

On OpenBSD, the device is fully supported by the ugold(4) driver :

uhidev0 at uhub0 port 4 configuration 1 interface 0 "RDing TEMPerV1.4" rev 2.00/0.01 addr 3
uhidev0: iclass 3/1, 1 report id
ukbd0 at uhidev0 reportid 1: 8 variable keys, 5 key codes
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
uhidev1 at uhub0 port 4 configuration 1 interface 1 "RDing TEMPerV1.4" rev 2.00/0.01 addr 3
uhidev1: iclass 3/1
ugold0 at uhidev1
ugold0: 1 sensor type ds75/12bit (temperature)

Sensor values can be retrieved via the sysctl interface :

sysctl hw.sensors.ugold0
hw.sensors.ugold0.temp0=26.75 degC (inner)    

Alternatively, the -n switch can be used to only display the field value :

sysctl -n hw.sensors.ugold0
26.75 degC (inner)

GPU-accelerated video playback with NetBSD on the Raspberry Pi

NetBSD 7 gained support for hardware acceleration on the Raspberry Pi last January, and OMXPlayer was ubsequently imported into Pkgsrc. This combination allows seamless video playback directly in console.

For testing this setup, I used Jun Ebihara’s prebuilt NetBSD RPi image and packages.

Installing OMXPlayer using binary packages :

pkg_add omxplayer

Playing a video after blanking the screen :

omxplayer -b captain-comic.avi

This works unsurprisingly well and the player is quite pleasant to use.

RISC OS on the Raspberry Pi

Last week-end, I was finally able to dedicate some free time to play a little bit with the Raspberry Pi again, so I decided to plug it on my TV and try RISC OS Open using the prebuilt RISC OS Pi (RC14) SD card image.

In fact, I already had a brief encounter with RISC OS running on Acorn hardware (most likely a Risc PC) a while ago at a French demoparty in the late nineties. I’m not sure how popular those machines were in the UK, but in France, it was as exotic as it can get.

RISC OS in full glory on a 42 inches Panasonic TV in 1080p

Here is a screenshot showing the desktop running a few applications : BBC Basic, StrongEd text editor, and the NetSurf Web browser pointed at my ASCii and ANSi Gallery :

RISC OS running BBC Basic, StrongEd and NetSurf

This capture was taken using Snapper and converted from sprite to PNG using ConvImgs.

The case for Nginx in front of application servers

As a rule of thumb, an application server should never face the Internet directly, unless of course Nginx (or OpenResty) is being used as such. This is not only for performance reasons, although this is not much of a concern anymore with modern runtimes such as Go or Node, but mostly for flexibility and security reasons.

Here are some key points to consider :

  • At this point, Nginx is a proven and battle-tested HTTP server
  • This allows keeping the application as simple as possible : Nginx will handle logging, compression, SSL, and so on
  • In case the application server goes down, Nginx will still serve a 50x page so visitors know that something is wrong
  • Nginx has built-in load-balancing features, it also allows running several application servers on the same IP address
  • Nginx has built-in caching features (with on-disk persistence)
  • Nginx has rich rate-limiting features, which are especially useful for APIs
  • Nginx helps protecting against some DoS attacks (such as low-bandwidth Application Layer attacks)

Lastly, one aspect which tend to be forgotten these days is the importance of server logs. While in some cases it might be an accepable solution to use Google Analytics or Piwik, for measuring APIs traffic however, there is no better option. For a modern real-time log analyzer, I heartily recommend GoAccess.