Storing ASCII art in the DNS

TXT records are bizarre things. Each TXT record is actually a variably sized list of variably sized character strings. There can safely up to 127 characters per string (there's ambiguity about whether the 8-bit length field is signed or not) and the total size of the whole record is up to 64k. That should be plenty for ascii art.

Order is guaranteed for these character strings; at the wire level they are a contiguous blob. With the increasing adoption of SPF though, it's also increasingly common for implementations to preserve the order of the TXT records in a multi-record record set; so that the records can be concatenated in order to make a meaningful SPF string.

On the wire the records look like this;

   name type=TXT class=IN TTL=NN RDLENGTH=MM [length]some text[length]more text
   name type=TXT class=IN TTL=NN RDLENGTH=MM [length]even more text

which should be concatenated by readers (e.g. SPF implementations) to form a logical string like "some textmore texteven more text".

so if you use multiple records, you're really just putting arrays on top of arrays. It's usually best to stuff things into one record though, so that you don't have to risk an intermediate resolver re-ordering things.

Here's one of the earliest records ever created in Route 53, to test things out;

   dig +short TXT bradm.com @ns-323.awsdns-40.com | sed $'s/\" \"/\\\n/g'

Step 1: Encrypt your data

Step 2: base64encode it and store it in DNS records

Step 3: Data is propagated and cached globally

Step 4: ???

Step 5: Profit!

I just tried the command but it looks like the lines came back out of order.

The order seems random each time, I suppose I could keep trying until it works.

Brilliant.

dig @8.8.8.8 naptr ascii.artsy.net +short | sort