ohaiibuzzle
commented
3 months ago Another option we can do is make our own lightweight resolver. Since we only need to deal with A (and maybe AAAA) addresses we might be able to fit one in
Closed ohaiibuzzle closed 3 months ago
ohaiibuzzle
commented
3 months ago Another option we can do is make our own lightweight resolver. Since we only need to deal with A (and maybe AAAA) addresses we might be able to fit one in
xvzc
commented
3 months ago Thank you for your research. greatq job. the reason why i switched to another doh client was the previous one doesn't seem to be maintained anymore. let me think of what other alternatives we can have.
ohaiibuzzle
commented
3 months ago I mean in one way yeah maybe we could bring it up-to-date On the other hand, the spec (RFC8484) really didn't change (otherwise it will break a lot of things). So it's probably fine for it to be that way.
If you really want to be updated though, the IETF implementation here seems to be spec-compliant. I'll look over it in the weekend and see if I can hack it into SpoofDPI
Overview
We should probably revert to the github.com/babolivier/go-doh-client impementation of DoH used in older versions rather than the current github.com/likexian/doh of DoH
Description
The change in v0.10 to likexian's DoH implementation causes the loss of the ability to switch to different DoH providers. It is now basically hard-coded to use CloudFlare and Google's DNS (which are made from the client itself and not proxied). As such, if those addresses (cloudflare-dns.com and dns.google) is unresolvable, it would cause DoH not to work, exposing the client to classic DNS poisoning.
Additional context
The issue here is that likexian/doh isn't really a DNS-over-HTTPS client: What it does is actually use the JSON API endpoints of some resolvers (eg. dns.google/resolve) to fetch addresses. As such, it is not spec (RFC8484) compliant and some DNS servers (which users might prefer because provided ones are unreachable, which does happen) won't work.