HTML over DNS: Serving Blog Content over DNS(jacobkiers.net) |
HTML over DNS: Serving Blog Content over DNS(jacobkiers.net) |
I used DoH because to the best of my knowledge it's not possible to open raw sockets from the browser. Otherwise I'd have done that.
I don't think there's any practical use. And I did not intend it to have any.
Sometimes those are the most satisfying and technologically interesting proof of concepts. Don't let any of the detractors here tell you you're wasting your time!
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 and way less 4G available.
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.
- A website can bring its own DoH client and bypass both the OS resolver and the browser's trusted DoH resolver for anything except the initial page request.
- Any website can now access the full DNS information of any domain: Not just A/AAAA records, but also TXT, MX, SRV etc. Record metadata such as TTLs likewise.
All of that without requiring any backend infrastructure or exotic web API. It's literally just a static HTML file and fetch().
That's a genuinely new capability that wasn't available to websites before public DoH servers became available. I'm no security expert, but this smells like it should have some implications for web security.
Not sure about that, since it doesn’t sound like simply requesting answers from the DOH server injects the answer into the DNS cache.
And I don’t think this is novel, since anyone could have ran a dns info api before if they really wanted to.
True about that. While you can find out the real IP address of a host even if the os/browser blackholes it, it's more difficult to actually send requests to it: You can pass IP addresses to fetch(), but those will then also be used for the Host header, SNI and cert validation - not what you'd usually want. To make this work, you'd need a "connect to IP address X but pretend it's host Y" option for fetch - something that is probably not supported for obvious reasons.
I think it should still be possible to connect to WebRTC peers or to implement a tamper detection.
> And I don’t think this is novel, since anyone could have ran a dns info api before if they really wanted to.
If you ran your own API, you'd have server infrastructure to maintain. If you used a 3rd-party API, you'd have to deal with accounts, tokens, rate-limiting, etc. In contrast, this DoH server seems to be open to anyone, without any kind of registration required.
I think this makes this feature significantly cheaper to use.
A lot of web features had always been possible by simply running them on your own server: Cross-origin requests, generating images on-demand, rendering vector graphics, etc. Nevertheless, when those features became available in the browser - without any additional effort needed from the developer - it had massive effects on the web ecosystem.
I can't say I have answers, but my suspicion is that it makes a significant difference in friction whether a feature requires you to setup and run your own infrastructure or whether you just need to type in some javascript to use it.
> If web security depends on websites not having access to public data that could always be proxied to it then we're already screwed.
To some extent it does - that's why you cannot access the body cross-origin GET requests or the contents of cross-origin iframes without those sites opting in - even if no cookies or other credentials are sent with the reqest.
[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)
Turns out when you spy on your users word gets around.
const dohServer = "https://cloudflare-dns.com/dns-query?ct=application/dns-json&type=TXT&name=";
const baseDomain = "hod.experiments.jacobkiers.net";
A few years ago I randomly remarked that repeated base64 prefix converge to a fixed point. I tweeted [1] the first characters of that string out of amusement, without any additional details.
Then someone saw the tweet, found it funny, and did a write-up about it [2], and then there was an interesting discussion on Reddit [3]. There may have been one on HN too, I don't remember.
Have fun :).
[1] https://twitter.com/p4bl0/status/298900842076045312
[2] https://web.archive.org/web/20160313123301/https://fmota.eu/...
[3] https://www.reddit.com/r/compsci/comments/18234a/the_base64_...
I'll try it sometime soon (though my CSS skills are basically nonexistent...).
$ 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<<- opcode: QUERY, status: NOERROR, id: 49067
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;posts-2021-08-17-serving-blog-content-over-dns-md.hod.experiments.jacobkiers.net. IN TXT
;; AUTHORITY SECTION:
hod.experiments.jacobkiers.net. 292 IN SOA home.kie.rs. postmaster.kie.rs. 2021081903 3600 900 604800 3600> ;; 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.
Or at all since the content is entirely injected via JS with no fallback (and the JS uses class fields in case you thought an old browser might be able to load it).
Also, since this was mostly a DNS-focused proof of concept, I don't particularly care about that. Not in this case, at least.
I guess there are lots of tiny edge cases that look like that.
Class fields are later addition to classes. And completely unnecessary here, it looks. The class fields are just duplicates of the instance fields, which are always filled.
> The other 4% is divided between Internet Explorer, Opera Mini and obsolete versions of every other browser. So I'm trying to figure out what kind of people are using such ancient technology and why?
Unsupported device which can not have recent updates for one reason or an other?
dig TXT content.uniquekey.dnskv.com
--> 'ok'
dig TXT uniquekey.dnskv.com
--> 'content'
"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)"
For anyone who wants to research the subject, the class of security vulnerabilities are called DNS tunneling.
Whenever I see regexs hanging off the Internet, my heart skips a beat! :)
dns works fine at those rates or higher, and you'll use caching dns servers of ISPs, scales like no other, geo support etc etc. I think its great idea for public data.
A similar technique forms the basis of how services like dnsleaktest.com and which.nameserve.rs identify DNS resolvers in-use by a particular client.
How could they even know to tuen it on when all they get is an empty page?
And yet most site designers which require javascript turn out to be thoughtful enough to make a note of it rather than leave a completely empty page.
And public sites which absolutely require javascript to do anything turn out to be quite rare.
So there’s no reason to be used to it. “Some buttons don’t work”, yes I do expect i need to allow some JS. “Nothing shows up at all” is usually a network issue.