Your email response really is indicative of some of the folks that get cranky when you send them packets :)
I love posts like this where someone applies a theoretical concept in a fun and interesting (even if not practical) way.
Guessing date as circa 2003. Could be wrong.
As for DNS, djbdns can store arbitrary bytes in RR (e.g., TXT), as octal. For example, modified dnstxt can print formatted text stored in TXT records, with linefeeds, etc.
πfs (a file system)
0byte (a programming language)
Can anyone confirm if the Microsoft DNS servers default to caching an unlimited amount of data? The article claims "Unlimited??" as the default for these systems. Eyeballing the pie chart looks like 20% of the servers are running Microsoft, which could provide quite a lot of storage.
An enhancement of this technique could be used on one’s own private network of DNS resolvers for the specific purpose of acting like a highly available directory of private cloud nodes, storing the following information:
This would kind of be like a mashup of Apple Bonjour and this technique.
The big question is, how long to cache the information for in such a setup, assuming the cloud itself is highly unreliable, so as to make the entire thing extremely fault tolerant?
There are detectors of DNS abuse that I imagine the people who actually would store files in DNS would not want pointed at their files.
Seem's like this would be a good way to circumvent web filters that block remote file services (though allow DNS over tcp or udp).
How would one restrict this capability from an administrative perspective?
I have tested various use cases for Iodine, which works great, unless you are blocking all outbound dns traffic.
NS for hacker.toys not responding
Reason being, if users on my network are using a resolvers other than my own, they can resolve all sorts of domains I would have otherwise blackholed.
Especially with things like Google DNS over HTTPS and https://github.com/pforemski/dingo ...
Doing this sounds like a good way to increase the noise to signal ratio in your support calls....
# from memory, syntax might not quite work
telnet 188.8.131.52 80
With http 1.0 blocking/filtering ips was enough, with 1.1 you need a proxy. With tls/ssl you have the choice between (having the capability to) decrypt everything or filter nothing. (obviously ip level filtering works, but it's a little crude in a Http 1/1 world. Ditto for http2 etc).
Too high of a hurdle for your average user though, in which case blocking sites at the DNS resolver works.
Just a tiny correction: RIPE Atlas' reliability tags (e.g., "-stable-Xd") have nothing to do with the probe "changing the public IP address once a day". Those filter simply measure the probe's uptime over different time windows.
In fact, the "-stable-1d" tag you mentioned would be true even for probes that have been down "up to 2h" over the last day.
;; WARNING: recursion requested but not available