search

tholian-network / stealth

:rocket: Stealth - Secure, Peer-to-Peer, Private and Automateable Web Browser/Scraper/Proxy
GNU General Public License v3.0
1.04k stars 301 forks source link

Stealth: DNSviaHTTPS Connection #67

Closed cookiengineer closed 3 years ago

cookiengineer commented 3 years ago

Once the DNSS Connection and HTTPS Connection refactor is done, the DNSviaHTTPS Connection needs to be re-implemented using the new HTTPS Connection.

- [ ] The /resolve JSON API should work as intended like before, which means the ?name=<domain>&type=<DNS Q/A Type> API can be reused as before.

cookiengineer commented 3 years ago

As it turns out, most servers implement the JSON API in a non-standardized (and draft-violating) way. The DNS over HTTPS implementation in stealth will use the base64url encoded payload for transfers for a couple of reasons:

  1. The wireformat is basically a custom base64url encode, which is shitty, but it's at least done already as the encoder is identically to the UDP DNS wireformat (without the byte length prefix the TCP DNS wireformat has).

  2. application/dns-message is the new unified and implemented MIME header across all DNS over HTTPS implementations. The legacy application/dns-udpwireformat header and application/dns+json headers that are part of the JSON API draft work nowhere in practice. Cloudflare uses application/dns-json (with - instead of +) for their JSON-supporting /dns-query API and Google uses application/x-javascript for their /resolve API.

  3. The /resolve API is only supported by two servers in the wild: google and cloudflare. Therefore it makes no sense to implement the absurd amount of complexity for encoding/decoding its payload format; at least not with the current state of DoH support.

  4. The /resolve API also only supports one question at a time, and not multiple questions. The DNS Resolver's implementation would overcomplicate the RONIN idea, as a connection could not reliably be reused and would need another scheduler.

  5. As of now it's assumed that any connection can transfer multiple payloads. Turns out that the /resolve API scenario isn't capable of that because of the ?name= parameter being a single domain (not an Array of domains); and therefore the /dns-query API has to be used (as multiple questions and multiple answers can be transferred).

Implementations of RFC8484 in the wild:

As all implementations MUST support both POST and GET, the initial reimplementation will try to use POST wherever possible - and if that doesn't work then it'll fallback to GET dynamically on an error event.

Transferring base64url encoded wireframes via POST is much easier implemented than the GET request; as it is a payload-dependent implementation and leads to all servers requiring a Content-Length in the response, which eases up future reuse of existing Connections to multiplex more requests.

cookiengineer commented 3 years ago

As of https://github.com/tholian-network/stealth/commit/4285bdaa5646a2eaddc323ae7d24d5e6304b9626 this has been implemented, so this issue can be closed.