41–50 of 77 posts
Earlier quoted context omitted.
I don't know how to do this without JS. Also, since this was mostly a DNS-focused proof of concept, I don't particularly care about that. Not in this case, at least.
You don’t have to “do this without JS” but you could have a fallback to tell JS-less users about it. As is they get a blank page and no idea what’s happening.
Corollary is, spyware can use DNS to exfiltrate data [0]. Or, send out client-side metrics with cleverly drafted DNS requests [1], or use it as a 3p-cookie replacement [2]. [0] https://unit42.paloaltonetworks.com/dns-tunneling-how-dns-ca... [1] https://github.com/Jigsaw-Code/choir (disclosure: I co-develop hard-forks of two other related Jigsaw-Code projects) [2] http://dnscookie.com/
Turns out when you spy on your users word gets around.
Corollary is, spyware can use DNS to exfiltrate data [0]. Or, send out client-side metrics with cleverly drafted DNS requests [1], or use it as a 3p-cookie replacement [2]. [0] https://unit42.paloaltonetworks.com/dns-tunneling-how-dns-ca... [1] https://github.com/Jigsaw-Code/choir (disclosure: I co-develop hard-forks of two other related Jigsaw-Code projects) [2] http://dnscookie.com/
Packet size is a really good detection for this. DNS packets should only be so big ;)
Well the content is stored in a DNS Zone file but it is requested using JavaScript to an external HTTP API. I wouldn't really call that HTML over DNS but rather "DNS Zone as blog database". Anyway, this made me think of iodine [1], an IP over DNS solution, which I still run on my main server even though it has a lot less use now than it had until a few years ago when there were a lot of open wifi with captive portals…
the site is down? - https://code.kyro.se/iodine/
Thanks for pointing it out.
EDIT: As an aside, I still hate how mobile browsers have the bad habits of reloading tabs (and most of the time loosing content) that you get back to with no reason. If not for this crappy behavior, I would have copy-pasted the URL.
This looks like it was a fun project! For anyone who wants to research the subject, the class of security vulnerabilities are called DNS tunneling.
"In contrast to other top-level domains, .tel information is stored directly within the Domain Name System (DNS) [...] as opposed to the DNS simply returning details (such as IP addresses)"
Well the content is stored in a DNS Zone file but it is requested using JavaScript to an external HTTP API. I wouldn't really call that HTML over DNS but rather "DNS Zone as blog database". Anyway, this made me think of iodine [1], an IP over DNS solution, which I still run on my main server even though it has a lot less use now than it had until a few years ago when there were a lot of open wifi with captive portals…
Wondering why I can't query the DNS directly. $ dig posts-2021-08-17-serving-blog-content-over-dns-md.hod.experiments.jacobkiers.net TXT ; > DiG 9.8.3-P1 > posts-2021-08-17-serving-blog-content-over-dns-md.hod.experiments.jacobkiers.net TXT ;; global options: +cmd ;; Got answer: ;; ->>HEADER
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
That says that the DNS server didn't answer - for whatever reason - despite the address of that server being determined. It could have been a form of HN's "hug of death" where the website temporarily goes down when many people start to view it in a short period of time.
Looks more like HTML via HTTP, specifically DoH. const dohServer = "https://cloudflare-dns.com/dns-query?ct=application/dns-json&type=TXT&name="; const baseDomain = "hod.experiments.jacobkiers.net"; About 12 years ago I experimented with HTML over UDP DNS by modifying dnstxt from djbdns to output a MIME header. I could store tiny web pages, i.e., hyperlinks, in a zone file and serve them with tinydns. (This was befor…