search

aarond10 / https_dns_proxy

A lightweight DNS-over-HTTPS proxy.
MIT License
775 stars 114 forks source link

support for 1.1.1.1 #29

Closed stangri closed 6 years ago

stangri commented 6 years ago

Hello Aaron, could you please implement support for https://1.1.1.1/?

Ideally, we should be able to specify the actual dns server to be used in the /etc/config/https_dns_proxy along with the other options for the proxy.

ghost commented 6 years ago

It's documented here: https://developers.cloudflare.com/1.1.1.1/dns-over-https/request-structure/.

a7ypically commented 6 years ago

The json response of 1.1.1.1 seems to be compatible with Google's, so this is just about changing the URL.

It also works without resolving a domain name: curl 'https://1.1.1.1/dns-query?ct=application/dns-json&name=example.com&type=AAAA'

ghost commented 6 years ago

For the time being I made a Cloudflare clone, but it's not my intention to take over the project. I did some testing and it seems to work fine.

famewolf commented 6 years ago

Strictly as an FYI...the dnscrypt-proxy service supports both dnscrypt and doh. In the config you can choose whether to use just one or both types of servers. Cloudflare is already listed in the list of servers it uses. If you user merlin/asuswrt there is also an installer which asks you questions to generate a config. https://www.snbforums.com/threads/release-dnscrypt-installer-for-asuswrt.36071/ If you use android magisk has a dnscrypt2 module which can be configured the same way.

jooray commented 6 years ago

I would love to see https_dns_proxy on openwrt instead of dnscrypt-proxy. The packaged version is too old on openwrt and does not seem to be maintained (although dnscrypt-proxy is pretty cool by itself). I think https_dns_proxy suits openwrt better and I vote for this feature.

famewolf commented 6 years ago

@jooray Where are you getting your information? The dnscrypt-proxy website, faq etc still indicates it supports both doh and dnscrypt as does the latest build I can find.

stangri commented 6 years ago

@jooray -- I'm running https_dns_proxy on OpenWrt (well, LEDE 17.01.4) without any issues. The package I installed from official repo is https_dns_proxy - 2018-01-24-1.

Ah, I just realized you're talking about dnscrypt-proxy being outdated...

jooray commented 6 years ago

@stangri ...and https_dns_proxy not supporting 1.1.1.1 out of the box (which is the topic of this issue)

VindicatorDS commented 6 years ago

Cloudflare (for now, because of the lack of alternatives - see https://developers.cloudflare.com/1.1.1.1/dns-over-https/cloudflared-proxy/) recommends using either their own client (cloudflared +/- 20MB binary blob...) or the new dnscrypt-proxy 2.0 (https://github.com/jedisct1/dnscrypt-proxy).

This new dnscrypt-proxy version supports both DoH and load balancing. I'm using it with both cloudflare and google dns. Both with DNSoHTTPs on an OpenWRT router (the downside is that it's a +/- 6MB binary blob.... The source code is in Go, hence the binary blob size...).

I would love to continue using https_dns_proxy, but right now I'm having issues with DNSSEC because it fails to parse DNS answers with RR type: 43 (https://github.com/aarond10/https_dns_proxy/issues/20) and doesn't support cloudflare nor load-balancing.

frankiexyz commented 6 years ago

I would love to use https_dns_proxy on my openwrt unfortunately there is no option to use Cloudflare s setup and compile a package for openwrt seems to be quite complicated. I hope there will be a Cloudflare version on opkg soon

cg9999 commented 6 years ago

Makruiten's modified version seems to be working fine on openwrt. I just modified the feeds/packages/net/https-dns-proxy/Makefile PKG_SOURCE_URL:=https://github.com/makruiten/https_dns_proxy.git PKG_SOURCE_VERSION:=29a98002afdd7411c80bc5380c5b01a15d7abbb4 and built a new ipk

Mushoz commented 6 years ago

I would also love for 1.1.1.1 (and 1.0.0.1) to be supported, preferably via the config file. :)

aarond10 commented 6 years ago

A lot has happened in a week. :)

@stangri thanks for the heads up. I didn't know about 1.1.1.1 @makruiten thanks for verifying this works as is. Makes things a lot easier. @cg9999 please don't try to fork this into a version for Cloudflare and one for Google. I'd be very happy if it can be made to support both.

I'm away on holidays for the next few weeks but I'll pick this up when I get a chance. Happy to integrate clean, forward-thinking patches as well if anyone else has the time to throw at this.

cg9999 commented 6 years ago

@aarond10 Agreed, I'm not trying to push for a fork, just wanted to confirm that the changes made seem to be enough to make it work with 1.1.1.1. Making those configurable should be the goal.

fantuz commented 6 years ago

Consider that the IETF draft is ever changing, the URL parameters are changing as well with every new version of the draft (not yet RFC) https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-07

So, Cloudflare's 1.1.1.1 follows closely but we cannot talk about standard yet... for example, the actual MIME proposed type is now "application/dns-message" and not anymore "udpwireformat".

I suggest to leave this issue open, until DOH becomes RFC.

As well, defaulting to a service seems restrictive and "aggressive" choice. Better to leave the choice of the DNS provider to the user, as is already the case today.

fantuz commented 6 years ago

why @stangri your negative feedback ? JSON is NOT DOH, Cloudflare is NOT yet DOH. DOH is not from exclusive Cloudflare contribution either.

No DOH RFC exists (yet). So why develop and wonder, when no official standard is out there ? and Cloudflare could change the TOS (terms of service) and the format anytime, breaking your DNS resolution.

Do you think is appropriate, in this "beta" phase of D-o-H ?

yitzhaq commented 6 years ago

With https://github.com/vaapicon/doh-proxy from @vaapicon there are now (at least) three versions of this project floating around. Would be nice if this too could be merged back to the original project, so OpenWRT users would have a clean upgrade path towards using Cloudflare.

aarond10 commented 6 years ago

Yes, all these changes seem fairly trivial. I'm back from Holidays on Monday. I'll try to throw together something quickly to avoid further forking.

aarond10 commented 6 years ago

I've just added support for setting the resolver address in addition to the bootstrap DNS so using cloudflare is now trivial. Hoping the forks disappear now, or at least stagnate. :)

ghost commented 6 years ago

I've deleted mine.

Mushoz commented 6 years ago

@aarond10 why is a bootstrap DNS used? Wouldn't it be vulnerable to a MITM attack that returns an IP that does not belong to Google/Cloudflare, but to a DNS server setup by the attacker with its own https certificate such as let's encrypt?

aarond10 commented 6 years ago

The IP of the DNS resolver for DoH is not well known. It's not 1.1.1.1 not 8.8.8.8. we have to rely on certificate chains to guard against mitm for the bootstrap DNS lookups.

On Fri., 20 Apr. 2018, 5:57 pm Jaap Buurman, notifications@github.com wrote:

@aarond10 https://github.com/aarond10 why is a bootstrap DNS used? Wouldn't it be vulnerable to a MITM attack that returns an IP that does not belong to Google/Cloudflare, but to a DNS server setup by the attacker with its own https certificate such as let's encrypt?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/aarond10/https_dns_proxy/issues/29#issuecomment-383032312, or mute the thread https://github.com/notifications/unsubscribe-auth/AAM3XvEWrqSbM31SBXpCg0LATYwwXC8Jks5tqaLdgaJpZM4TC9DK .