Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Storing ASCII art in the DNS (cambus.net)
39 points by fcambus on Feb 5, 2014 | hide | past | favorite | 9 comments


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'


Here's our log record using the same trick:

dig +short txt log.netkine.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!


  dig +short txt 'steganography.wp.dg.cx'
And the old TCP-over-DNS trick http://analogbit.com/tcp-over-dns_howto


Didn't know about Wikipedia-over-DNS, that's pretty cool: https://dgl.cx/wikipedia-dns


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.



Most resolvers rotate the records in a record set on every query. The main thinking behind this is so that all of the resolver's clients don't just hammer the first IP in a multi-IP recordset. Some resolvers make exceptions to this behavior for MX/NAPTR/TXT records, some don't.


Brilliant.

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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: