> Sadly, the "let's turn everything into JSON so I don't have to learn what bytes are" crowd won
DoH uses raw bytes for DNS answers and not json: https://www.rfc-editor.org/rfc/rfc8484#section-6
DoH uses raw bytes for DNS answers and not json: https://www.rfc-editor.org/rfc/rfc8484#section-6
The idea behind it remains the same. HTTP/http2/http3 as a carrying mechanism for an existing binary format makes no sense when none of the benefits of the new format are actually coming from the HTTP protocol. This only increases the attack surface and complexity of the protocol. I don't know, maybe there's a benefit to setting cookies and language headers for DNS requests but I'm not seeing it. The only potential benefit touted in the RFC is that web applications can now do DNS lookups in a standardised way and I don't see how that's a benefit for anyone but user hostile companies.
Now we've reached the situation where HTTP/2 server push has been deprecated in almost all browsers but is still part of the DoH spec. I don't see the benefit of including server push support in the first place but because it's part of the standard we'll have to deal with potential servers relying on features disabled in libraries or unmaintained code in libraries that lays dormant because the major consumers of HTTP have stopped calling their methods.
And pretty much anyone can run a personal DoH stub resolver for ~$0: https://github.com/serverless-dns/zero
Just DoH won't save you from an oppressive government and neither will DoT. You can run DoT on port 443 and it'll appear as normal TLS traffic as well. Unless the state actors are doing extensive fingerprinting (that will expose DoH servers as well) I doubt it'll make a difference in situations where DoH makes sense. In areas where occasional government TLS MitM attacks are common, neither DoH nor DoT will protect you.