aarond10 / https_dns_proxy

A lightweight DNS-over-HTTPS proxy.

https-dns-proxy

https_dns_proxy is a light-weight DNS<-->HTTPS, non-caching translation proxy for the RFC 8484 DNS-over-HTTPS standard. It receives regular (UDP) DNS requests and issues them via DoH.

Google's DNS-over-HTTPS service is default, but Cloudflare's service also works with trivial commandline flag changes.

Using Google

# ./https_dns_proxy -u nobody -g nogroup -d -b 8.8.8.8,8.8.4.4 \
    -r "https://dns.google/dns-query"

Using Cloudflare

# ./https_dns_proxy -u nobody -g nogroup -d -b 1.1.1.1,1.0.0.1 \
    -r "https://cloudflare-dns.com/dns-query"

Why?

Using DNS over HTTPS makes eavesdropping and spoofing of DNS traffic between you and the HTTPS DNS provider (Google/Cloudflare) much less likely. This of course only makes sense if you trust your DoH provider.

Features

• Tiny Size (<30kiB).
• Uses curl for HTTP/2 and pipelining, keeping resolve latencies extremely low.
• Single-threaded, non-blocking select() server for use on resource-starved embedded systems.
• Designed to sit in front of dnsmasq or similar caching resolver for transparent use.

Build

Depends on c-ares (>=1.11.0), libcurl (>=7.64.0), libev (>=4.25).

On Debian-derived systems those are libc-ares-dev, libcurl4-{openssl,nss,gnutls}-dev and libev-dev respectively. On Redhat-derived systems those are c-ares-devel, libcurl-devel and libev-devel.

On MacOS, you may run into issues with curl headers. Others have had success when first installing curl with brew.

brew install curl --with-openssl --with-c-ares --with-libssh2 --with-nghttp2 --with-gssapi --with-libmetalink
brew link curl --force

On Ubuntu

apt-get install cmake libc-ares-dev libcurl4-openssl-dev libev-dev build-essential

If all pre-requisites are met, you should be able to build with:

$ cmake .
$ make

Build with HTTP/3 support

• If system libcurl supports it by default nothing else has to be done

• If a custom build of libcurl supports HTTP/3 which is installed in a different location, that can be set when running cmake:

$ cmake -D CUSTOM_LIBCURL_INSTALL_PATH=/absolute/path/to/custom/libcurl/install .

• Just to test HTTP/3 support for development purpose, simply run the following command and wait for a long time:

$ ./development_build_with_http3.sh

INSTALL

Install built program

This method work fine on most Linux operating system, which uses systemd.
Like: Raspberry Pi OS / Raspbian, Debian, Ubuntu, etc.

To install the program binary, systemd service and munin plugin (if munin is pre-installed), simply execute the following after build:

$ sudo make install

To activate munin plugin, restart munin services:

$ sudo systemctl restart munin munin-node

To overwrite default service options use:

$ sudo systemctl edit https_dns_proxy.service

And re-define ExecStart with desired options:

[Service]
ExecStart=
ExecStart=/usr/local/bin/https_dns_proxy \
  -u nobody -g nogroup -r https://doh.opendns.com/dns-query

OpenWRT package install

There is a package in the OpenWRT packages repository as well. You can install as follows:

root@OpenWrt:~# opkg update
root@OpenWrt:~# opkg install https-dns-proxy
root@OpenWrt:~# /etc/init.d/https-dns-proxy enable
root@OpenWrt:~# /etc/init.d/https-dns-proxy start

OpenWrt's init script automatically updates the dnsmasq config to include only DoH servers on its start and restores old settings on stop. Additional information on OpenWrt-specific configuration is available at the README.

If you are using any other resolver on your router you will need to manually replace any previously used servers with entries like:

127.0.0.1#5053

You may also want to prevent your resolver from using /etc/resolv.conf DNS servers, leaving only our proxy server.

There's also a WebUI package available for OpenWrt (luci-app-https-dns-proxy) which contains the list of supported and tested DoH providers.

archlinux package install

There is also an externally maintained AUR package for latest git version. You can install as follows:

user@arch:~# yay -S https-dns-proxy-git

Docker install

There is also an externally maintained Docker image for latest git version. Documentation, Dockerfile, and entrypoint script can be viewed on GitHub. An example run:

### points towards AdGuard DNS, only use IPv4, increase logging ###

docker run --name "https-dns-proxy" -p 5053:5053/udp  \
  -e DNS_SERVERS="94.140.14.14,94.140.15.15" \
  -e RESOLVER_URL="https://dns.adguard.com/dns-query" \
  -d bwmoran/https-dns-proxy \
  -4 -vvv

Usage

Just run it as a daemon and point traffic at it. Commandline flags are:

Usage: ./https_dns_proxy [-a <listen_addr>] [-p <listen_port>]
        [-d] [-u <user>] [-g <group>] [-b <dns_servers>]
        [-i <polling_interval>] [-4] [-r <resolver_url>]
        [-t <proxy_server>] [-l <logfile>] [-c <dscp_codepoint>]
        [-x] [-q] [-s <statistic_interval>] [-v]+ [-V] [-h]

  -a listen_addr         Local IPv4/v6 address to bind to. (127.0.0.1)
  -p listen_port         Local port to bind to. (5053)
  -d                     Daemonize.
  -u user                Optional user to drop to if launched as root.
  -g group               Optional group to drop to if launched as root.
  -b dns_servers         Comma-separated IPv4/v6 addresses and ports (addr:port)
                         of DNS servers to resolve resolver host (e.g. dns.google).
                         When specifying a port for IPv6, enclose the address in [].
                         (8.8.8.8,1.1.1.1,8.8.4.4,1.0.0.1,145.100.185.15,145.100.185.16,185.49.141.37)
  -i polling_interval    Optional polling interval of DNS servers.
                         (Default: 120, Min: 5, Max: 3600)
  -4                     Force IPv4 hostnames for DNS resolvers non IPv6 networks.
  -r resolver_url        The HTTPS path to the resolver URL. Default: https://dns.google/dns-query
  -t proxy_server        Optional HTTP proxy. e.g. socks5://127.0.0.1:1080
                         Remote name resolution will be used if the protocol
                         supports it (http, https, socks4a, socks5h), otherwise
                         initial DNS resolution will still be done via the
                         bootstrap DNS servers.
  -l logfile             Path to file to log to. ("-")
  -c dscp_codepoint      Optional DSCP codepoint[0-63] to set on upstream DNS server
                         connections.
  -x                     Use HTTP/1.1 instead of HTTP/2. Useful with broken
                         or limited builds of libcurl. (false)
  -q                     Use HTTP/3 (QUIC) only. (false)
  -s statistic_interval  Optional statistic printout interval.
                         (Default: 0, Disabled: 0, Min: 1, Max: 3600)
  -v                     Increase logging verbosity. (Default: error)
                         Levels: fatal, stats, error, warning, info, debug
                         Request issues are logged on warning level.
  -V                     Print version and exit.
  -h                     Print help and exit.

Testing

Functional tests can be executed using Robot Framework.

dig and valgrind commands are expected to be available.

pip3 install robotframework
python3 -m robot.run tests/robot/functional_tests.robot

TODO

• Add some tests.
• Improve IPv6 handling and add automatic fallback to IPv4

Authors

• Aaron Drew ([email protected]): Original https_dns_proxy.
• Soumya (github.com/soumya92): RFC 8484 implementation.
• baranyaib90 (github.com/baranyaib90): fixes and improvements.

https_dns_proxy's Issues

Could you add proxy support?

Some country like China blocked the IP of dns.google.com, so we need proxy to work. I can hardcode add:

curl_easy_setopt(ctx->curl, CURLOPT_PROXY, "socks5://127.0.0.1:9050");

to https_client.c to use proxy, it's work, but this is bad way i know. It is shame i know nothing about C++ language...

So, could you add native proxy support? may be -t http://127.0.0.1:8080 or -t socks5://127.0.0.1:9050 etc...

Thanks!

OpenWRT/lede issue with libcurl/openssl and libcurl/mbedtls

I haven't nailed the root cause but recent builds are failing to resolve any DNS requests on OpenWRT and lede builds. Nothing appears broken about the software directly, only the binaries built from it.

CURL is reporting "Unsupported protocol" for libcurl versions built against openssl and a cryptic "no error" (but also no data) if compiled against mbedtls.

A workaround for now is to use libcurl compiled against gnutls. I notice this is falling back to HTTP/1.1 though which may push up resolve latencies a bit.

openwrt package: start second instance by default

Hi!

I just discovered this project and think it's awesome! Especially that you also provide an openwrt package so it is easy to use.

Related to #29 and #32:
Something that would be icing on the cake would be support for multiple DNS providers in an easy to use way too. The quickest way to achieve this probably is to start multiple instances listening at different ports and let the users configure dnsmasq (or whatever) to use all of them as DNS servers.
In the case of openwrt this way the desired service(s) can be selected even using luci via the "DHCP and DNS/DNS forwardings" setting. And it's a change that should be easy to transplant to a DoT proxy as well.

Maybe you could change the startup script so it launched a second process listening at e.g. 5153 that used the cloudflare DNS? Users could then very easily point dnsmasq to their preferred service, or use both.

In the long run maybe a (luci-editable?) config file where users can specify any number of DoH providers, query URLs, and ports could be in the cards.

Brgds!

Secure HTTPS

No attempt is made by https-dns-proxy to secure the TLS in HTTPS, such as

curl_easy_setopt(ctx->curl, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1_2);
curl_easy_setopt(curl, CURLOPT_SSL_CIPHER_LIST, "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH");

which means that the strength of encryption is left to the OS (or the packager of openssl for that distro). Not saying these good settings and I am no expert in crypto, and these will break older distros but I prefer security by default and hate applications that ship with known insecure defaults.

lede doesn't resolve any domain

root@LEDE-X64:~# /usr/bin/https_dns_proxy -p 5053 -v -v -v
[I] 1496692158.327939 main.c:135 Built Jun 6 2017 03:19:59.
[I] 1496692158.327961 main.c:136 System c-ares: 1.12.0
[I] 1496692158.327987 main.c:137 System libcurl: libcurl/7.54.0 mbedTLS/2.4.2
[I] 1496692158.328140 dns_server.c:39 Listening on 127.0.0.1:5053
[D] 1496692158.570174 main.c:120 Received new IP '216.58.200.46'
[D] 1496692182.874309 main.c:92 Received request for 'www.youtube.com' id: 6478, type 1, flags 0120
[D] 1496692182.874370 https_client.c:57 Requesting HTTP/1.1: 0

[D] 1496692184.876145 https_client.c:96 CURLINFO_EFFECTIVE_URL: https://dns.google.com/resolve?name=www.youtube.com&type=1
[D] 1496692184.876171 https_client.c:108 CURLINFO_RESPONSE_CODE: 0
[D] 1496692184.876180 https_client.c:137 CURLINFO_HTTP_VERSION: 0
[D] 1496692184.876187 https_client.c:144 CURLINFO_PROTOCOL: 0
[D] 1496692184.876195 https_client.c:165 Times: 0.000041, 0.000000, 0.000000, 0.000000, 0.000000, 2.001638
[D] 1496692184.876215 main.c:57 buflen 0

[D] 1496692187.879817 main.c:92 Received request for 'www.youtube.com' id: 6478, type 1, flags 0120
[D] 1496692187.879864 https_client.c:57 Requesting HTTP/1.1: 0

[D] 1496692189.880417 https_client.c:96 CURLINFO_EFFECTIVE_URL: https://dns.google.com/resolve?name=www.youtube.com&type=1
[D] 1496692189.880444 https_client.c:108 CURLINFO_RESPONSE_CODE: 0
[D] 1496692189.880453 https_client.c:137 CURLINFO_HTTP_VERSION: 0
[D] 1496692189.880460 https_client.c:144 CURLINFO_PROTOCOL: 0
[D] 1496692189.880467 https_client.c:165 Times: 0.000043, 0.000000, 0.000000, 0.000000, 0.000000, 2.000432
[D] 1496692189.880488 main.c:57 buflen 0

support SRV and RRSIG

Currently getting errors like this when trying to query for certain record types:
[W] 1479503994.574179 json_to_dns.c:333 Failed to encode Answer ix 0.

You can use these examples:
dig @127.0.0.1 -p5053 srv _xmpp-client._tcp.debian.org
dig @127.0.0.1 -p5053 rrsig _xmpp-client._tcp.debian.org

Might want to check other record types too, DNSKEY and such?

parse_time timezone offset TODO isn't accurate

@aarond10 , I noticed the following TODO while browsing your commit for #50 .
https://github.com/aarond10/https_dns_proxy/blob/master/src/json_to_dns.c#L304

I went and looked at glibc in time/mktime.c, function ranged_convert() they treat a negative tm_sec as an error, which is called by __mktime_internal(). I suspect the negative tm_sec value is being ignored and converted to 0 which probably isn't what you want.

I have an alternate parse_timezone routine available, should you find it useful:

uint32_t parse_time(const char *timestr) {
    struct tm tm;
    memset(&tm, 0, sizeof(tm));
    if (sscanf(timestr, "%04d%02d%02d%02d%02d%02d",
	       &tm.tm_year, &tm.tm_mon, &tm.tm_mday,
	       &tm.tm_hour, &tm.tm_min, &tm.tm_sec) != 6) {
	return 0;
    }

    tzset();
    tm.tm_year -= 1900;
    tm.tm_mon -= 1;

    if (tm.tm_year < 0)
	return 0; /* Treat years before 1900 as invalid. */
    if (tm.tm_mon < 0 || tm.tm_mon > 11)
	return 0;
    if (tm.tm_mday < 1 || tm.tm_mday > 31)
	return 0; /* Note zero is an invalid mday */
    if (tm.tm_hour < 0 || tm.tm_hour > 23)
	return 0;
    if (tm.tm_min < 0 || tm.tm_min > 59)
	return 0;
    if (tm.tm_sec < 0 || tm.tm_sec > 60)
	return 0; /* may contain a leap second */

    time_t t = mktime(&tm);
    if (t == -1)
	return 0;
    /* According to tzset(3) the global variable timezone is set to the
     * number of seconds needed to alter a GMT/UTC time into a local
     * time. Values west of GMT are positive, east of GMT are negative.
     * Because times west of GMT are earlier, we must subtract timezone.
     * In the case of timezones west of the GMT it will remove seconds
     * and in the case of timezones east of GMT it will add seconds
     * by subtracting a negative value.
     */
    t -= timezone;

    /* The contents of timezone is *not* adjusted for daylight savings.
     * We must manually adjust an hour if it is in effect.
     */
    t += tm.tm_isdst * 3600;
    return (uint32_t)t;
}

document macos install

Is it possible to document macos/osx installation more specifically, possibly using issue #13 as a resource?

thanks,

openwrt package: daemon does not drop privileges under procd

currently, main.c only drops privileges if daemonizing:

https_dns_proxy/src/main.c

Lines 212 to 221 in 7978052

	if (opt.daemonize) {
	if (setgid(opt.gid)) {
	FLOG("Failed to set gid.");
	}
	if (setuid(opt.uid)) {
	FLOG("Failed to set uid.");
	}
	// daemon() is non-standard. If needed, see OpenSSH openbsd-compat/daemon.c
	daemon(0, 0);
	}

under procd (i.e. when not daemonized) this code path isn't reached and therefore https_dns_proxy doesn't drop privileges as directed via the user and group options in /etc/config/https_dns_proxy.

i was using my own package up until now and worked around this by using an init script without USE_PROCD=1 and instead starting with -d.

maybe main.c should drop privileges if the daemon is started with -u / -g unconditionally, instead of just when the -d switch is used? or perhaps USE_PROCD should be dropped from the init script?

this mentions procd, but i'd imagine the same would happen with e.g. systemd.

if you'd like i can submit a PR which drops privileges unconditionally if -u / -g are provided. thanks!

How to resolve

https_dns_proxy/src/options.c: In function 'options_parse_args':
https_dns_proxy/src/options.c:100: error: 'O_CLOEXEC' undeclared (first use in this function)
https_dns_proxy/src/options.c:100: error: (Each undeclared identifier is reported only once
https_dns_proxy/src/options.c:100: error: for each function it appears in.)
https_dns_proxy.dir/build.make:206: recipe for target 'CMakeFiles/https_dns_proxy.dir/src/options.c.o' failed
make[5]: *** [CMakeFiles/https_dns_proxy.dir/src/options.c.o] Error 1

Incorrect query for root domain (breaks dig +trace)

It seems that for a query like IN NS ., https_dns_proxy will use an empty name field, which will not work with either Cloudflare or Google.

failed to build with openwrt 19.07-rc1

https_dns_proxy failed to compile: error: unknown argument: '-fhonour-copts' [clang-diagnostic-error];

https_dns_proxy-2018-04-23/src/dns_poller.c:4:10: error: 'ares.h' file not found [clang-diagnostic-error]

Bootstrap the bootstrap

Suggestion: call ares_set_servers to use 8.8.8.8 and 8.8.4.4 for resolving dns.google.com

This should eliminate dependencies on any local or dhcp (mis)configuration.

Bootstrap trust

This is an example or how to embed a trusted certificate to be used by curl:
https://github.com/curl/curl/blob/master/docs/examples/cacertinmem.c

This can help if the certificate pack in the OS is outdated, misconfigured or has extra certificates injected into it for a MITM attack.

The certificate to be embedded should the GeoTrust CA signing Google certs:

https://www.geotrust.com/resources/root_certificates/certificates/GeoTrust_Global_CA.pem

Not getting log output until I Ctrl-c

If I run https_dns_proxy and don't provide the -l argument, the output that I would expect to appear in stdout doesn't appear until I kill the program with ctrl + c.

For example:

wlaw@DEV-M-234SW:~/https_dns_proxy$ ./https_dns_proxy -t http://localhost:3128 -v
^C[W] 1511909566.963236 dns_poller.c:43 DNS lookup failed: 16
[W] 1511909566.963253 dns_poller.c:43 DNS lookup failed: 16
[W] 1511909566.963266 dns_poller.c:43 DNS lookup failed: 16
[W] 1511909566.963268 dns_poller.c:43 DNS lookup failed: 16
[W] 1511909566.963270 dns_poller.c:43 DNS lookup failed: 16
wlaw@DEV-M-234SW:~/https_dns_proxy$ 

I would expect that output to be printed to stdout before I hit ctrl + c, but instead it all gets written upon program close.

Can you make an option for the user to decide whether to get the A result or the AAAA result or the result of ANY?

Could you make an option for the user to decide whether to get the A result or the AAAA result or the result of ANY?
Not everyone has an ipv6 address. Those who don't have a native ipv6 address have to use a tunnel. And your software is very good.However, your software has only a backup mechanism and no complementary mechanism.which makes the software somewhat inadequate.
If you can do it ,I would be appreciate

Translated by Google Translate

gfwlist模式不支持https_dns_proxy？

现在我有两种模式，一种是gfwlist模式，一种是白名单模式。

1. gfwlist的规则：只有名单里的domain才走代理
   -- iptables -t nat -A PREROUTING -p tcp -m set --match-set gfwlist dst -j REDIRECT --to-port 1080
   -- iptables -t nat -A OUTPUT -p tcp -m set --match-set gfwlist dst -j REDIRECT --to-port 1080
   在该模式下使用opkg 安装好https_dns_proxy 后，使用dig -p 6053 www.google.com获得以下返回值：
   root@****:/etc/dnsmasq.d# dig -p 6053 www.google.com

; <<>> DiG 9.11.2-P1 <<>> -p 6053 www.google.com
;; global options: +cmd
;; connection timed out; no servers could be reached

2. 白名单模式：自定义规则链SHADOWSOCKS，放行大陆IP和部分特殊的IP，其余的全部走代理。
   该模式下可使用https_dns_proxy。

ps：shadowsocks使用的ss-redir和ss-tunnel。已经在/etc/config/dhcp里添加了" list server '127.0.0.1#6053' ".

Using Cloudflare URL, it still polls DNS for 'dns.google.com'

Using Cloudflare URL, it still polls DNS for 'dns.google.com'. It doesn't lookup DNS for 'cloudflare-dns.com' until the I send it a request. The address it starts using for cloudflare is IPV6. The connections to the DoH server are IPV6 unless using Google's server. I thought wow, but after a few requests it stops responding. I had to restart it. ps. Cloudflare uses 1.1.1.1 and 1.0.0.1 as Alternate names in their Certificates.

does openwrt/lede version support proxy?

Thanks for the amazing app.

It seems that it does not support proxy on lede. Following is the init script for https_dns_proxy which comes from lede's package (opkg install https_dns_proxy).

I tried to start https_dns_proxy with -t param, but seems no lucky.

root@LEDE:~# cat /etc/init.d/https_dns_proxy
#!/bin/sh /etc/rc.common

START=80

USE_PROCD=1
PROG=/usr/sbin/https_dns_proxy

start_instance() {
	local cfg="$1"
	local listen_addr listen_port user group

	config_get listen_addr "$cfg" listen_addr
	config_get listen_port "$cfg" listen_port
	config_get user "$cfg" user
	config_get group "$cfg" group

	procd_open_instance
	procd_set_param command ${PROG} \
		-a "$listen_addr" -p "$listen_port" \
		-u "$user" -g "$group"
	procd_set_param respawn
	procd_close_instance
}

service_triggers() {
	procd_add_reload_trigger "https_dns_proxy"
}

start_service() {
	config_load 'https_dns_proxy'
	config_foreach start_instance 'https_dns_proxy'
}

I cannot get https_dns_proxy work on lede. I saw an open issue about openwrt/lede, but am not sure whether it's the same problem since I am in China, where may have the most complex network in the world...

Currently I am doing the following thing to make it work as a workaround.

Network
lede router --> notebook --> ubuntu in virtualbox with bridge network
192.168.1.1 ---- 192.168.1.2 ----- 192.168.1.3

there is a socks5 proxy on lede, socks5://192.168.1.1:1080

a https_dns_proxy instance is running on ubuntu with -t socks5://192.168.1.1:1080

dnsmasq.conf
server=/#/192.168.1.3#5053

The workaround works but it's annoying because when the notebook get sleep. https_dns_proxy also stop working. thus other devices cannot resolve name anymore.

Hope we can figure out what's the problem. Thanks

app.extra_request_args should be initialized

app.extra_request_args should be initialized otherwise the HTTPS request would look like "GET /resolve?name=example.com&type=1(null)" and get a 400 response

OpenWRT package version not updated?

I've checked the opkg repo and the version does not support changing to cloudflare dns

https_dns_proxy | 2018-01-24-1 | 13648 | DNS over HTTPS proxy server

how to build on raspbian?

pi@raspberrypi:~/https_dns_proxy $ cmake .
-- Configuring done
-- Generating done
-- Build files have been written to: /home/pi/https_dns_proxy
pi@raspberrypi:~/https_dns_proxy $ make
[ 11%] Building C object CMakeFiles/https_dns_proxy.dir/src/https_client.c.o
In file included from /usr/include/curl/curl.h:2323:0,
                 from /home/pi/https_dns_proxy/src/https_client.c:5:
/home/pi/https_dns_proxy/src/https_client.c: In function ‘https_client_init’:
/home/pi/https_dns_proxy/src/https_client.c:180:52: error: ‘CURLPIPE_MULTIPLEX’ undeclared (first use in this function)
   curl_multi_setopt(c->curlm, CURLMOPT_PIPELINING, CURLPIPE_MULTIPLEX);
                                                    ^
/home/pi/https_dns_proxy/src/https_client.c:180:52: note: each undeclared identifier is reported only once for each function it appears in
CMakeFiles/https_dns_proxy.dir/build.make:134: recipe for target 'CMakeFiles/https_dns_proxy.dir/src/https_client.c.o' failed
make[2]: *** [CMakeFiles/https_dns_proxy.dir/src/https_client.c.o] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/https_dns_proxy.dir/all' failed
make[1]: *** [CMakeFiles/https_dns_proxy.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2
pi@raspberrypi:~/https_dns_proxy $

https_dns_proxy don't support DS type record

Start https_dns_proxy
./https_dns_proxy -a 127.0.0.1 -p 5353 -t socks5://127.0.0.1:1080 -u nobody -g nobody -v

Run dig cloudflare.com ds @127.0.0.1 -p 5353 and you can't get the correct answers.

$ dig cloudflare.com ds @127.0.0.1 -p 5353
;; Warning: Message parser reports malformed message packet.

; <<>> DiG 9.11.2 <<>> cloudflare.com ds @127.0.0.1 -p 5353
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34528
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;cloudflare.com.                        IN      DS

;; Query time: 1476 msec
;; SERVER: 127.0.0.1#5353(127.0.0.1)
;; WHEN: Wed Nov 29 17:07:32 CST 2017
;; MSG SIZE  rcvd: 32

The log output:

./https_dns_proxy -a 127.0.0.1 -p 5353 -t socks5://127.0.0.1:1080 -u nobody -g nobody -v
[W] 1511945779.408802 json_to_dns.c:347 Failed to encode Answer ix 0.
[W] 1511946452.174362 json_to_dns.c:347 Failed to encode Answer ix 0.

Use the api of Google's DNS-over-HTTPS service

$ proxychains curl "https://dns.google.com/resolve?name=cloudflare.com&type=ds"
[proxychains] config file found: /etc/proxychains.conf
[proxychains] preloading /usr/lib/libproxychains4.so
[proxychains] DLL init: proxychains-ng 4.12
[proxychains] Strict chain  ...  127.0.0.1:1080  ...  dns.google.com:443  ...  OK
{"Status": 0,"TC": false,"RD": true,"RA": true,"AD": true,"CD": false,"Question":[ {"name": "cloudflare.com.","type": 43}],"Answer":[ {"name": "cloudflare.com.","type": 43,"TTL": 14809,"data": "2371 13 2 32996839A6D808AFE3EB4A795A0E6A7A39A76FC52FF228B22B76F6D63826F2B9"}]}

Question: Certificate Validation

Quick question that I hope somebody is able to answer: Does this application do certificate validation to prevent MITM attacks with self-signed certificates?

Quad9: failing to encode authority for some queries.

I am seeing a an issue when using DoH on quad9. I have tried using all three of their configuration options and see similar warning strings.

I should note this doesn't happen for all host queries, only some of them. For example, yahoo.com does not produce the warnings.

I'll also note this configuration is working with dnsmasq to resolve hosts. It's just that https_dns_proxy reports some of these packets as malformed, which dnsmasq seems to ignore with my configuration.

Here are the steps to reproduce the warnings:

1. execution:

./https_dns_proxy \
    -u nobody -g nogroup \
    -b 9.9.9.9,149.112.112.9 \
    -r https://dns9.quad9.net/dns-query?ct=application/dns-json& \
    -a 127.0.0.1 -p 5054 \
    -d -v -l /root/gw/https_dns_proxy/run_quad9.log

2. local query:

dig -p 5054 @127.0.0.1 tensorflow.com

3. log result:

[W] 1548086891.902399 json_to_dns.c:416 Failed to encode Authority ix 1.
[W] 1548086891.902453 json_to_dns.c:416 Failed to encode Authority ix 2.
[W] 1548086891.902462 json_to_dns.c:416 Failed to encode Authority ix 3.
[W] 1548086891.902469 json_to_dns.c:416 Failed to encode Authority ix 4.
[W] 1548086891.902477 json_to_dns.c:416 Failed to encode Authority ix 5.
[W] 1548086891.902483 json_to_dns.c:416 Failed to encode Authority ix 6.
[W] 1548086891.902490 json_to_dns.c:416 Failed to encode Authority ix 7.

BUG

Hello when I used 2k+ queries the next connections from Google.com are refused to reply to UDP Clients, it's possible to fix it ?

Build failed

build on debian 8, dependency versions:

root@SG:~# dpkg -l | grep clang
ii  clang                         1:3.5-25                         amd64        C, C++ and Objective-C compiler (LLVM based)
ii  clang-3.5                     1:3.5-10                         amd64        C, C++ and Objective-C compiler (LLVM based)
ii  clang-tidy-4.0                1:4.0.1-10~deb8u1                amd64        clang-based C++ linter tool
ii  libclang-common-3.5-dev       1:3.5-10                         amd64        clang library - Common development package
ii  libclang1-3.5:amd64           1:3.5-10                         amd64        C interface to the clang library
root@SG:~# dpkg -l | grep libev
ii  libev-dev                     1:4.15-3                         amd64        static library, header files, and docs for libev
ii  libev4                        1:4.15-3                         amd64        high-performance event loop library modelled after libevent
root@SG:~# dpkg -l | grep libcurl
ii  libcurl3:amd64                7.38.0-4+deb8u14                 amd64        easy-to-use client-side URL transfer library (OpenSSL flavour)
ii  libcurl3-gnutls:amd64         7.38.0-4+deb8u14                 amd64        easy-to-use client-side URL transfer library (GnuTLS flavour)
ii  libcurl4-openssl-dev:amd64    7.38.0-4+deb8u14                 amd64        development files and documentation for libcurl (OpenSSL flavour)
root@SG:~# dpkg -l | grep ares
ii  libc-ares-dev:amd64           1.10.0-2+deb8u2                  amd64        asynchronous name resolver - development files
ii  libc-ares2:amd64              1.10.0-2+deb8u2                  amd64        asynchronous name resolver

/root/https_dns_proxy/src/utils.c: In function ‘dn_write_name’:
/root/https_dns_proxy/src/utils.c:18:3: warning: incompatible implicit declaration of built-in function ‘memcpy’
   memcpy(out, name, namelen);
   ^
/root/https_dns_proxy/src/utils.c: In function ‘dn_match’:
/root/https_dns_proxy/src/utils.c:38:9: warning: incompatible implicit declaration of built-in function ‘strlen’
     if (strlen(str) < len) {
         ^
/root/https_dns_proxy/src/utils.c: In function ‘dn_find_dnptr’:
/root/https_dns_proxy/src/utils.c:73:29: warning: incompatible implicit declaration of built-in function ‘strlen’
   const char *nend = name + strlen(name);
                             ^
/root/https_dns_proxy/src/utils.c: In function ‘dn_name_nocompress’:
/root/https_dns_proxy/src/utils.c:137:21: warning: incompatible implicit declaration of built-in function ‘strlen’
   size_t name_len = strlen(name);
                     ^
/root/https_dns_proxy/src/utils.c:139:26: warning: initialization makes pointer from integer without a cast
   char *name_component = strtok_r(name, ".", &savedptr);
                          ^
/root/https_dns_proxy/src/utils.c:149:5: warning: incompatible implicit declaration of built-in function ‘memcpy’
     memcpy(pos, name_component, l);
     ^
/root/https_dns_proxy/src/utils.c:151:20: warning: assignment makes pointer from integer without a cast
     name_component = strtok_r(NULL, ".", &savedptr);
                    ^
/root/https_dns_proxy/src/utils.c: In function ‘unescape’:
/root/https_dns_proxy/src/utils.c:164:23: warning: incompatible implicit declaration of built-in function ‘strlen’
   const char *e = s + strlen(in);
                       ^
/root/https_dns_proxy/src/utils.c:171:5: warning: incompatible implicit declaration of built-in function ‘strncpy’
     strncpy(o, s, *olen);
     ^
/root/https_dns_proxy/src/utils.c: In function ‘b32hexdec’:
/root/https_dns_proxy/src/utils.c:319:23: warning: incompatible implicit declaration of built-in function ‘strlen’
   const char *e = s + strlen(buf);
                       ^
/root/https_dns_proxy/src/utils.c: In function ‘b64dec’:
/root/https_dns_proxy/src/utils.c:359:13: warning: incompatible implicit declaration of built-in function ‘strlen’
   int len = strlen(buf);
             ^
/root/https_dns_proxy/src/utils.c: In function ‘hexdec’:
/root/https_dns_proxy/src/utils.c:391:13: warning: incompatible implicit declaration of built-in function ‘strlen’
   int len = strlen(buf);
             ^
/root/https_dns_proxy/src/utils.c:405:5: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
     for (int i = 0; i < 2; i++) {
     ^
/root/https_dns_proxy/src/utils.c:405:5: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code
/root/https_dns_proxy/src/utils.c: In function ‘type_bitmap_dec’:
/root/https_dns_proxy/src/utils.c:425:22: warning: initialization makes pointer from integer without a cast
   char *rrtype_str = strtok_r(buf, " ", &saveptr);
                      ^
/root/https_dns_proxy/src/utils.c:428:3: warning: incompatible implicit declaration of built-in function ‘memset’
   memset(&bits[0], 0, sizeof(bits));
   ^
/root/https_dns_proxy/src/utils.c:440:16: warning: assignment makes pointer from integer without a cast
     rrtype_str = strtok_r(NULL, " ", &saveptr);
                ^
/root/https_dns_proxy/src/utils.c:442:3: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
   for (int i = 0; i < 256; i++) {
   ^
/root/https_dns_proxy/src/utils.c:450:5: warning: incompatible implicit declaration of built-in function ‘memcpy’
     memcpy(pos, &bits[i * 256 / 8], window_len[i]);
     ^
CMakeFiles/https_dns_proxy.dir/build.make:215: recipe for target 'CMakeFiles/https_dns_proxy.dir/src/utils.c.o' failed
make[2]: *** [CMakeFiles/https_dns_proxy.dir/src/utils.c.o] Error 1
CMakeFiles/Makefile2:60: recipe for target 'CMakeFiles/https_dns_proxy.dir/all' failed
make[1]: *** [CMakeFiles/https_dns_proxy.dir/all] Error 2
Makefile:117: recipe for target 'all' failed
make: *** [all] Error 2

error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode

compile error

In file included from /mmc/include/curl/curl.h:2426:0,
                 from /mmc/compile/https_dns_proxy/src/https_client.c:5:
/mmc/compile/https_dns_proxy/src/https_client.c: In function 'https_fetch_ctx_cleanup':
/mmc/compile/https_dns_proxy/src/https_client.c:123:28: error: 'CURLINFO_HTTP_VERSION' undeclared (first use in this function)
                 ctx->curl, CURLINFO_HTTP_VERSION, &long_resp)) != CURLE_OK) {
                            ^
/mmc/compile/https_dns_proxy/src/https_client.c:123:28: note: each undeclared identifier is reported only once for each function it appears in
/mmc/compile/https_dns_proxy/src/https_client.c:141:28: error: 'CURLINFO_PROTOCOL' undeclared (first use in this function)
                 ctx->curl, CURLINFO_PROTOCOL, &long_resp)) != CURLE_OK) {
                            ^
make[2]: *** [CMakeFiles/https_dns_proxy.dir/build.make:159: CMakeFiles/https_dns_proxy.dir/src/https_client.c.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/Makefile2:68: CMakeFiles/https_dns_proxy.dir/all] Error 2
make: *** [Makefile:128: all] Error 2

TXT Records not Properly Parsed

Since I have changed my Lede router's DNSMasq to forward the DNS requests to 127.0.0.1:5053, on which https_dns_proxy is running my IPTV stopped working completely. Changing the destination server to 8.8.8.8 instantly fixes the issue. I've captured the DNS request to and response from DNSMasq with the working configuration in which the request is forwarded to google directly, and the same thing where the request is sent to the proxy.

Working setup:

22:18:49.361244 IP 192.168.1.187.60201 > 192.168.1.1.53: 2+ TXT? sap.stb.itvonline.nl. (38)
0x0000: 4a67 c7cf 4838 0002 9bdd 8780 0800 4500 Jg..H8........E.
0x0010: 0042 8403 4000 4011 329b c0a8 01bb c0a8 .B..@[email protected].......
0x0020: 0101 eb29 0035 002e 7bce 0002 0100 0001 ...).5..{.......
0x0030: 0000 0000 0000 0373 6170 0373 7462 0969 .......sap.stb.i
0x0040: 7476 6f6e 6c69 6e65 026e 6c00 0010 0001 tvonline.nl.....
22:18:49.369894 IP 192.168.1.1.53 > 192.168.1.187.60201: 2 1/0/0 TXT "SAP/1/224.3.2.6:9875" (71)
0x0000: 0002 9bdd 8780 4a67 c7cf 4838 0800 4500 ......Jg..H8..E.
0x0010: 0063 885a 4000 4011 2e23 c0a8 0101 c0a8 .c.Z@.@..#......
0x0020: 01bb 0035 eb29 004f 846d 0002 8180 0001 ...5.).O.m......
0x0030: 0001 0000 0000 0373 6170 0373 7462 0969 .......sap.stb.i
0x0040: 7476 6f6e 6c69 6e65 026e 6c00 0010 0001 tvonline.nl.....
0x0050: c00c 0010 0001 0000 03d0 0015 1453 4150 .............SAP
0x0060: 2f31 2f32 3234 2e33 2e32 2e36 3a39 3837 /1/224.3.2.6:987
0x0070: 35 5

Nonworking setup:

22:22:30.082757 IP 192.168.1.187.34002 > 192.168.1.1.53: 2+ TXT? sap.stb.itvonline.nl. (38)
0x0000: 4a67 c7cf 4838 0002 9bdd 8780 0800 4500 Jg..H8........E.
0x0010: 0042 83fd 4000 4011 32a1 c0a8 01bb c0a8 .B..@[email protected].......
0x0020: 0101 84d2 0035 002e e225 0002 0100 0001 .....5...%......
0x0030: 0000 0000 0000 0373 6170 0373 7462 0969 .......sap.stb.i
0x0040: 7476 6f6e 6c69 6e65 026e 6c00 0010 0001 tvonline.nl.....
22:22:30.097732 IP 192.168.1.1.53 > 192.168.1.187.34002: 2 1/0/0 TXT ""SAP/1/224.3.2.6:9875"" (73)
0x0000: 0002 9bdd 8780 4a67 c7cf 4838 0800 4500 ......Jg..H8..E.
0x0010: 0065 bb6a 4000 4011 fb10 c0a8 0101 c0a8 .e.j@.@.........
0x0020: 01bb 0035 84d2 0051 846f 0002 8180 0001 ...5...Q.o......
0x0030: 0001 0000 0000 0373 6170 0373 7462 0969 .......sap.stb.i
0x0040: 7476 6f6e 6c69 6e65 026e 6c00 0010 0001 tvonline.nl.....
0x0050: c00c 0010 0001 0000 52d4 0017 1622 5341 ........R...."SA
0x0060: 502f 312f 3232 342e 332e 322e 363a 3938 P/1/224.3.2.6:98
0x0070: 3735 22 75"

To the naked eye, the major difference between the two responses is that with the working setup we get the answer as is, while in the non-working setup the answer is encapsulated by two double quotes. Any idea what might be going wrong with https_dns_proxy?

Edit: Sorry for the horrendous formatting of the raw packets. When I insert them into code blocks, the formatting is even worse.

Edit 2: Might even be an Issue with Google's DoH. With the verbosity cranked up I am seeing this:

[D] 1523480054.665965 https_client.c:96 CURLINFO_EFFECTIVE_URL: https://dns.google.com/resolve?name=sap.stb.itvonline.nl&type=16
[D] 1523480054.666119 https_client.c:169 Times: 0.000212, 0.000232, 0.000234, 0.000496, 0.015144, 0.015516
[D] 1523480054.666234 main.c:57 buflen 235

[D] 1523480054.666273 main.c:71 Received response for id e434: {"Status": 0,"TC": false,"RD": true,"RA": true,"AD": false,"CD": false,"Question":[ {"name": "sap.stb.itvonline.nl.","type": 16}],"Answer":[ {"name": "sap.stb.itvonline.nl.","type": 16,"TTL": 19929,"data": ""SAP/1/224.3.2.6:9875""}]}

The quotes in the answer are present (and escaped with the backslash), so https_dns_proxy seems to be parsing the result just fine. Any idea how I might be able to solve this issue?

Edit 3: It is definitely a bug in the parsing of https_dns_proxy. Record type 16 is for arbitrary human-readable text, and hence it is encapsulated by quotation marks. However, the actual information that needs to be send back within the response is the text itself, so without the quotation marks.

Edit 4: As a double check, I did the same request to Cloudflare's DoH service via the following url: https://1.1.1.1/dns-query?ct=application/dns-json&name=sap.stb.itvonline.nl&type=16

And as we can see, this response also includes those quotation marks. So it seems to be part of the DoH spec. Because if I send the same request to 8.8.8.8 or 1.1.1.1 I receive the answer without any quotation marks.

Support more DoH servers

Hello Aaron,
There are DoH servers which currently do not seem to work with this proxy:

https://dns.adguard.com/dns-query?
https://dns-family.adguard.com/dns-query?
https://doh.cleanbrowsing.org/doh/security-filter/?ct&
https://doh.cleanbrowsing.org/doh/family-filter/?ct&
https://doh.cleanbrowsing.org/doh/adult-filter/?ct&
https://dns.digitale-gesellschaft.ch/dns-query?
https://odvr.nic.cz/doh?
https://dns.quad9.net:5053/dns-query?
https://dns9.quad9.net:5053/dns-query?
https://dns10.quad9.net:5053/dns-query?
https://dns11.quad9.net:5053/dns-query?

I'm not competent enough in the protocol/C code to figure out if support can be added easily.

Could you please advise if it's just the incorrect URL/missing parameters which are required to make it work or if you need to modify something in the sources to add the support for the above.

Thanks!

segmentation fault with curl 7.60 on Arch Linux

It was working until recent upgrade to curl 7.60
Works OK if I disable http/2 with the -x option.

• Edit:
  This happens when used in conjunction with dnsmasq or unbound. I cant replicate with the dig command.

Default to (1.1.1.1 / 1.0.0.1) Cloudflare's DNS-over-HTTPS service

https://blog.cloudflare.com/announcing-1111/

Please default to the new Cloudflare 1.1.1.1/1.0.0.1 doh service.

Since users are seeking privacy by using this proxy app, it doesn't make sense to continue with Google's service since they likely are already logging, processing and monetizing our DNS queries.

compile bug

options.c:36:26: error: 'optarg' undeclared (first use in this function)
opt->listen_addr = optarg;

any mt7620a release for openwrt 15.05.1?

Any mt7620a released ipk for openwrt 15.05.1? Install failed.

Unknown package 'https_dns_proxy'.
Collected errors:
 * opkg_install_cmd: Cannot install package https_dns_proxy.

support for 1.1.1.1

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.

Do not change user's custom config of dnsmasq

You said you maintain the package for OpenWrt as well. Then read my thoughts about your startup script /etc/init.d/https_dns_proxy.
Shortly: do not change user's custom configuration of another packages!
For example, mine configuration of dnsmasq uses ~20 dns providers: several instances for dnscrypt-proxy, several for stubby and three for https_dns_proxy (and yes, there are some others providers of DoH, not only Google and Cloudflare!). And now I suddenly discovered that startup script of your new version of https_dns_proxy crosses out all my efforts on dnsmasq config making "doh_backup_server" instead of "server". And it is not as good as it seems, because after that changes dnsmasq uses only your https_dns_proxy and none of the others specified in the config.
Are you understand? You want to help "stupid" users but if user is really stupid then nothing can help him.
Please consider to remove such "helpers" as dhcp_backup function an so on, from startup script for OpenWrt.
Thank you.

openwrt 19.07 CURLINFO_RESPONSE_CODE: 0

Hi,

Looks like this is a curl issue but I'm putting it here so others who may look for this issue can find it.

I'm running a pre released openwrt 19.07 on x86 and I've been constantly getting periods of time where https-dns-proxy did not respond to dns queries. Looking at the logs I can see that the curl request immediately returned with a response code of zero. The proxy would recover in about a couple of minutes until the next period of curl errors.

openwrt 19.07 has curl 7.65.3 and I found an open issue with curl not detecting dead connections: curl/curl#4246
It seems that curl 7.65.1 did not exhibit this issue and sure enough after I downgraded my curl to 7.65.1 https-dns-proxy works fine with no issue.

Also, I have two https-dns-proxy instances, one uses a socks proxy and the other do not. The one with the socks proxy did not have any issue, regardless of the curl version.

[D] 1569266163.986096 https_client.c:96 CURLINFO_EFFECTIVE_URL: https://dns.goog
le/resolve?name=google.com&type=1
[D] 1569266163.986103 https_client.c:108 CURLINFO_RESPONSE_CODE: 0
[D] 1569266163.986110 https_client.c:173 Times: 0.000062, 0.000065, 0.000065, 0.
000109, 0.000000, 0.000134
[D] 1569266163.986138 main.c:81 buflen 0

Not working (sometimes)?

My apologies in advance as this may not be a very good bug report. I've spent a lot of time trying to get the proxy to work reliably, but I'm still not clear what it going wrong.

I'm running LEDE 17.01.4 on a TP-Link Archer C7 v2, and I built the 2018-04-23 version of https_dns_proxy, based on the current Makefile in the packages feed.

(As a side note, it would be nice if the DNS polling timeout was adaptive or at least shorter. I initially had the proxy started on boot only, but because the network wasn't ready yet, the DNS lookup would fail and it would wait 2 minutes to retry. I now have a hotplug script to restart the proxy whenever a network interface goes up, that seems to have bypassed the wait.)

Sometimes when the proxy is started, usually at boot or soon after, in the debug log I can see requests:

[D] 1528893225.373079 main.c:115 Received request for 'www.icloud.com' id: ffda, type 28, flags 0100
[D] 1528893225.373549 https_client.c:57 Requesting HTTP/1.1: 1

[D] 1528893225.789908 main.c:115 Received request for 'www.icloud.com' id: 4048, type 1, flags 0100
[D] 1528893225.790256 https_client.c:57 Requesting HTTP/1.1: 1

but the responses will have 0 length:

[D] 1528893226.830422 https_client.c:96 CURLINFO_EFFECTIVE_URL: https://cloudflare-dns.com/dns-query?ct=application/dns-json&name=www.icloud.com&type=1
[D] 1528893226.830473 https_client.c:108 CURLINFO_RESPONSE_CODE: 0
[D] 1528893226.830491 https_client.c:169 Times: 0.000246, 0.242603, 0.000000, 0.000000, 0.000000, 2.250143
[D] 1528893226.830551 main.c:80 buflen 0

[D] 1528893226.830580 https_client.c:96 CURLINFO_EFFECTIVE_URL: https://cloudflare-dns.com/dns-query?ct=application/dns-json&name=www.icloud.com&type=28
[D] 1528893226.830598 https_client.c:108 CURLINFO_RESPONSE_CODE: 0
[D] 1528893226.830616 https_client.c:169 Times: 0.000247, 0.297239, 0.000000, 0.000000, 0.000000, 2.259714
[D] 1528893226.830672 main.c:80 buflen 0

I've used the -x switch (and it says it's using HTTP/1.1 for requests) but it doesn't seem to help. If I restart the proxy (either manually or automatically by my hotplug script), sometimes it will get responses with actual JSON content.

I'd really like to have this resolved, as I don't want to worry about my DNS not working whenever my router is restarted 😆

new version not working

run
./https_dns_proxy -a 0.0.0.0 -p 5053

dig domain.com @ServerIP -p 5053
nothing happend

an old version workd very well

macos compile error

10.12.6 Sierra, Darwin 16.7.0 Darwin Kernel Version 16.7.0: Thu Jun 15 17:36:27 PDT 2017; root:xnu-3789.70.16~2/RELEASE_X86_64

xcode-select --install
xcode-select --switch /Library/Developer/CommandLineTools
brew doctor
brew install c-ares socat libev
curl 7.54.0

git clone https://github.com/aarond10/https_dns_proxy.git
cd https_dns_proxy
cmake .
-- Configuring done
-- Generating done
-- Build files have been written to: ./https_dns_proxy

make
[ 11%] Linking C executable https_dns_proxy
ld: library not found for -lcares
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [https_dns_proxy] Error 1
make[1]: *** [CMakeFiles/https_dns_proxy.dir/all] Error 2
make: *** [all] Error 2

Any suggestions on how to resolve this error or any additional detail needed? Thanks.

Not binding to port when run from Systemd

I am trying to write a systemd unit file to handle running https_dns_proxy as a system service. However, for some reason https_dns_proxy doesn't want to listen for connections when its run by systemd. When I take the command that systemd executes to run https_dns_proxy and run it manually through the command line, it works fine however.

More details at this StackOverflow question:

When I run a program the command line that listens on a specified address and port, it works perfectly fine:

/usr/bin/https_dns_proxy -t http://localhost:3128 -a 127.0.0.1 -p 5054

Give me:

dig @127.0.0.1 -p 5054 www.amazon.com

; <<>> DiG 9.11.3-1ubuntu1-Ubuntu <<>> @127.0.0.1 -p 5054 www.amazon.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5356
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.amazon.com.			IN	A

;; ANSWER SECTION:
www.amazon.com.		162	IN	CNAME	www.cdn.amazon.com.
www.cdn.amazon.com.	46	IN	CNAME	www.amazon.com.edgekey.net.
www.amazon.com.edgekey.net. 105	IN	CNAME	e15316.ci.akamaiedge.net.
e15316.ci.akamaiedge.net. 6	IN	A	104.117.47.132

;; Query time: 29 msec
;; SERVER: 127.0.0.1#5054(127.0.0.1)
;; WHEN: Mon Jun 11 13:52:15 EDT 2018
;; MSG SIZE  rcvd: 158

However, when I run the program through systemd, it does not work:

$ sudo systemctl status https-dns-proxy.service 
● https-dns-proxy.service - Resolve DNS queries over HTTPS.
   Loaded: loaded (/lib/systemd/system/https-dns-proxy.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since Mon 2018-06-11 13:52:09 EDT; 1min 20s ago
  Process: 8338 ExecStart=/usr/bin/https_dns_proxy ${DAEMON_ARGS} (code=killed, signal=TERM)
 Main PID: 8338 (code=killed, signal=TERM)
$ sudo systemctl start https-dns-proxy.service 
$ sudo systemctl status https-dns-proxy.service 
● https-dns-proxy.service - Resolve DNS queries over HTTPS.
   Loaded: loaded (/lib/systemd/system/https-dns-proxy.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2018-06-11 13:54:31 EDT; 2s ago
 Main PID: 12635 (https_dns_proxy)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/https-dns-proxy.service
           └─12635 /usr/bin/https_dns_proxy -t http://localhost:3128 -a 127.0.0.1 -p 5054

Jun 11 13:54:31 DEV-M-20T3W systemd[1]: Started Resolve DNS queries over HTTPS..

$ dig @127.0.0.1 -p 5054 www.amazon.com

; <<>> DiG 9.11.3-1ubuntu1-Ubuntu <<>> @127.0.0.1 -p 5054 www.amazon.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Why when running the program with systemd does the app no listen on the specified port?

The unit file:

[Unit]
Description=Resolve DNS queries over HTTPS. 
After=network.target

[Service]
User=nobody
Group=nogroup
EnvironmentFile=-/etc/default/https-dns-proxy
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
ExecStart=/usr/bin/https_dns_proxy ${DAEMON_ARGS}

[Install]
WantedBy=multi-user.target

can't connect to cloudflare dns if using direct ip address https://1.1.1.1/

I tried to use 1.1.1.1 as t he name resolver, https://1.1.1.1/dns-query?ct=application/dns-json& but got a connection timeout error, I can only use the domain name https://cloudflare-dns.com/

same situation for https://9.9.9.9/

master no longer compiles on Ubuntu 16.04

As of sha 03f3285 ( pull request #62 by @wowczarek ) the following compile error occurs on Ubuntu 16.04:

Scanning dependencies of target https_dns_proxy
[ 27%] Building C object CMakeFiles/https_dns_proxy.dir/src/dns_poller.c.o
/home/bmr/git/https_dns_proxy/src/dns_poller.c: In function ‘dns_poller_init’:
/home/bmr/git/https_dns_proxy/src/dns_poller.c:93:11: warning: implicit declaration of function ‘ares_set_servers_ports_csv’ [-Wimplicit-function-declaration]
   if((r = ares_set_servers_ports_csv(d->ares, bootstrap_dns)) != ARES_SUCCESS) {
           ^
...

CMakeFiles/https_dns_proxy.dir/src/dns_poller.c.o: In function `dns_poller_init':
/home/bmr/git/https_dns_proxy/src/dns_poller.c:93: undefined reference to `ares_set_servers_ports_csv'
collect2: error: ld returned 1 exit status
CMakeFiles/https_dns_proxy.dir/build.make:277: recipe for target 'https_dns_proxy' failed
make[2]: *** [https_dns_proxy] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/https_dns_proxy.dir/all' failed
make[1]: *** [CMakeFiles/https_dns_proxy.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2

The version of c-ares shipped with Ubuntu 16.04 is 1.10.0 and the function call ares_set_servers_ports_csv() was added in 1.11.0 ( c-ares/c-ares@7972adc).

I am able to build by cloning https://github.com/c-ares/c-ares , building tip, and using LIBRARY_PATH when running CMake and setting LD_LIBRARY_PATH before calling https_dns_proxy.

It'd probably be a good idea for either the README, or checking ares_version.h ARES_VERSION_MINOR is 11 or larger when running CMake.

A strange problem

openwrt 18.02+https_dns_proxy 2018-04-23-3

When use google.com + hdp, everything is fine.
When use rubyfish.cn + hdp , WIN10 LTSC can't get IP, but no problem with Android.
Check dnsmasq's log, google & rubyfish reply the same IP.
Then use WireShark to capture the DNS reply message, rubyfish's reply message has some error:

[Malformed Packet: DNS]
    [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
        [Malformed Packet (Exception occurred)]
        [Severity level: Error]
        [Group: Malformed]

rubyfish/hdp/LTSC, I don't know which one is the culprit.

Could I install it on Openwrt 15.05?

I found the package in the snapshots repository.But I couldn't find it in any other Openwrt repository and I was running Openwrt 15.05 on my router.Will it be added to the repository of Openwrt 15.05?

How to make it work on LEDE?

Hi! Linux noob here.

I put 'list server = 127.0.0.1:5053' on dnsmasq config and enabled and started https_dns_proxy on init.
But doesn't resolve any dns queries.

Do I have to reroute dns request through IPTables thanks!

Any chance to support OpenResolve by OpenDNS?

Google is good, but we can try another way.

https://www.openresolve.com/

debian/raspbian can't setup

I must be doing something wrong, and cannot figure out what. Are the environment variables to the INCLUDE_DIRs looking correct?

rpi3 Raspbian GNU/Linux 9.1 (stretch)
Linux 4.9.53-v7+ #1040 SMP Fri Oct 6 14:19:18 BST 2017 armv7l GNU/Linux

sudo apt-get install -y shadowsocks-libev libc-ares2 cmake

ls /usr/lib/arm-linux-gnueabihf/
libev.so.4 libcares.so.2 libcurl-gnutls.so.4 libcurl.so.4

env | grep LIB
LIBCARES_INCLUDE_DIR=/usr/lib/arm-linux-gnueabihf
LIBEV_INCLUDE_DIR=/usr/lib/arm-linux-gnueabihf
LIBCURL_INCLUDE_DIR=/usr/lib/arm-linux-gnueabihf


cmake .
-- The C compiler identification is GNU 6.3.0
-- The CXX compiler identification is GNU 6.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
LIBCARES_INCLUDE_DIR
   used as include directory in directory /home/jim/https_dns_proxy
LIBCURL_INCLUDE_DIR
   used as include directory in directory /home/jim/https_dns_proxy
LIBEV_INCLUDE_DIR
   used as include directory in directory /home/jim/https_dns_proxy

-- Configuring incomplete, errors occurred!


CMakeFiles/CMakeOutput.log
1 The system is: Linux - 4.9.53-v7+ - armv7l
...
472 Detecting CXX [-std=c++98] compiler features compiled with the following output:
473 Change Dir: /home/jim/https_dns_proxy/CMakeFiles/CMakeTmp
474
475 Run Build Command:"/usr/bin/make" "cmTC_fa1d0/fast"
476 /usr/bin/make -f CMakeFiles/cmTC_fa1d0.dir/build.make CMakeFiles/cmTC_fa1d0.dir/build
477 make[1]: Entering directory '/home/jim/https_dns_proxy/CMakeFiles/CMakeTmp'
478 Building CXX object CMakeFiles/cmTC_fa1d0.dir/feature_tests.cxx.o
479 /usr/bin/c++     -std=c++98 -o CMakeFiles/cmTC_fa1d0.dir/feature_tests.cxx.o -c /home/jim/https_dns_proxy/CMakeFiles/feature_tests.cxx
480 Linking CXX executable cmTC_fa1d0
481 /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_fa1d0.dir/link.txt --verbose=1
482 /usr/bin/c++        CMakeFiles/cmTC_fa1d0.dir/feature_tests.cxx.o  -o cmTC_fa1d0 -rdynamic
483 make[1]: Leaving directory '/home/jim/https_dns_proxy/CMakeFiles/CMakeTmp'
484
485
486     Feature record: CXX_FEATURE:0cxx_aggregate_default_initializers
487     Feature record: CXX_FEATURE:0cxx_alias_templates
488     Feature record: CXX_FEATURE:0cxx_alignas
489     Feature record: CXX_FEATURE:0cxx_alignof
490     Feature record: CXX_FEATURE:0cxx_attributes
491     Feature record: CXX_FEATURE:0cxx_attribute_deprecated
492     Feature record: CXX_FEATURE:0cxx_auto_type
493     Feature record: CXX_FEATURE:0cxx_binary_literals
494     Feature record: CXX_FEATURE:0cxx_constexpr
495     Feature record: CXX_FEATURE:0cxx_contextual_conversions
496     Feature record: CXX_FEATURE:0cxx_decltype
497     Feature record: CXX_FEATURE:0cxx_decltype_auto
498     Feature record: CXX_FEATURE:0cxx_decltype_incomplete_return_types
499     Feature record: CXX_FEATURE:0cxx_default_function_template_args
500     Feature record: CXX_FEATURE:0cxx_defaulted_functions
501     Feature record: CXX_FEATURE:0cxx_defaulted_move_initializers                                                                                                                                                                          502     Feature record: CXX_FEATURE:0cxx_delegating_constructors                                                                                                                                                                              503     Feature record: CXX_FEATURE:0cxx_deleted_functions                                                                                                                                                                                    504     Feature record: CXX_FEATURE:0cxx_digit_separators                                                                                                                                                                                     505     Feature record: CXX_FEATURE:0cxx_enum_forward_declarations                                                                                                                                                                            506     Feature record: CXX_FEATURE:0cxx_explicit_conversions                                                                                                                                                                                 507     Feature record: CXX_FEATURE:0cxx_extended_friend_declarations                                                                                                                                                                         508     Feature record: CXX_FEATURE:0cxx_extern_templates
509     Feature record: CXX_FEATURE:0cxx_final
510     Feature record: CXX_FEATURE:0cxx_func_identifier
511     Feature record: CXX_FEATURE:0cxx_generalized_initializers
512     Feature record: CXX_FEATURE:0cxx_generic_lambdas
513     Feature record: CXX_FEATURE:0cxx_inheriting_constructors
514     Feature record: CXX_FEATURE:0cxx_inline_namespaces
515     Feature record: CXX_FEATURE:0cxx_lambdas
516     Feature record: CXX_FEATURE:0cxx_lambda_init_captures
517     Feature record: CXX_FEATURE:0cxx_local_type_template_args
518     Feature record: CXX_FEATURE:0cxx_long_long_type
519     Feature record: CXX_FEATURE:0cxx_noexcept
520     Feature record: CXX_FEATURE:0cxx_nonstatic_member_init
521     Feature record: CXX_FEATURE:0cxx_nullptr
522     Feature record: CXX_FEATURE:0cxx_override
523     Feature record: CXX_FEATURE:0cxx_range_for
524     Feature record: CXX_FEATURE:0cxx_raw_string_literals
525     Feature record: CXX_FEATURE:0cxx_reference_qualified_functions
526     Feature record: CXX_FEATURE:0cxx_relaxed_constexpr
527     Feature record: CXX_FEATURE:0cxx_return_type_deduction
528     Feature record: CXX_FEATURE:0cxx_right_angle_brackets
529     Feature record: CXX_FEATURE:0cxx_rvalue_references
530     Feature record: CXX_FEATURE:0cxx_sizeof_member
531     Feature record: CXX_FEATURE:0cxx_static_assert
532     Feature record: CXX_FEATURE:0cxx_strong_enums
533     Feature record: CXX_FEATURE:1cxx_template_template_parameters
534     Feature record: CXX_FEATURE:0cxx_thread_local
535     Feature record: CXX_FEATURE:0cxx_trailing_return_types
536     Feature record: CXX_FEATURE:0cxx_unicode_literals
537     Feature record: CXX_FEATURE:0cxx_uniform_initialization
538     Feature record: CXX_FEATURE:0cxx_unrestricted_unions
539     Feature record: CXX_FEATURE:0cxx_user_literals
540     Feature record: CXX_FEATURE:0cxx_variable_templates
541     Feature record: CXX_FEATURE:0cxx_variadic_macros
542     Feature record: CXX_FEATURE:0cxx_variadic_templates

Try to use -rpath? How to resolve?

warning: libmbedtls.so.10, needed by libcurl.so, not found (try using -rpath or -rpath-link).

When I compile padavan source for mt7620, I met this problem. Hot to resolve this problem?

Not work. I get an error when I test with dig

./https_dns_proxy -r "https://cloudflare-dns.com/resolve?ct=application/dns-json&"
[E] 1544533631.106395 https_client.c:246 libcurl bug detected: socket closed without ever being read.
[E] 1544533631.106434 https_client.c:247 Activating workaround.  PERFORMANCE WILL BE GREATLY DEGRADED!

Ubuntu 16.04