[xg15]

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

[judge2020]

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

[xg15]

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

[Spivak]

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.

[xg15]

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

[globular-toast]

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.