Live data from Hacker News

HTML over DNS: Serving Blog Content over DNS

jacobkiers.net

61–70 of 77 posts

Re: HTML over DNS: Serving Blog Content over DNS

#61
post #28

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 ;)

And packet rate. Some corporate firewalls may detect this as abusive and block it leading to questions from the security operations team and the person testing this out.

Re: HTML over DNS: Serving Blog Content over DNS

#62
post #54

The HTML bit is fun, but the more remarkable takeaway for me is that DoH servers accept cross-origin requests from ordinary javascript. This means two things: - 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…

A script could already bypass DNS by connecting directly to an IP address which could have been either hard coded or come from an API, for example. You could also send it all the other records via some API too. This just means people don't have to implement the service themselves.

Re: HTML over DNS: Serving Blog Content over DNS

#64
post #54

The HTML bit is fun, but the more remarkable takeaway for me is that DoH servers accept cross-origin requests from ordinary javascript. This means two things: - 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…

It shouldn't because this was always possible if someone really cared to just run their own public server with a /dig endpoint. If web security depends on websites not having access to public data that could always be proxied to it then we're already screwed.

Re: HTML over DNS: Serving Blog Content over DNS

#65

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/

You can even set up a VPN over DNS if you really wanted. https://github.com/yarrick/iodine

Re: HTML over DNS: Serving Blog Content over DNS

#66

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/

I'm not sure why this should be a corollary now. DNS exfiltration has always been possible, just like the article you linked to says. (I also like to point people to https://twitter.com/rsobers/status/1293539543115862016 in this context because it puts the idea so succinctly.)

Re: HTML over DNS: Serving Blog Content over DNS

#67

Author here: I made it as a proof of concept, just because I could. 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.

>Author here: I made it as a proof of concept, just because I could.

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!

Re: HTML over DNS: Serving Blog Content over DNS

#68
post #64
post #54

The HTML bit is fun, but the more remarkable takeaway for me is that DoH servers accept cross-origin requests from ordinary javascript. This means two things: - 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…

It shouldn't because this was always possible if someone really cared to just run their own public server with a /dig endpoint. If web security depends on websites not having access to public data that could always be proxied to it then we're already screwed.

> It shouldn't because this was always possible if someone really cared to just run their own public server with a /dig endpoint.

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.

Re: HTML over DNS: Serving Blog Content over DNS

#69
post #54

The HTML bit is fun, but the more remarkable takeaway for me is that DoH servers accept cross-origin requests from ordinary javascript. This means two things: - 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…

> - 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. 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.

> Not sure about that, since it doesn’t sound like simply requesting answers from the DOH server injects the answer into the DNS cache.

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.

Re: HTML over DNS: Serving Blog Content over DNS

#70

Earlier quoted context omitted.

> but once they turn it on it should have relatively good feature support How could they even know to tuen it on when all they get is an empty page?

The noscript tag is a thing.

The noscript tag is something the page would need to use, and does not. Again, page is completely empty (or was, author commented that they fixed it, very nice)
Post reply on HN