Closed cookiengineer closed 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:
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).
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.
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.
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.
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.
As of https://github.com/tholian-network/stealth/commit/4285bdaa5646a2eaddc323ae7d24d5e6304b9626 this has been implemented, so this issue can be closed.
Once the
DNSS
Connection andHTTPS
Connection refactor is done, theDNSviaHTTPS
Connection needs to be re-implemented using the new HTTPS Connection./dns-query
API needs additionally an encode/decode method for?dns=<base64url>
formatted transfer of payloads as per RFC4648- [ ] 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.