search

m13253 / dns-over-https

High performance DNS over HTTPS client & server
https://developers.google.com/speed/public-dns/docs/dns-over-https
MIT License
1.99k stars 221 forks source link

your DoH client implementation is not interoperable with some RFC8484 server implementations #48

Closed appliedprivacy closed 4 years ago

appliedprivacy commented 5 years ago

Your DoH client implementation is incompatible with some RFC8484 server implementations.

Your DoH client apparently sets a parameter that is not specified in RFC8484 (ct=), this causes some RFC8484 servers to respond with 400 Bad Request.

You also mentioned this obsolete parameter in #18.

Suggested solution: stop setting the ct HTTP parameter.

m13253 commented 5 years ago

Hello,

Thank you for your message.

As I said in #18, the ct= left in the codebase is a private extension used to negotiate between IETF DoH (RFC8484) and Google DoH. Obviously using ct= is not the best way to do the negotiation. The best way is to use URI Template, but I currently don't have time implementing it. (Pull Request welcome. :-)

The reason I kept Google DoH protocol (also known as CloudFlare JSON protocol) is that it is human-readable, thus very useful as a DNS problem troubleshooter in my daily life. IETF rejected Google DoH due to its feature incompleteness, but I am sure IETF will implement another human-readable protocol as an extension to RFC8484. That day might be the day that I have to solve #18.

However, most implementations does not reject ct= parameter. (Usually HTTP servers will not reject unrecognized query fields, remember utm_source?) The real problem is that they only recognize the old ct=application/dns-udpwireformat, which is an interoperable behavior in other words.

If you know such a server implementation, you can tell me so I can talk to them.

m13253 commented 5 years ago

As the discussion continued at DoH client-server interoperability vs. strict HTTP parameter checking, I will respond to this issue after the discussion has a result.