High performance DNS over HTTPS client & server

https://developers.google.com/speed/p…

Client and server software to query DNS over HTTPS, using Google DNS-over-HTTPS protocol and IETF DNS-over-HTTPS (RFC 8484).

Guide

Tutorial to setup your own DNS-over-HTTPS (DoH) server. (Thanks to Antoine Aflalo)

Installing

Install Go, at least version 1.10.

(Note for Debian/Ubuntu users: You need to set $GOROOT if you could not get your new version of Go selected by the Makefile.)

First create an empty directory, used for $GOPATH:

mkdir ~/gopath
export GOPATH=~/gopath

To build the program, type:

make

To install DNS-over-HTTPS as Systemd services, type:

sudo make install

By default, Google DNS over HTTPS is used. It should work for most users (except for People's Republic of China). If you need to modify the default settings, type:

sudoedit /etc/dns-over-https/doh-client.conf

To automatically start DNS-over-HTTPS client as a system service, type:

sudo systemctl start doh-client.service
sudo systemctl enable doh-client.service

Then, modify your DNS settings (usually with NetworkManager) to 127.0.0.1.

To test your configuration, type:

dig www.google.com

If it is OK, you will wee:

;; SERVER: 127.0.0.1#53(127.0.0.1)

Uninstalling

To uninstall, type:

sudo make uninstall

The configuration files are kept at /etc/dns-over-https. Remove them manually if you want.

Server Configuration

The following is a typical DNS-over-HTTPS architecture:

+--------------+                                +------------------------+
| Application  |                                |  Recursive DNS Server  |
+-------+------+                                +-----------+------------+
        |                                                   |
+-------+------+                                +-----------+------------+
| Client side  |                                |      doh-server        |
| cache (nscd) |                                +-----------+------------+
+-------+------+                                            |
        |         +--------------------------+  +-----------+------------+
+-------+------+  |    HTTP cache server /   |  |   HTTP service muxer   |
|  doh-client  +--+ Content Delivery Network +--+ (Apache, Nginx, Caddy) |
+--------------+  +--------------------------+  +------------------------+

Although DNS-over-HTTPS can work alone, a HTTP service muxer would be useful as you can host DNS-over-HTTPS along with other HTTPS services.

HTTP/2 with at least TLS v1.3 is recommended. OCSP stapling must be enabled, otherwise DNS recursion may happen.

Example configuration: Apache

SSLProtocol TLSv1.2
SSLHonorCipherOrder On
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+3DES:!aNULL:!MD5:!DSS:!eNULL:!EXP:!LOW:!MD5
SSLUseStapling on
SSLStaplingCache shmcb:/var/lib/apache2/stapling_cache(512000)


    ServerName MY_SERVER_NAME
    Protocols h2 http/1.1
    ProxyPass /dns-query http://[::1]:8053/dns-query
    ProxyPassReverse /dns-query http://[::1]:8053/dns-query

(Credit: Joan Moreau)

Example configuration: Nginx

server {
    listen       443 ssl http2;
    listen       [::]:443 ssl http2;
    server_name  MY_SERVER_NAME;

    server_tokens off;

    ssl_protocols TLSv1.2 TLSv1.3;          # TLS 1.3 requires nginx >= 1.13.0
    ssl_prefer_server_ciphers on;
    ssl_dhparam /etc/nginx/dhparam.pem;     # openssl dhparam -dsaparam -out /etc/nginx/dhparam.pem 4096
    ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
    ssl_ecdh_curve secp384r1;               # Requires nginx >= 1.1.0
    ssl_session_timeout  10m;
    ssl_session_cache shared:SSL:10m;
    ssl_session_tickets off;                # Requires nginx >= 1.5.9
    ssl_stapling on;                        # Requires nginx >= 1.3.7
    ssl_stapling_verify on;                 # Requires nginx => 1.3.7 
    resolver 1.1.1.1 valid=300s;            # Replace with your local resolver
    resolver_timeout 5s;
    # HTTP Security Headers
    add_header X-Frame-Options DENY;
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
    add_header Strict-Transport-Security "max-age=63072000";
    ssl_certificate /path/to/your/server/certificates/fullchain.pem;
    ssl_certificate_key /path/to/your/server/certificates/privkey.pem;
    location /dns-query {
        proxy_pass       http://localhost:8053/dns-query;
        proxy_set_header Host      $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

备注：上面配置文件内的ssl_early_data off那一行已被我删除。如果加那一行，重启nginx时，反而会遇错。

上面配置文件内的default_server也是多余的，也被我删了。

(Credit: Cipherli.st)

Example configuration: Caddy

https://MY_SERVER_NAME {
        log     / syslog "{remote} - {user} [{when}] \"{method} {scheme}://{host}{uri} {proto}\" {status} {size} \"{>Referer}\" \"{>User-Agent}\" {>X-Forwarded-For}"
        errors  syslog
        gzip
        proxy   /dns-query      http://[::1]:18053 {
                header_upstream Host {host}
                header_upstream X-Real-IP {remote}
                header_upstream X-Forwarded-For {>X-Forwarded-For},{remote}
                header_upstream X-Forwarded-Proto {scheme}
        }
        root    /var/www
        tls {
                ciphers ECDHE-ECDSA-WITH-CHACHA20-POLY1305 ECDHE-RSA-WITH-CHACHA20-POLY1305 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-GCM-SHA256
                curves  X25519 p384 p521
                must_staple
        }
}

DNSSEC

DNS-over-HTTPS is compatible with DNSSEC, and requests DNSSEC signatures by default. However signature validation is not built-in. It is highly recommended that you install unbound or bind and pass results for them to validate DNS records.

EDNS0-Client-Subnet (GeoDNS)

DNS-over-HTTPS supports EDNS0-Client-Subnet protocol, which submits part of the client's IP address (/24 for IPv4, /56 for IPv6 by default) to the upstream server. This is useful for GeoDNS and CDNs to work, and is exactly the same configuration as most public DNS servers.

Keep in mind that /24 is not enough to track a single user, although it is precise enough to know the city where the user is located. If you think EDNS0-Client-Subnet is affecting your privacy, you can set no_ecs = true in /etc/dns-over-https/doh-client.conf, with the cost of slower video streaming or software downloading speed.

To ultilize ECS, X-Forwarded-For or X-Real-IP should be enabled on your HTTP service muxer. If your server is backed by unbound or bind, you probably want to configure it to enable the EDNS0-Client-Subnet feature as well.

Protocol compatibility

Google DNS-over-HTTPS Protocol

DNS-over-HTTPS uses a protocol compatible to Google DNS-over-HTTPS, except for absolute expire time is preferred to relative TTL value. Refer to json-dns/response.go for a complete description of the API.

IETF DNS-over-HTTPS Protocol

DNS-over-HTTPS uses a protocol compatible to IETF DNS-over-HTTPS (RFC 8484).

Supported features

Currently supported features are:

•  IPv4 / IPv6
•  EDNS0 large UDP packet (4 KiB by default)
•  EDNS0-Client-Subnet (/24 for IPv4, /56 for IPv6 by default)

The name of the project

This project is named "DNS-over-HTTPS" because it was written before the IETF DoH project. Although this project is compatible with IETF DoH, the project is not affiliated with IETF.

To avoid confusion, you may also call this project "m13253/DNS-over-HTTPS" or anything you like.

from https://github.com/m13253/dns-over-https

我的补充说明：

在linux vps上。先安装go,然后，

cd $GOPATH

go get -u -v github.com/m13253/dns-over-https/doh-server/

安装完成后，doh-server会出现在$GOBIN下面。

[root@host gopath]# which doh-server

/root/go/gopath/bin/doh-server

[root@host gopath]# doh-server -h

Usage of doh-server:

  -conf string

     Configuration file (default "doh-server.conf")

  -pid-file string

     PID file for legacy supervision systems lacking support for reliable cgroup-based process tracking

  -verbose

     Enable logging

  -version

     Show software version and exit

[root@host gopath]# cd ~

[root@host ~]# find / -name doh-server.conf

/root/go/gopath/src/github.com/m13253/dns-over-https/doh-server/doh-server.conf

[root@host ~]# cp /root/go/gopath/src/github.com/m13253/dns-over-https/doh-server/doh-server.conf ~/

[root@host ~]# nano doh-server.conf

[root@host ~]# cat doh-server.conf

# HTTP listen port

listen = [

    ":8053",

    ## To listen on both 0.0.0.0:8053 and [::]:8053, use the following line

    # ":8053",

]

# Local address and port for upstream DNS

# If left empty, a local address is automatically chosen.

local_addr = ""

# TLS certification file

# If left empty, plain-text HTTP will be used.

# You are recommended to leave empty and to use a server load balancer (e.g.

# Caddy, Nginx) and set up TLS there, because this program does not do OCSP

# Stapling, which is necessary for client bootstrapping in a network

# environment with completely no traditional DNS service.

cert = ""

# TLS private key file

key = ""

# HTTP path for resolve application

path = "/dns-query"

# Upstream DNS resolver

# If multiple servers are specified, a random one will be chosen each time.

upstream = [

    "8.8.8.8:53",

    "8.8.4.4:53",

]

# Upstream timeout

timeout = 10

# Number of tries if upstream DNS fails

tries = 3

# Only use TCP for DNS query

tcp_only = false

# Enable logging

verbose = false

# Enable log IP from HTTPS-reverse proxy header: X-Forwarded-For or X-Real-IP

# Note: http uri/useragent log cannot be controlled by this config

log_guessed_client_ip = false

[root@host ~]# nano /etc/systemd/system/doh-server.service

[root@host ~]# cat /etc/systemd/system/doh-server.service

[Unit]

After=network.target

[Service]

ExecStart=/root/go/gopath/bin/doh-server -conf /root/doh-server.conf

Restart=always

[Install]

WantedBy=multi-user.target

[root@host ~]# systemctl start doh-server

[root@host ~]# systemctl enable doh-server

然后在vps上，安装nginx1.14,按上面的Example configuration: Nginx段的内容，添加该段内容至你的nginx的配置文件内，然后重启nginx.

这样，服务器端搭建完成。

在本地机器mac.先安装go,然后，

cd $GOPATH

go get -u -v github.com/m13253/dns-over-https/doh-client/

安装完成后，doh-client会出现在$GOBIN下面。

doh-client -h

会显示：

Usage of doh-client:

  -conf string

    Configuration file (default "doh-client.conf")

  -verbose

    Enable logging

  -version

     Show software version and exit

sudo find / -name doh-client.conf

会显示：

...

$GOPATH/src/github.com/m13253/dns-over-https/doh-client/doh-client.conf

...

cp $GOPATH/src/github.com/m13253/dns-over-https/doh-client/doh-client.conf ~/

cd ~

nano doh-client.conf

(启用里面的3行：

[[upstream.upstream_ietf]]

url = "https://9.9.9.9/dns-query"

weight = 50

或者这3行：

[[upstream.upstream_ietf]]

url = "https://1.1.1.1/dns-query"

weight = 50  ）

sudo  $GOBIN/doh-client -conf ~/doh-client.conf

不过在doh-client.conf文件里，像上面那样去启用那2段之一，并没有用到所搭建的‘ DNS over HTTPS’ 服务器。要用到所搭建的‘ DNS over HTTPS’ 服务器，先把上面所启用的那2段之一都禁用掉：

nano doh-client.conf

(把bootstrap = [

内容

]

改为:

bootstrap = [
"208.67.222.222:443",
]

注意：上面的"208.67.222.222:443"一定要使用非53的端口，比如443或5353.建议使用443端口，速度更快。事实上，208.67.222.222:443，208.67.222.222:5353，208.67.220.220:443，208.67.220.220:5353这四组之一都行。你把它们全部加进去也行：
bootstrap = [
"208.67.222.222:443",
"208.67.222.222:5353",
"208.67.220.220:443",
"208.67.220.220:5353",
]

其实，你还可在自己的vps上安装dnsmasq
(apt-get install dnsmasq -y或yum install -y dnsmasq)
所有的配置都在一个文件中完成/etc/dnsmasq.conf, Dnsmasq配置文件是/etc/dnsmasq.conf，下面对Dnsmasq中和DNS相关的配置项进行说明:

用指定的端口代替默认的DNS 53端口，如果设置为0，则完全禁止DNS功能.
port=53538

从不转发格式错误的域名:

domain-needed

从不转发不在路由地址中的域名:

bogus-priv

然后，运行dnsmasq即可。然后，在本地机器，修改doh-client.conf文件，在

bootstrap = [

...

] 的...处，加上"my-vps-ip:53538",

使用了一段时间，还是觉得把doh server的域名的 IP 地址直接写到/etc/hosts文件里比较可靠。如果使用bootstrap DNS 的方式，有时不能完全的加载被封网站。
(详见https://github.com/m13253/dns-over-https/issues/65），使用这种方式，需先把

bootstrap = [

...

] 的方括号里的内容全部注释掉或删除，然后去修改/etc/hosts文件。

然后，在这行## Google's resolver, good ECS, good DNSSEC的上方加上：

[[upstream.upstream_ietf]]

url = "https://mydomain.com/dns-query"

weight = 100

保存更改。然后运行：

sudo $GOBIN/doh-client -conf ~/doh-client.conf

使用例子：

运行全局代理程序mellow

sudo networksetup -setdnsservers "Wi-Fi" 127.0.0.1

sudo $GOBIN/doh-client -conf ~/doh-client.conf

然后，就可以用全局代理程序mellow任意翻墙。

（OpenDNS 开放非常规端口 5353查询和 TCP查询，即使从国内直接请求也不容易被污染和劫持。如果你在使用 ChinaDNS 这类工具同时又没有专门为其准备一条加密隧道，那么直连 OpenDNS 的 5353 就是一个不错的替代选择。）

---------------

自建DoH服务

1. 前言

DoH（DNS over HTTPS），顾名思义，使用HTTPS协议执行DNS查询，除了最常用的UDP外，还有DoT（DNS over TLS），DNS over HTTP（服务提供商自定义）等方案，对比如下：

协议	标准	描述
DNS over HTTPS	RFC8484	使用TLS加密的HTTP/2执行DNS查询
DNS over TLS	RFC7858	使用TLS加密的TCP执行DNS查询
DNS over HTTP	服务提供商自定义	使用自定义加密的HTTP/1.1执行DNS查询

移动端的DNS优化已经有很多实践，最常见的是DNS over HTTP，通过加密的HTTP请求规避运营商对DNS的UDP包劫持，从而优化App访问服务器的延迟。但这个方案并没有形成统一的标准，通常需要内嵌DNS服务提供商的SDK，通过访问固定的BGP或任播IP获取DNS响应。

大概是意识到DNS在移动互联网中的扮演越来越重要的角色，在DoT和DoH的规范相继推出后，许多DNS服务提供商都跟进了部署，国内的阿里云、DNSPod，国外的谷歌、Cloudflare等目前已经推出了免费的DoT和DoH服务。

客户端方面，常用的Chrome、FireFox已经支持了自定义DoH服务器，macOS、iOS也可通过配置文件设置系统范围的默认DoH服务器。

笔者也正好有一个自定义DNS的需求：

1. 需要针对一些域名的DNS查询仅返回IPv4记录
2. 使用的某某路由器系统的自定义DNS服务仅支持设置UDP和DoH
3. UDP模式默认使用53端口，不可修改，UDP包容易遭受干扰
4. DoH可自定义域名、端口且使用HTTP2作为传输协议，稳定性更强

综上，只有自建DoH服务了，于是就有了下面的折腾，最后测试时发现这个傻瓜路由器系统只支持一些特定的DoH服务商如阿里云DNS、DNSPod等，不支持自建的DoH服务。

2. 部署方案

DoH本质上就是一个HTTP请求，只是目前协议定义要求启用TLS与HTTP/2。最初没有跑通coredns的DoH时，使用了nginx作为前端转发DoH请求到doh-server，然后doh-server使用本地的coredns服务作为上游。

最近再仔细研究了下文档，发现coredns已经支持了DoH服务，可直接对外暴露服务，或者通过nginx转发来复用已经部署好的web服务。

2.1 nginx + doh-server + coredns

https://github.com/m13253/dns-over-https 是一个提供 DNS over HTTP 的服务，需要一个web前端和一个DNS后端，可用的docker镜像地址为：satishweb/doh-server，使用doh-server时，DNS请求流转如下：

1	HTTP Service -> doh-server -> DNS Server

RFC8484中指定使用/dns-query路径作为默认查询路径，因此只需要将该路径前缀的请求转发到doh-server即可，如下：

nginx配置（已配置好TLS与HTTP2）

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

server { listen 443 ssl http2 fastopen=256 reuseport; listen [::]:443 ssl http2 fastopen=256 reuseport; server_name doh.wbuntu.com ... location /dns-query { proxy_redirect off; proxy_http_version 1.1; proxy_set_header Host $http_host; # show real IP proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://127.0.0.1:8053; } }

doh-server

使用hostNetwork模式启动服务，监听8053端口

1 2 3 4 5 6 7 8

docker run -d --restart unless-stopped --network host --name doh-server \ -e UPSTREAM_DNS_SERVER="udp:127.0.0.1:53" \ -e DOH_HTTP_PREFIX="/dns-query" \ -e DOH_SERVER_LISTEN="127.0.0.1:8053" \ -e DOH_SERVER_TIMEOUT="10" \ -e DOH_SERVER_TRIES="3" \ -e DOH_SERVER_VERBOSE="true" \ satishweb/doh-server

coredns

coredns配置文件如下

1 2 3 4 5 6 7 8 9 10 11 12 13

➜ ~ tree /etc/coredns/ /etc/coredns/ └── Corefile 0 directories, 1 files ➜ cat /etc/coredns/Corefile .:53 { bind 127.0.0.1 forward . 1.1.1.1 1.0.0.1 log errors cache }

使用hostNetwork模式启动服务，监听53端口

1 2 3 4

docker run -d --restart unless-stopped --network host --name coredns \ -v /etc/coredns:/etc/coredns \ coredns/coredns \ -conf /etc/coredns/Corefile

服务启动后，我们可以得到一个自定义的DoH服务：https://doh.wbuntu.com/dns-query

2.2 coredns

目前coredns支持作为DoH服务端，不支持连接上游DoH服务器，上游服务器可使用UDP和DoT。

直接对外暴露服务需要使用有效的TLS证书，coredns配置文件及证书位置如下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

➜ ~ tree /etc/coredns/ /etc/coredns/ ├── Corefile ├── tls.crt └── tls.key 0 directories, 3 files ➜ cat /etc/coredns/Corefile https://.:443 { tls /etc/coredns/tls.crt /etc/coredns/tls.key bind 0.0.0.0 forward . 1.1.1.1 1.0.0.1 log errors cache }

使用hostNetwork模式启动服务，监听443端口

1 2 3 4

docker run -d --restart unless-stopped --network host --name coredns \ -v /etc/coredns:/etc/coredns \ coredns/coredns \ -conf /etc/coredns/Corefile

服务启动后，我们可以得到一个自定义的DoH服务：https://doh.wbuntu.com/dns-query

2.3 nginx + coredns

直接暴露coredns服务到公网需要占用端口，coredns在未配置TLS证书时，可使用nginx作为前端来复用web服务，如下：

nginx配置（已配置好TLS与HTTP2）

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

server { listen 443 ssl http2 fastopen=256 reuseport; listen [::]:443 ssl http2 fastopen=256 reuseport; server_name doh.wbuntu.com ... location /dns-query { proxy_redirect off; proxy_http_version 1.1; proxy_set_header Host $http_host; # show real IP proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://127.0.0.1:8053; } }

coredns

coredns配置文件如下

1 2 3 4 5 6 7 8 9 10 11 12 13

➜ ~ tree /etc/coredns/ /etc/coredns/ └── Corefile 0 directories, 1 files ➜ cat /etc/coredns/Corefile https://.:8053 { bind 127.0.0.1 forward . 1.1.1.1 1.0.0.1 log errors cache }

使用hostNetwork模式启动服务，监听8053端口

1 2 3 4

docker run -d --restart unless-stopped --network host --name coredns \ -v /etc/coredns:/etc/coredns \ coredns/coredns \ -conf /etc/coredns/Corefile

服务启动后，我们可以得到一个自定义的DoH服务：https://doh.wbuntu.com/dns-query

3. 测试

使用谷歌浏览器配置DoH服务：Settings -> Secutiry and Privacy -> Secutiry -> Advanced -> Use secure DNS.

--------------------------------------------------

(Cloudflare 與 ISP 合作推出 DoH 加強隱私，然後 Google 想要看 HTTPS 流量

Cloudflare 推出了 ODoH (目前是 IETF 的 draft：「Oblivious DNS Over HTTPS」)：「Improving DNS Privacy with Oblivious DoH in 1.1.1.1」，在 Hacker News 上面也有討論：「 Improving DNS Privacy with Oblivious DoH (cloudflare.com)」

基本上就是 DNS over HTTPS 在上面架一層 Proxy，但這層 Proxy 不能是 Cloudflare 自己：

 

這樣一來 Cloudflare 知道 IP address 的機會就會比較小，藉以達到要求，先前要達到這樣的效果必須透過 ISP 提供的 HTTP/HTTPS Proxy (像是已經淘汰的 proxy.hinet.net：「HiNet 宣佈年底關閉 Proxy 服務」)，或是透過 Tor，但 Tor 的效能會讓 query 速度慢不少。這次的這個服務的確是好不少...

技術上來說，當 Cloudflare 與 ISP 都把所有的 packet 記錄下來後，兩邊合作還是可以取得原始的 IP 資訊，以這個例子來說，你跟總部在香港的 PCCW 集團合作，看起來就不怎麼吸引人啊...

不過隔壁棚的 Google 則是讓人吐血中，打算用 Prefetch 名義看到你的 HTTPS 流量：「Continuing our journey to bring instant experiences to the whole web」，這樣一來，就有不少的機會 Google 可以分析出來使用者在看什麼 Netflix 影片了 (要看 Prefetch 到什麼程度，2017 年的時候做出來有 99.99% 的準確度)：「利用 Side-channel 資訊判斷被 HTTPS 保護的 Netflix 影片資訊」。

來坐著等看 Google 這邊的好戲...)

----------------

Tutorial to setup your own DNS-over-HTTPS (DoH) server

Introduction

Traditional DNS queries and responses are sent over UDP or TCP without encryption. This is vulnerable to eavesdropping and spoofing (including DNS-based Internet filtering). Responses from recursive resolvers to clients are the most vulnerable to undesired or malicious changes, while communications between recursive resolvers and authoritative name servers often incorporate additional protection. (Google)

To simplify, anybody on your network, your ISP, etc … can easily spoof DNS response and decide to send you to a different website than the one you desired. Also, it has some privacy implication where anybody between you and the DNS server can know what website you visit.

Guide

The guide is divided in multiple part. The first one covers how to setup a DNS-over-HTTPS (DoH) while using dnscrypt-proxy as DNS server to answer the requests.

The second part explains how to make couple of changes to that configuration to have PiHole (dns server that block ads) as DNS server behind DoH.

The third part explains how to add DNS-over-TLS to your setup. Useful if you own Android 9 (Pie) devices.

The last  part will provide you with a list of client for Windows, Linux, Android and iOS that supports DoH natively to be able to use it on all your devices.

Server

I advise you to setup a free f1 micro instance at Google Cloud Computing. You can setup anywhere you want, I only advise there because they have a good image for Ubuntu 18.04 and the f1 micro instance is free forever. All the request the machine will do will be encrypted and not accessible by Google.

Again, if you’re more familiar with Digital Ocean, AWS, etc … please use the hosting provider you know the best. For this guide, I only advise you to have a Debian based image (Debian, Ubuntu, etc …)

Architecture

DNS-over-HTTPS server

The next step is to install the server that implement the DoH protocol to get an HTTP request and do a DNS request.

I provide 2 ways to install it, either you download the deb I provide or you compile the program (in golang) yourself.

Download

For this tutorial, I’ve taken the time to compile and package DNS-over-HTTPS (Golang) and provide a deb file easily installable.

Download Now!

Compile

If you prefer to build it yourself, you can follow the guide provided in the GitHub repository.

After compiling you can use FPM to build the package.

1. 
   
2. 
   
3. 
   
4. 
   

Install

_{If you compile it yourself, you won’t need to do this, the make install will have already taken care of it.}

1. sudo dpkg -i doh-server_*_amd64.deb

This will install and start the service for you.

Configuration

Open the file /etc/dns-over-https/doh-server.conf in your favorite editor. Keep somewhere the listen IP/Port. We’ll need it when we’ll setup Nginx.

Change upstream variable.

1. # HTTP listen port
2. listen = [
3. "127.0.0.1:8053",
4. "[::1]:8053",
5. ]
6. 
   
7. # TLS certification file
8. # If left empty, plain-text HTTP will be used.
9. # You are recommended to leave empty and to use a server load balancer (e.g.
10. # Caddy, Nginx) and set up TLS there, because this program does not do OCSP
11. # Stapling, which is necessary for client bootstrapping in a network
12. # environment with completely no traditional DNS service.
13. cert = ""
14. 
    
15. # TLS private key file
16. key = ""
17. 
    
18. # HTTP path for resolve application
19. path = "/dns-query"
20. 
    
21. # Upstream DNS resolver
22. # If multiple servers are specified, a random one will be chosen each time.
23. upstream = [
24. "127.0.0.1:53",
25. ]
26. 
    
27. # Upstream timeout
28. timeout = 60
29. 
    
30. # Number of tries if upstream DNS fails
31. tries = 10
32. 
    
33. # Only use TCP for DNS query
34. tcp_only = false
35. 
    
36. # Enable logging
37. verbose = false

This will tell DoH-server to use our dnscrypt-proxy to do its DNS requests.

Once done, restart the service.

1. sudo systemctl restart doh-server

Nginx

This section focus on installing and configuring Nginx to take care of the HTTPS part of DNS-over-HTTPS. To do this, we configure it as a reverse proxy and use let’s encrypt to generate a certificate.

Install

We add the PPA with TLS 1.3 of Nginx to get the latest stable version with TLS 1.3.

1. sudo add-apt-repository ppa:ondrej/nginx
2. sudo apt install nginx-full

Configuration

This is an example of a configuration. You need to change the server_name to the domain you’ll use for DoH. Also check that the uptream server point to doh-server ip and port. If you didn’t change anything in the configuration of doh-server, it’s already configured correctly.

For now, we don’t enable SSL, this will be done after with certbot & let’s encrypt.

1. upstream dns-backend {
2. server 127.0.0.1:8053;
3. }
4. 
   
5. server {
6. listen 80;
7. server_name dns.example.com;
8. root /var/www/html/dns;
9. access_log /var/log/nginx/dns.access.log;
10. 
    
11. location /dns-query {
12. proxy_set_header X-Real-IP $remote_addr;
13. proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
14. proxy_set_header Host $http_host;
15. proxy_set_header X-NginX-Proxy true;
16. proxy_http_version 1.1;
17. proxy_set_header Upgrade $http_upgrade;
18. proxy_redirect off;
19. proxy_set_header X-Forwarded-Proto $scheme;
20. proxy_read_timeout 86400;
21. proxy_pass http://dns-backend/dns-query ;
22. }
23. }

Put the content of the configuratione into /etc/nginx/sites-available/dns-over-https.

Then do a symlink to the enabled folder. Ask Nginx to check that to configuration works, and reload nginx.

1. sudo ln -s /etc/nginx/sites-available/dns-over-https /etc/nginx/sites-enabled/dns-over-https
2. sudo nginx -t
3. sudo systemctl reload nginx

And there you go, you have now Nginx that will takes care of serving HTTP request to doh-server.

Stapling

The idea is to make Nginx take care of checking if the certificate is expired and keep that information in cache. This is to avoid doing too many requests on the Certificate Authority (CA) of the certificate.

Definition

Create a new file into /etc/nginx/conf.d/stapling.conf with the following content:

1. ssl_stapling on;
2. ssl_stapling_verify on;
3. resolver 127.0.2.1;

This will activate the stapling for all your website hosted with Nginx and using HTTPS.
Feel free to change the resolver variable. By default I made it use the dnscrypt-proxy we configured, but you can change it to any other DNS server.

Certbot

Certbot is the tool developed by EFF to help you request SSL certificate using let’s encrypt. Not only it will generate a certificate for your domain, it will also configure Nginx for you and take care of renewing the certificate.

Install

Usually the version available in the distribution is a little old. We’re going to use the official PPA.

1. sudo add-apt-repository ppa:certbot/certbot
2. sudo apt install python-certbot-nginx

Configuration

Certbot provides a variety of ways to obtain SSL certificates, through various plugins. The Nginx plugin will take care of reconfiguring Nginx and reloading the config whenever necessary:

1. sudo certbot --nginx -d dns.example.com

This runs certbot with the --nginx plugin, using -d to specify the names we’d like the certificate to be valid for.

If this is your first time running certbot, you will be prompted to enter an email address and agree to the terms of service. After doing so, certbot will communicate with the Let’s Encrypt server, then run a challenge to verify that you control the domain you’re requesting a certificate for.

If that’s successful, certbot will ask how you’d like to configure your HTTPS settings.

1. Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
2. -------------------------------------------------------------------------------
3. 1: No redirect - Make no further changes to the webserver configuration.
4. 2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
5. new sites, or if you're confident your site works on HTTPS. You can undo this
6. change by editing your web server's configuration.
7. -------------------------------------------------------------------------------
8. Select the appropriate number [1-2] then [enter] (press 'c' to cancel):

I advise to choose redirect to be sure it use only HTTPS.

SSL Defaults

Certbot comes with “good-enough” SSL defaults, but they haven’t been updated in a while. It keeps support for TLS1.0 which has been deprecated for years. No device should use it anymore. Moreover the chosen cypher list contains weak cyphers. To resolve this issue, I compiled a new configuration file for you to replace the weak defaults of Certbot.

Edit the file /etc/letsencrypt/options-ssl-nginx.conf and replace its content by this.

1. # This file contains important security parameters. If you modify this file
2. # manually, Certbot will be unable to automatically provide future security
3. # updates. Instead, Certbot will print and log an error message with a path to
4. # the up-to-date file that you will need to refer to when manually updating
5. # this file.
6. 
   
7. ssl_session_cache shared:le_nginx_SSL:1m;
8. ssl_session_timeout 1440m;
9. 
   
10. ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3;
11. 
    
12. 
    
13. # Enable modern TLS cipher suites
14. ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
15. 
    
16. # The order of cipher suites matters
17. ssl_prefer_server_ciphers on;
18. 
    
19. add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Then reload nginx.

1. sudo systemctl reload nginx

Renewal

By design, the certificate will expire in 90 days. Certbot will take care of renewing it 30 days before expiry. In the case you want to test the renewal process you can run this command.

If you remove the --dry-run, you’ll actively ask Certbot to renew the certificate.

1. sudo certbot renew --dry-run

Conclusion

Congratulation you have now a DNS-over-HTTPS server running that can accept request at https://dns.example.com/dns-query.

This conclude the first part of the guide. The second convers the differents clients available, like dnscrypt-proxy (windows/linux) and Intra (Android). And the third one how to make this DoH block advertising.

from https://www.aaflalo.me/2018/10/tutorial-setup-dns-over-https-server/
(https://www.bentasker.co.uk/documentation/linux/407-building-and-running-your-own-dns-over-https-server#doh-server)

-----------------https://dnsprivacy.org/wiki/display/DP/Running+a+DNS+Privacy+server#RunningaDNSPrivacyserver-DoTNameserverConfiguration (很有参考价值）

------------------

A lightweight DNS-over-HTTPS proxy.

https_dns_proxy

https_dns_proxy is a light-weight DNS over HTTPS, non-caching translation proxy for the emerging DoH 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.com/resolve?"

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?ct=application/dns-json&"

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 li="">
• 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, libcurl, libev.

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

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

$ cmake .
$ make

INSTALL

There is no installer at this stage - just run it.

OpenWRT package install

I maintain 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

Replace any 'list server' lines in /etc/config/dhcp with:

list server '127.0.0.1#5053'

You may also want to add the line:

noresolv '1'

This prevents dnsmasq from using /etc/resolv.conf DNS servers, leaving only our proxy server.

archlinux package install

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

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

Usage

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

Usage: ./https_dns_proxy [-a ] [-p ]
        [-d] [-u ] [-g ] [-b ]
        [-r ] [-e ]
        [-t ] [-l ] [-x] [-v]+

  -a listen_addr         Local 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 address of DNS servers
                         to resolve resolver host (e.g. dns.google.com).  (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)
  -r resolver_url_prefix The HTTPS path to the JSON resolver URL.  (https://dns.google.com/resolve?)
  -e subnet_addr         An edns-client-subnet to use such as "203.31.0.0/16".  ()
  -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. (-)
  -x                     Use HTTP/1.1 instead of HTTP/2. Useful with broken
                         or limited builds of libcurl (false).
  -v                     Increase logging verbosity. (INFO)

Alternative protocols


The DoH standard is still evolving. Because responses are translated into JSON, there is room for error in encoding and parsing response types - particularly the less common ones.


For this reason, I tend to believe DNS-over-TLS is a better long-term strategy for the industry, but proxy clients aren't yet readily available.


Note that fundamental differences (binary vs JSON encoding) mean this software does not and will not support DNS-over-TLS.





from https://github.com/aarond10/https_dns_proxy

https://github.com/aarond10/https_dns_proxy/issues/54 (在mac上，build失败）

---------









Google Public DNS offers DNSSEC-validating resolution over an encrypted HTTPS.

Thanks

https://github.com/fardog/secureoperator
https://developers.cloudflare.com/1.1.1.1/dns-over-https/
https://developers.google.com/speed/public-dns/docs/dns-over-https




Docker

https://hub.docker.com/r/chenhw2/https-dns




TODO

Currently only Block DNS TYPE:ANY
More thorough tests should be written
No caching is implemented, and probably never will




Usage
$ docker pull chenhw2/https-dns

$ docker run -d \
    -e "ARGS=-d 8.8.8.8 --edns 0.0.0.0/0" \
    -p "5300:5300/udp" \
    -p "5300:5300/tcp" \
    chenhw2/https-dns



Help
$ docker run --rm chenhw2/https-dns -h
NAME:
   https-dns - A DNS-protocol proxy for Google's DNS-over-HTTPS service.

USAGE:
   https-dns [global options] command [command options] [arguments...]

VERSION:
   MISSING build version [git hash]

COMMANDS:
     help, h  Shows a list of commands or help for one command

GLOBAL OPTIONS:
   --listen value, -l value           Serve address (default: ":5300")
   --proxy value, -p value            Proxy (SOCKS or SHADOWSOCKS) Server for HTTP GET
   --endpoint value                   Google DNS-over-HTTPS endpoint url (default: "https://dns.google.com/resolve")
   --endpoint-ips value, --eip value  IPs of the Google DNS-over-HTTPS endpoint; if provided, endpoint lookup skip
   --dns-servers value, -d value      DNS Servers used to look up the endpoint; system default is used if absent.
   --edns value, -e value             Extension mechanisms for DNS (EDNS) is parameters of the Domain Name System (DNS) protocol.
   --no-pad, -N                       Disable padding of Google DNS-over-HTTPS requests to identical length
   --insecure, -I                     Disable SSL/TLS Certificate check (for some OS without ca-certificates)
   --udp, -U                          Listen on UDP
   --tcp, -T                          Listen on TCP
   -V value                           log level for V logs (default: 2)
   --logtostderr                      log to standard error instead of files
   --help, -h                         show help
   --version, -v                      print the version



 from https://github.com/honwen/https-dns







我的补充说明：




https://briteming.blogspot.com/2019/12/https-dns-by-honwendns.html














搭建智能的DNS服务器：https-dns

众所周知，DNS 污染是较常遭遇的攻击手段之一。

以 ChinaDNS 为代表，目前自动解决这个问题的思路是多 DNS 对比：同时查询较快的本地 DNS（通常为 ISP 的 DNS）和较慢的可信 DNS（通常为经过加密传输的 Google 或 OpenDNS 等），对比返回的结果，若有差异，说明本地 DNS 返回的结果大概率被污染。
以此为基础，配合国内网站和国内 CDN 的白名单（直接使用本地 DNS）、被封锁网站的黑名单（直接使用可信 DNS）基本上达到了兼顾功能（反污染）和效率（国内跳过）的效果。
这个思路的缺点也很明显：
- 如果使用白名单，截至今天（2018.01.26），白名单 accelerated-domains.china.conf 已经包含了 39881 条记录，这对很多路由器上的 dnsmasq 造成了不小的压力。而实际上，在这么一份大而全、更新飞快的列表中，大部分人使用的只是很小一部分。
- 如果不使用白名单，仅使用黑名单，对于非重度网络使用者，其实是一个可以接受的方案。
- 如果不使用白名单也不使用黑名单，结果更糟糕。这种情况下一般会启用类似 GEO IP: CN => DIRECT; FINAL => PROXY
 的自动规则，由于目前绝大部分大中型网站均在多个区域部署 CDN 进行加速，对这些网站查询可信 DNS 
有非常大的概率会返回一个对本地来说负优化的结果（为远端 VPS 或者代理优化，解析到一个对本地较慢的 CDN 节点），甚至网站会根据 GEO 
IP 的结果强制跳转（如淘宝海外站）。
- 路由器版本的 ChinaDNS 有时会出一些莫名其妙的问题导致不能正常解析，非常影响心情。

改进思路

为了弥补这些缺点，我们提出以下需求：
- 只查询一个本地 DNS，或者，一个快的远端 可信 DNS（考虑到大部分地区到 114.114.114.114 和 119.29.29.29 的延迟，可以认为 30-45 左右的延迟是可以接受的）。
- 不使用庞大的白名单和黑名单。
- 确保解析到的结果为本地优化。

针对后两点，技术上其实已经有了解决方案，那就是 RFC 7871 (Client Subnet in DNS Queries, aka edns-client-subnet, ECS)，RFC 文档见此，还可参考 Google 的帮助。
ECS 允许 DNS 解析的请求放附带一个网络地址，要求 DNS 服务器做出针对这个地址优化的解析响应。
但是，ECS 目前的实施还是非常不接地气的。国内大厂多有成熟的智能解析方案，国外大厂更由于隐私等诸多问题对此动力不足。即便是目前对 ECS 支持的最好的 Google Public DNS，发过去的请求包也只有一半可以得到正确的 ECS 响应。
因此 Google 提供了一种迂回的解决方案：DNS-over-HTTPS（文档）。不使用不能稳定得到 ECS 响应的 DNS 协议，通过 HTTPS 协议可以稳定获取 ECS 响应。
我们可以从这个方案中得到一个新思路，将 DNS 请求转化为 HTTPS 请求，再将收到的响应转化为 DNS 响应返回（事实上会小幅度增加解析耗时）。

部署

实现这个思路有两种部署方案：

本地部署

下载https://github.com/honwen/https-dns/releases（Go 语言，支持包括 ARM 在内的多种CPU），参照作者的说明安装在本地路由器或其他设备上为局域网提供服务，通过前置的代理（支持 socks 或影梭）访问 Google 的 DNS over HTTPS。

远端部署

推荐以容器的形式部署。
远端部署的优势是可以共享自建的DNS。
这种方式将 google-https-dns 作为后端提供服务，同时在前端放置一个支持 ECS 缓存的 DNS 代理（推荐使用Unbound）以获得更高性能。
部署方式如下，也可以参考 这份 Gist：
1. 创建 google-https-dns 的容器：docker run -d --name dns-google --log-opt max-size=1m --restart=unless-stopped tarot13/google-https-dns
2. 准备 Unbound 的配置文件 unbound.conf（见后文）和 Root Hints root.hints（可以从 ftp://FTP.INTERNIC.NET/domain/named.cache 下载）
3. 创建 Unbound 的容器：docker
 run -d --name dns-unbound -v $HOME/unbound:/etc/unbound -p 53:53/tcp -p
 53:53/udp --link=dns-google:dns-google --log-opt max-size=1m 
--restart=unless-stopped tarot13/unbound

供参考的 unbound.conf 配置：
需要注意的是其中的两项：
1. ECS 缓存（subnetcache）必须在模块配置中启用：module-config: "subnetcache iterator"
2. 最好指定允许发送 ECS 信息的上游 DNS 网段（即 google-https-dns 的地址）：send-client-subnet: 172.16.0.0/12
server:
  username: "root"
  interface: 0.0.0.0
  verbosity: 1
  do-daemonize: no
  access-control: 0.0.0.0/0 allow
  root-hints: "/etc/unbound/root.hints" # Root Hints: ftp://FTP.INTERNIC.NET/domain/named.cache
  auto-trust-anchor-file: "/etc/unbound/root.key" # Auto generated
  do-ip4: yes
  do-ip6: no
  do-udp: yes
  do-tcp: yes
  hide-identity: yes
  hide-version: yes
  harden-glue: yes
  use-caps-for-id: yes
  cache-max-ttl: 3600
  prefetch: yes
  num-threads: 4
  msg-cache-size: 64m
  rrset-cache-size: 128m
  module-config: "subnetcache iterator"
  unwanted-reply-threshold: 10000000
  do-not-query-localhost: no
  send-client-subnet: 172.16.0.0/12
  minimal-responses: yes

  forward-zone:
    name: "."
    forward-host: dns-google


使用

对于本地部署，局域网内的其他设备可以直接使用。
对于远端部署，可以选择通过非 53 端口转发，或者通过任意方法加密传输。

测试记录：

dig with subnet (web), mainland IPs.



-------------------------------------------------------


 dnss

dnss is a daemon for using DNS over HTTPS.


It can act as a proxy (the most common use case)


Features

Supports the JSON-based protocol as implemented by dns.google.com (reference).
Supports the DNS Queries over HTTPS (DoH) proposed standard (and implemented by Cloudflare's 1.1.1.1).
Local cache (optional).
HTTP(s) proxy support, autodetected from the environment.
Monitoring HTTP server, with exported variables and tracing to help debugging.
Separate resolution for specific domains, useful for home networks with local DNS servers.



Install



Debian/Ubuntu


The dnss package installs the daemon configured in proxy mode and ready to use, using Google's public resolvers (and easily changed via configuration).
sudo apt install dnss



Manual install

To download and build the binary:
go install blitiri.com.ar/go/dnss


And if you want to configure the daemon to be automatically run by systemd:

# Copy the binary to a system-wide location.
sudo cp "$GOPATH/bin/dnss" /usr/local/bin/

# Set it up in systemd.
sudo cp "$GOPATH"/src/blitiri.com.ar/go/dnss/etc/systemd/dns-to-https/* \
    /etc/systemd/system/

sudo systemctl dnss enable




Listens on port 53 for DNS queries, resolves them using the given HTTPS URL.

# Use the default HTTPS URL (currently, dns.google.com):
dnss -enable_dns_to_https

# Use Cloudflare's 1.1.1.1:
dnss -enable_dns_to_https -https_upstream="https://1.1.1.1/dns-query"

# Use Google's dns.google.com:
dnss -enable_dns_to_https -https_upstream="https://dns.google.com/resolve"

Supports both DoH and JSON modes automatically, and the endpoints are /dns-query and /resolve.

from https://blitiri.com.ar/git/r/dnss/b/next/t/f=README.md.html

(DNS over HTTPS https://blitiri.com.ar/git/r/dnss/

dnss


dnss is a daemon for using DNS over HTTPS.


It can act as a proxy (the most common use case), and as a server (in case you want end to end control).





Features


Supports the JSON-based protocol as implemented by dns.google.com (reference).
Supports the DNS Queries over HTTPS (DoH) proposed standard (and implemented by Cloudflare's 1.1.1.1).
Local cache (optional).
HTTP(s) proxy support, autodetected from the environment.
Monitoring HTTP server, with exported variables and tracing to help debugging.
Separate resolution for specific domains, useful for home networks with local DNS servers.



Install


Debian/Ubuntu


The dnss package installs the daemon configured in proxy mode and ready to use, using Google's public resolvers (and easily changed via configuration).


sudo apt install dnss



Manual install


To download and build the binary:


go install blitiri.com.ar/go/dnss



And if you want to configure the daemon to be automatically run by systemd:


# Copy the binary to a system-wide location.
sudo cp "$GOPATH/bin/dnss" /usr/local/bin/

# Set it up in systemd.
sudo cp "$GOPATH"/src/blitiri.com.ar/go/dnss/etc/systemd/dns-to-https/* \
 /etc/systemd/system/

sudo systemctl dnss enable




DNS proxy mode on client machine:


Listens on port 53 for DNS queries, resolves them using the given HTTPS URL:


# Use the default HTTPS URL (currently, dns.google.com):
dnss -enable_dns_to_https

# Use Cloudflare's 1.1.1.1:
dnss -enable_dns_to_https -https_upstream="https://1.1.1.1/dns-query"

# Use Google's dns.google.com:
dnss -enable_dns_to_https -https_upstream="https://dns.google.com/resolvess"



sudo ~/go1.10.2/go/bin/dnss -enable_dns_to_https -https_upstream="https://mydomain.com/dns-query" -dns_listen_addr :53 -force_mode DoH


from https://github.com/albertito/dnss)
Alberto Bertogli's dnss, a daemon written in Go which act as a proxy (the most common use-case).
-----------------------------------------
cd $GOPATH
go get -u -v github.com/rameezk/secure-dns
cd src/github.com/rameezk/secure-dns/
go build
会在当前目录下，生成可执行文件：secure-dns。

sudo ./secure-dns -listen_addr :53 -https_upstream https://mydomain.com/dns-query

注意：此处的https://mydomain.com/dns-query必须是
用https://github.com/m13253/dns-over-https/搭建的doh server.
项目地址：https://github.com/rameezk/secure-dns
------------------------------------------------------------------





















A proof of concept DNS-Over-HTTPS proxy implementing https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https








A set of python 3 scripts that supports proxying DNS over HTTPS as specified in the IETF Draft draft-ietf-doh-dns-over-https.



DOH provides a way to run encrypted DNS over HTTPS, a protocol which can freely traverse firewalls when other encrypted mechanism may be blocked.

DOH Proxy was created during IETF Hackathon 100 as a proof-of-concept.

-------
A DNS-protocol proxy for DNS-over-HTTPS providers, such as Google and Cloudflare.



 



A DNS-protocol proxy for DNS-over-HTTPS: allows you to run a server on your local network which responds to DNS queries, but requests records across the internet using HTTPS.



It's known to work with the following providers:



Google - Well tested and configured by default
Cloudflare (Beta) - May be used by passing the --cloudflare flag
Quad9 (Beta) - May be used by passing the `--quad9' flag




If you're interested in a more roll-your-own-DNS system, you might look at dnoxy, a sibling project to secureoperator which allows running your own DNS-over-HTTPS servers.



Installation



You may retrieve binaries from the releases page, or install using go get: 

cd $GOPATH

go get -u -v github.com/fardog/secureoperator/cmd/secure-operator

(THEN,THE executable file secure-operator will appear in $GOBIN/)


This will start a DNS server listening on TCP and UDP at :53. For usage information, run secure-operator --help.




Note: Running a service on port 53 requires administrative privileges on most systems.

(sudo secure-operator -listen :53 -google ) 


























sudo ~/go1.10.2/go/bin/secure-operator -listen :53 -endpoint https://mydomain.com/dns-query -endpoint-ips vps-ip (必须加上“-endpoint-ips vps-ip”.这个程序不错）




Docker




There is a Docker image available for secureoperator:


docker pull fardog/secureoperator




The latest tag will always be the build from the master branch. If you wish to use one of the stable releases, use its version tag when pulling, e.g.:


docker pull fardog/secureoperator:4  # latest of major version
docker pull fardog/secureoperator:4.0  # latest of minor version
docker pull fardog/secureoperator:4.0.1  # exact version




Version Compatibility




This package follows semver for its tagged releases. The master branch is always considered stable, but may break API compatibility. If you require API stability, either use the tagged releases or mirror on gopkg.in:


go get -u gopkg.in/fardog/secureoperator.v4



Caching



secureoperator does not perform any caching; each request to it causes a matching request to the upstream DNS-over-HTTPS server to be made. It's recommended that you place secureoperator behind a caching DNS server such asdnsmasq on your local network.



An simple example setup is described on the wiki. Please feel free to contribute additional setups if you are running secureoperator in your environment.



Security



Note that while DNS requests are made over HTTPS, this does not imply "secure"; consider the following:



You must trust the upstream provider with your requests; for your chosen provider, see:

Google's Privacy Policy
Cloudflare's Privacy Policy


The lookup for the HTTP endpoint must happen in some regard, although how this is handled is up to you:

The system DNS resolver is used to look up the endpoint (default)
You provide a list of DNS servers to use for the endpoint lookup
You provide the IP address(es) to the endpoint; and no unencrypted DNS lookup will be performed. However if the addresses change while the service is running, you will need to restart the service to provide new addresses.





Information on the usage of these options is available with secure-operator --help.




Help Wanted



secureoperator could be greatly enhanced by community contributions! The following areas could use work:



More thorough unit tests
Installable packages for your favorite Linux distributions
Documentation on deploying secureoperator to a local network



Known Issues



Cloudflare is not fully tested yet; it should work for common cases, however:



EDNS is not supported; this is an intentional choice by Cloudflare, which means any EDNS setting you provide when using Cloudflare as a provider will be silently ignored.



For a production environment, the Google provider (default) is your best option today. If you're brave, please test Cloudflare and report any issues!




from https://github.com/fardog/secureoperator

----------------------------------



cd  $GOPATH






go get -u -v github.com/fardog/dnoxy/cmd/dnoxy-dns/

(THEN,THE executable file dnoxy-dns will appear in $GOBIN/)

sudo dnoxy-dns -listen :53 -endpoint https://mydomain.com/dns-query -tcp true -udp true 

(在运行dnoxy-dns命令之前，需先添加一行：my-vps-ip mydomain.com到/etc/hosts文件的底部。)）



项目地址：https://github.com/fardog/dnoxy



-------------------------------- 




cd  $GOPATH
go get -u -v github.com/markkurossi/vpn


sudo vpn -doh https://mydomain.com/dns-query




项目地址：https://github.com/markkurossi/vpn
------------------------------------------


cd  $GOPATH
go get -u -v github.com/hpidcock/nz














sudo nz -listen 127.0.0.1:53 -upstream https://mydomain.com/dns-query



项目地址：github.com/hpidcock/nz

------











npm install -g dohnut ，得到可执行文件~/node-v12.6.0/node-v12.6.0-darwin-x64/bin/dohnut


dohnut --help














sudo dohnut --doh https://somedomain.com/dns-query --listen :53 --datagram-protocol udp4

(在运行上面的命令之前，需先添加一行：my-vps-ip mydomain.com到/etc/hosts文件的底部。)



项目地址：https://github.com/commonshost/dohnut


--------------------------------------



go-doh-proxy



在本地机器mac上安装go环境，然后，

cd $GOPATH

go get -u -v github.com/aaronriekenberg/go-doh-proxy

wget https://github.com/aaronriekenberg/go-doh-proxy/raw/master/config/config.json -O go-doh-proxy-config.json

nano go-doh-proxy-config.json

把port的值改为53 ，把第48行改为"https://mydomain.com/dns-query" ，这个doh server不能

使用https://github.com/m13253/dns-over-https/项目里的doh server端。

这个doh server要使用rust-doh，详见https://briteming.blogspot.com/2019/12/https-dns-by-honwendns.html

里所说的“doh server程序rust-doh的搭建说明“。






sudo go-doh-proxy go-doh-proxy-config.json
项目地址：github.com/aaronriekenberg/go-doh-proxy


----------------------------------------------------------------------







godoh - A DNS-over-HTTPS C2 https://sensepost.com/blog/2018/waiti…


(godoh不好用，完全用不了）





A DNS-over-HTTPS Command & Control Proof of Concept


 

introduction

godoh is a proof of concept Command and Control framework, written in Golang, that uses DNS-over-HTTPS as a transport medium. Currently supported providers include Google, Cloudflare but also contains the ability to use traditional DNS.

installation


All you would need are the godoh binaries themselves. Binaries are available for download from the releases page as part of tagged releases.


To build godoh from source, follow the following steps:

Ensure you have dep installed (go get -u -v github.com/golang/dep/cmd/dep)
Clone this repository to your $GOPATH's src/ directory so that it is in sensepost/godoh
Run dep ensure to resolve dependencies
Run make key to generate a unique encryption key to use for communication
Use the go build tool, or run make to build the binaries in the build/ directory



usage


$ godoh -h
A DNS (over-HTTPS) C2
    Version: dev
    By @leonjza from @sensepost

Usage:
  godoh [command]

Usage:
  godoh [command]

Available Commands:
  agent       Connect as an Agent to the DoH C2
  c2          Starts the godoh C2 server
  help        Help about any command
  receive     Receive a file via DoH
  send        Send a file via DoH
  test        Test DNS communications

Flags:
  -d, --domain string     DNS Domain to use. (ie: example.com)
  -h, --help              help for godoh
  -p, --provider string   Preferred DNS provider to use. [possible: google, cloudflare, raw] (default "google")

Use "godoh [command] --help" for more information about a command.
from https://github.com/sensepost/goDoH
----------------------------------


This is the repo for draft-ietf-doh-dns-over-https, which is a contribution to the IETF discussion of how to serve DNS over HTTPS. This is part of the IETF's DOH Working Group; see https://datatracker.ietf.org/wg/doh/about/ for information about the Working Group and how to subscribe to the mailing list for discussion of this draft.



from https://github.com/dohwg/draft-ietf-doh-dns-over-https

-----------------------------------------------


a network tool for people in PRC

dns-over-https

file /dns.php

just Google DNS Mirror

parameter should base64 encode and urlencode and base64 decode the response

name=urlencode(base64encode("img.alicdn.com")) edns_client_subnet=urlencode(base64encode("123.125.18.108"))

Demo
https://prudent-travels.000webhostapp.com/dns.php?name=&edns_client_subnet=


Pac File

file /pac.php

Build by mono_pac

use proxy to foreign site and Direct to PRC site.

Demo

https://prudent-travels.000webhostapp.com/pac.php?a=SOCKS5&b=192.168.1.1:1080

generate a pac file which use SOCKS5 192.168.1.1 proxy, copy and parse to SwitchyOmega

from https://github.com/lbp0200/prc-net-tool

--------------------------------------




Dima Krasner's nss-tls, a daemon that makes gethostbyname(), getaddrinfo(), etc' happen through DoH, without any change to applications, thus transparently migrating all applications that don't use their own resolver (like some browsers) from DNS to DoH.(用命令：brew install libsoup来安装dependency: libsoup失败，遂放弃此项目）






Maxime Elomari's dealdoh, a middleware to proxy DoH requests to different DNS upstreams, written in PHP.(要求php为7.x版）

https://github.com/danielinux/dohd,

我试过，但遇错：https://github.com/danielinux/dohd/issues/1

-----------------------------------------



dohproxy

DNS over HTTPS proxy written in golang

I got interested in DNS over HTTPS after Firefox started supporting it in its latest release. I looked around to understand how it worked. Most of the implementations were too complex and did a lot of things. I read the RFC[1] and realised it was very trivial. So I tried my hand at implementing a proxy. This is just a proof of concept.

To install it you can use:
go get -u -v github.com/satran/dohproxy


This assumes you have installed go.

To run it use:
dohproxy


This will start the proxy on 5353 port.

You can resolve addresses using:
dig @127.0.0.1 -p 5353 redhat.com


Running it as a docker container

If you would like to run it as a docker container run:
docker run -it --rm -p 53:53/udp satran/dohproxy


This will run the proxy on localhost. You can update your /etc/resolv.conf file with nameserver 127.0.0.1 to resolve all dns queries using the dohproxy.

[1] https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-13




from https://github.com/satran/dohproxy











sudo ~/go1.10.2/go/bin/dohproxy -host localhost -port 53 -dohserver https://mydomain.com/dns-query



运行此程序时，有"no such host"问题,解决办法：

修改hosts文件，把mydomain.com指向你的vps的ip,具体就是：

modify the /etc/hosts file,add the following line to the bottom of the hosts file:
my-vps-ip mydomain.com

见https://github.com/satran/dohproxy/issues/6

---------------------------------------



dohproxy

A DNS-over-Https proxy and router

 

Installation

Download from the latest release page,

or install from source

$ go get -u github.com/major1201/dohproxy (未编译成功.只好下载其
可执行文件）


or run with Docker

docker run -d \
    --name dohproxy \
    -v /etc/dohproxy:/etc/dohproxy \
    -p 5353:53/udp \
    major1201/dohproxy


Usage

Start dohproxy with config /etc/dohproxy.yml
dohproxy


Start dohproxy with a custom config path

dohproxy -c /home/major1201/my-doh-config.yml


Service

# install as a service
dohproxy -c /home/major1201/my-doh-config.yml --service install

# start the service
dohproxy --service start

# stop the service
dohproxy --service stop

# uninstall the service
dohproxy --service uninstall


Configuration

log:
  stdout: stdout                  # default: stdout, log-to-file on Windows is not supported
  stderr: /var/log/dohproxy.err   # default: stderr, log-to-file on Windows is not supported
  level: info                     # default: debug, choices: debug, info, warn(warning), error, dpanic, panic, fatal

listen:
  - type: udp
    address: 127.0.0.1:53
  - type: tcp
    address: 127.0.0.1:53

upstreams:
  google-public:
    type: dns
    address: 8.8.8.8:53
  my-corp-dns:
    type: dns
    address: 192.168.53.1:53
  doh-get-with-proxy:
    type: doh-get
    address: https://some-doh-server-i-cant.com/dns-query
    proxy: socks5://127.0.0.1:1080
  doh-post:
    type: doh-post
    address: https://cloudflare-dns.com/dns-query

rules:
  - fqdn:cloudflare-dns.com      google-public
  - fqdn:www.my-dev-server.com   10.0.31.1
  - keyword:mycorp.com           my-corp-dns
  - suffix:mybiz.com             my-corp-dns
  - suffix:never-response.com    blackhole
  - suffix:adxxx.com             reject
  - wildcard:*                   doh-post


listen types:

udp
tcp


upstream types:

dns: classic DNS server
doh / doh-get: DNS-over-HTTPS protocol, using HTTP GET method
doh-post: DNS-over-HTTPS protocol, using HTTP POST method


rule format: [fqdn|prefix|suffix|keyword|wildcard|regex]:expression upstream|blackhole|reject|static_ip

upstream: upstream name defined in the upstreams field
blackhole: it never response to any dns requests, it just does nothing
reject: returns error immediately


Known Issues

The log.stdout and log.stderr part in config file only support stdout on Windows platform, due to zap package limit.



from https://github.com/major1201/dohproxy



我的补充说明：

wget https://github.com/major1201/dohproxy/releases/download/v0.2.0/dohproxy-darwin_amd64-0.2.0.tar.gz



mkdir dohproxy-darwin_amd64-0.2.0-by-major1201



mv dohproxy-darwin_amd64-0.2.0.tar.gz dohproxy-darwin_amd64-0.2.0-by-major1201



cd dohproxy-darwin_amd64-0.2.0-by-major1201



tar xvf dohproxy-darwin_amd64-0.2.0.tar.gz








./dohproxy-darwin_amd64-0.2.0 -h

显示：

...











--config value, -c value   set config file (default: "/etc/dohproxy.yml")

...




wget https://github.com/major1201/dohproxy/raw/master/example-config.yml -O  dohproxy-by-major1201-config.yml 




nano dohproxy-by-major1201-config.yml 




cat dohproxy-by-major1201-config.yml 

---

log:                              # optional

  stdout: stdout                  # default: stdout, log-to-file on Windows is not supported

  stderr: /var/log/dohproxy.err   # default: stderr, log-to-file on Windows is not supported

  level: info                     # default: debug, choices: debug, info, warn(warning), error, dpanic, panic, fatal




listen:

  - type: udp

    address: 127.0.0.1:53

  - type: tcp

    address: 127.0.0.1:53




upstreams:

 xyz-public:

   type: dns

   address: 2.2.2.2:5356

  my-corp-dns:

    type: dns

    address: 192.168.53.1:53

  doh-get-with-proxy:

    type: doh-get

    address: https://dns.google.com/resolve

    proxy: socks5://127.0.0.1:1080

  doh-post:

    type: doh-post

    address: https://mydomain.com/dns-query




rules:

  - fqdn:cloudflare-dns.com      google-public

  - fqdn:www.my-dev-server.com   10.0.31.1

  - keyword:mycorp.com           my-corp-dns

  - suffix:mybiz.com             my-corp-dns

  - suffix:never-response.com    blackhole

  - suffix:adxxx.com             reject

  - wildcard:*                   doh-post









































...




然后，






sudo ./dohproxy-darwin_amd64-0.2.0 -c dohproxy-by-major1201-config.yml

------------





在mac上，先安装go环境。然后，

cd $GOPATH







go get -u -v github.com/markdingo/trustydns/cmd/trustydns-proxy/

可执行文件trustydns-proxy就会生成在$GOBIN里面.






trustydns-proxy -h

(帮助文件的内容很多！！）






sudo trustydns-proxy -A :53 https://mydomain.com/dns-query




项目地址：https://github.com/markdingo/trustydns































----------------------------------------------------

在mac上，先安装go环境。然后，

cd $GOPATH




go get -u -v github.com/tpetr/dns-https













sudo dns-https -l 127.0.0.1:53 https://mydomain.com/dns-query




项目地址：https://github.com/tpetr/dns-https

----------------------------------------

在mac上，先安装rust环境。然后，

git clone https://github.com/mudge/homer homer-by-mudge

cd homer-by-mudge

cargo build --release

cd target/release/






sudo ./homer --bind 127.0.0.1:53 --upstream https://mydomain.com/dns-query







项目地址：https://github.com/mudge/homer

-----------------------------

在mac上，先安装go环境。然后，

cd $GOPATH







go get -u -v github.com/adnsio/dotd/cmd/dotd/














sudo dotd  -address :53 -upstream https://mydomain.com/dns-query





项目地址：https://github.com/adnsio/dotd


---------------

在本地机器mac上。先安装python3,然后，

git clone https://github.com/radixcl/pydoh pydoh-by-radixcl

cd pydoh-by-radixcl

sudo pip3 install -r requirements.txt

nano config.json

cat config.json

{

    "listen_port": 53,

    "listen_address": "0.0.0.0",

    "runas_user": "nobody",

    "runas_group": "nogroup",

    "doh_urls": [

        "https://mydomain.com/dns-query",

        "https://some-public-domain.com/dns-query"

    ]















}



然后，






sudo python3 pydoh.py




项目地址：https://github.com/radixcl/pydoh

------


doh-forwarder
在本地机器mac上。先安装python3,然后，

sudo pip3 install aiohttp 

sudo pip3 install uvloop

sudo pip3 install cchardet

wget https://github.com/kpadron/doh-forwarder/raw/master/doh-forwarder.py







sudo python3 doh-forwarder.py -l 127.0.0.1 -p 53 --tcp --upstream https://mydmain.com/dns-query



This program is a basic attempt at creating a DNS over HTTPS inline-proxy forwarder. This means that it accepts standard UDP or TCP DNS packets and converts them to DoH HTTP requests. Queries made by this program are encrypted using TLS schemes defined in the python standard library ssl. The program can be configured with command line options to support a listening address and any non-standard ports.

This program is meant to be single-threaded and is based on the python standard library asyncio. Asynchronous HTTP requests are made over encrypted connections to upstream servers via required library aiohttp. This allows for extra performance when many requests are received at once. If TCP resolving is enabled extra threads may be spawned to accept connections on the listening socket. Please note that this program was originally configured for operation with Cloudflare's public DNS servers and as such may contain specifics to that resolver.

doh-forwarder.py is the main program for this project and as such will have the most features implemented. Other scripts in this repository represent different approaches to the same problem.


项目地址：https://github.com/kpadron/doh-forwarder

--------

https://github.com/davehermann/dohcp

--------

在mac上，先安装go环境。然后，

cd $GOPATH





go get -u -v github.com/karlbateman/saber













sudo saber -host 127.0.0.1 -port 53 -resolver https://mydomain.com/dns-query





项目地址：https://github.com/karlbateman/saber

--------

在mac上，先安装go环境。然后，

cd $GOPATH







go get -u -v github.com/iamd3vil/danse




danse -h

会显示：

Usage of danse:

  -addr string

     Address to bind (default "127.0.0.1")

  -cache

     DNS response caching



  -port string

     Port for DNS server (default "53")

  -url string

























     URLs for DoH resolvers seperated by comma (default "https://cloudflare-dns.com/dns-query")







其实danse只支持doh server. 对dot server支持得并不好。






sudo danse -addr 127.0.0.1 -port 53 -url https://mydomain.com/dns-query 





项目地址：https://github.com/iamd3vil/danse

---------

在mac上，先安装go环境。然后，

cd $GOPATH












go get -u -v github.com/voidpirate/proxydoh/














sudo proxydoh -host 0.0.0.0 -port 53 -dohserver https://mydomain.com/dns-query


项目地址：github.com/voidpirate/proxydoh

-------



在mac上，先安装python3环境。然后，

git clone https://github.com/wanglihe/forwardoh forwardoh-by-wanglihe

cd forwardoh-by-wanglihe






sudo pip3 install gevent











./src/forwardoh -h

显示：

...











FileNotFoundError: [Errno 2] No such file or directory: '/etc/forwardoh.conf'




sudo nano /etc/forwardoh.conf

按此页面：https://github.com/wanglihe/forwardoh/blob/master/config/forwardoh.conf 的内容，创建/etc/forwardoh.conf文件，

其内容为：

port = 53

#url = "https://cloudflare-dns.com/dns-query"

#url = "https://mozilla.cloudflare-dns.com/dns-query"

#url = "https://1.1.1.1/dns-query"

#url = "https://1.0.0.1/dns-query"

url = "https://mydomain.com/dns-query"

cache_max = 1000

cache_refresh = 300














status_interval = 10




然后，











sudo ./src/forwardoh






项目地址：https://github.com/wanglihe/forwardoh

---------

利用dnsproxy-by-AdguardTeam解决dns污染问题



Simple DNS proxy with DoH, DoT, and DNSCrypt support.



参见：https://briteming.blogspot.com/2019/09/dnsproxy-by-adguardteamdns.html

------------------

在mac上，先安装nodejs环境。然后，


git clone https://github.com/hardillb/dns-over-https dns-over-https-by-hardillb

cd dns-over-https-by-hardillb 

npm install

nano dns-to-https-proxy.js

（修改第8行的url为https://mydomain.com/dns-query)















sudo node dns-to-https-proxy.js
项目地址：https://github.com/hardillb/dns-over-https

----------

在mac上，先安装go环境。然后，

cd $GOPATH

go get -u -v github.com/rollcat/gdoh




sudo gdoh -listen :53

不过，默认的上游dns server为https://1.1.1.1/，不一定能连上。





项目地址：https://github.com/rollcat/gdoh

--------

在mac上，先安装go环境。然后，

cd $GOPATH

go get -u -v github.com/gurparit/fastdns




sudo fastdns

会显示：

DNS1: 1.1.1.1

DNS2: 1.0.0.1

Strategy: https




项目地址：github.com/gurparit/fastdns

-------




在mac上，先安装python3环境。然后，

sudo pip3 install named1



sudo python3 -m named1

会显示：

...

[Serve53] listening on ('0.0.0.0', 53)

[Serve53] listening on ('::', 53)

[cloudflare] 1.0.0.1 connected, cert cloudflare-dns.com

[google] 8.8.4.4 connected, cert dns.google

[cloudflare] 1.1.1.1 connected, cert cloudflare-dns.com

[google] 8.8.8.8 connected, cert dns.google




项目地址：https://github.com/Tronic/named1


















-------------------------------------------------------------









https://github.com/pengelana/blocklist/wiki/DNS-over-HTTPS-(DoH)





-----------------------------------------------------



DNS over HTTPS




DNS over HTTPS (DoH) is a protocol for performing remote Domain Name System (DNS) resolution via the HTTPS protocol. A goal of the method is to increase user privacy and security by preventing eavesdropping and manipulation of DNS data by man-in-the-middle attacks[1] by using the HTTPS protocol to encrypt the data between the DoH client and the DoH-based DNS resolver. Encryption by itself does not protect privacy, encryption is simply a method to obfuscate the data. As of March 2018, Google and the Mozilla Foundation started testing versions of DNS over HTTPS.[2][3]

In addition to improving security, another goal of DNS over HTTPS is to improve performance: testing of ISP DNS resolvers has shown that many often have slow response times, a problem that is exacerbated by the need to potentially have to resolve many hostnames when loading a single web page.[1]







Contents


1Technical detail
2Deployment scenarios
3Public DNS servers using DoH
4Client support
5Operating system support
6Criticism
7See also
8References
9External links



Technical detail[edit]

DoH is a proposed standard, published as RFC 8484 (October 2018) by the IETF. It uses HTTP/2 and HTTPS, and supports the wire format DNS response data, as returned in existing UDP responses, in an HTTPS payload with the MIME type application/dns-message.[1][4] If HTTP/2 is used, the server may also use HTTP/2 server push to send values that it anticipates the client may find useful in advance.[5]

DoH is a work in progress. Even though the IETF has published RFC 8484 as a proposed standard and companies are experimenting with it,[6][7] the IETF has yet to determine how it should best be implemented. The IETF is evaluating a number of approaches for how to best deploy DoH and is looking to stand up a working group, Applications Doing DNS (ADD), to do this work and develop a consensus. In addition, other industry working groups such as the Encrypted DNS Deployment Initiative, have been formed to "define and adopt DNS encryption technologies in a manner that ensures the continued high performance, resiliency, stability and security of the Internet’s critical namespace and name resolution services, as well as ensuring the continued unimpaired functionality of security protections, parental controls, and other services that depend upon the DNS".[8]

Many issues with how to properly deploy DoH are still being resolved by the internet community including but not limited to:

Parental controls and content filters
Split DNS in Enterprises
CDN Localization
Interoperability with 5G networks


Deployment scenarios[edit]

DoH is used for recursive DNS resolution by DNS resolvers. Resolvers (DoH clients) must have access to a DoH server hosting a query endpoint.[5]

DoH lacks native support in operating systems. Thus, a user wishing to use it must install additional software. Three usage scenarios are common:

Using a DoH implementation within an application: Some browsers have a built-in DoH implementation and can thus perform queries by bypassing the operating system's DNS functionality. A drawback is that an application may not inform the user if it skips DoH querying, either by misconfiguration or lack of support for DoH.
Installing a DoH proxy on the name server in the local network: In this scenario client systems continue to use traditional (port 53 or 853) DNS to query the name server in the local network, which will then gather the necessary replies via DoH by reaching DoH-servers in the Internet. This method is transparent to the end user.
Installing a DoH proxy on a local system: In this scenario, operating systems are configured to query a locally running DoH proxy. In contrast to the previously mentioned method, the proxy needs to be installed on each system wishing to use DoH, which might require a lot of effort in larger environments.
Installing a DoH resolving plugin for the operating system


In all of these scenarios, the DoH client does not directly query any authoritative name servers. Instead, the client relies on the DoH server using traditional (port 53 or 853) queries to finally reach authoritative servers. Thus DoH does not qualify as an end-to-end encrypted protocol, only hop-to-hop encrypted and only if DNS over TLS is used consistently.

Public DNS servers using DoH[edit]

DNS over HTTPS server implementations are already available free of charge by some public DNS providers[9]. See public recursive name server for an overview.

Client support[edit]

AdGuard for Android,[10] AdGuard for iOS[11] and AdGuard Home[12]
Cloudflare 1.1.1.1 client app for Android and iOS.[13]
Cloudflare resolver for Linux, MacOS and Windows.[14]
cURL since 7.62.0.[15]
DNSCrypt-proxy — Local DNS → DNS over HTTPS proxy.[16]
DNSP — Versatile DNSProxy. DoH server (C) and client (PHP) implementation.[17]
doh-php-client — PHP Implementation.[18]
Firefox since Version 62 and later[19] — Browser support.[20]
go-doh-proxy — Go DoH Proxy Server.[21]
Intra — Android app by Jigsaw.[22]
nss-tls — a DoH-based resolver plugin for glibc.[23]
Technitium DNS Client — C# .NET cross-platform implementation.[24]
NextDNS client apps.[25]
Nebulo - DNS over HTTPS/TLS - for Android.[26]


Operating system support[edit]

In November 2019, Microsoft announced plans to implement support for encrypted DNS protocols in Microsoft Windows, beginning with DoH.[27]

Criticism[edit]

It has been argued that DoH provides a false sense of security, as it only encrypts information that could still be obtained via non-encrypted portions of HTTPS requests, such as IP addresses and Server Name Indication.[28][29] In addition, DoH implementations in web browsers currently rely on third-party DNS providers, which is contrary to the decentralized nature of DNS and may have privacy implications.[29] OpenBSD has disabled DoH by default in their builds of Firefox due to use of Cloudflare services for this feature.[30] Chrome will use DoH only if the user's chosen DNS provider is known to support it, although it did face accusations by U.S. ISPs that it was using the implementation to force users onto its Google Public DNS service.[31][29][32]

DoH can impede analysis and monitoring of DNS traffic for cybersecurity purposes; the 2019 DDoS worm Godula used DoH to mask connections to its command-and-control server [33][29] It is argued that DoH could bypass content-control software and enterprise DNS policies.[29]

The Internet Watch Foundation and the Internet Service Providers Association (ISPA)—a trade association representing UK ISPs—criticized Mozilla, developers of the widely-used Firefox Web browser, and Google—for supporting DoH, as they believe that it will undermine web blocking programs in the country, including ISP default filtering of adult content, and mandatory court-ordered filtering of copyright violations. The ISPA nominated Mozilla for its "Internet Villain" award for 2019 (alongside the EU Directive on Copyright in the Digital Single Market, and Donald Trump), "for their proposed approach to introduce DNS-over-HTTPS in such a way as to bypass UK filtering obligations and parental controls, undermining internet safety standards in the UK." Mozilla responded to the allegations by the ISPA, arguing that it would not prevent filtering, and that they were "surprised and disappointed that an industry association for ISPs decided to misrepresent an improvement to decades-old internet infrastructure".[34][35] In response to the criticism, the ISPA apologized and withdrew the nomination.[36][37] Mozilla subsequently stated that DoH will not be used by default in the UK market until further discussion with relevant stakeholders, but stated that it "would offer real security benefits to UK citizens".[38]

See also[edit]

EDNS Client Subnet
DNS over TLS
DNSCurve
DNSCrypt


References[edit]


^ Jump up to:a b c Chirgwin, Richard (14 Dec 2017). "IETF protects privacy and helps net neutrality with DNS over HTTPS". The Register. Retrieved 2018-03-21.
^ "DNS-over-HTTPS | Public DNS | Google Developers". Google Developers. Retrieved 2018-03-21.
^ Cimpanu, Catalin (2018-03-20). "Mozilla Is Testing "DNS over HTTPS" Support in Firefox". BleepingComputer. Retrieved 2018-03-21.
^ Hoffman, P; McManus, P. "RFC 8484 - DNS Queries over HTTPS". datatracker.ietf.org. Retrieved 2018-05-20.
^ Jump up to:a b Hoffman, P; McManus, P. "draft-ietf-doh-dns-over-https-08 - DNS Queries over HTTPS". datatracker.ietf.org. Retrieved 2018-05-20.
^ "Experimenting with same-provider DNS-over-HTTPS upgrade". Chromium Blog. Retrieved 2019-09-13.
^ Deckelmann, Selena. "What's next in making Encrypted DNS-over-HTTPS the Default". Future Releases. Retrieved 2019-09-13.
^ "About". Encrypted DNS Deployment Initiative. Retrieved 2019-09-13.
^ "DNS over HTTPS Implementations". 2018-04-27. Retrieved 2018-04-27.
^ Brinkmann, Martin (2019-03-21). "AdGuard 3.0 for Android: Redesign, Stealth Mode, Custom Filter Lists". Ghacks Technology News. Retrieved 2019-08-02.
^ Orr, Andrew (2019-07-13). "AdGuard 3 Brings DNS Privacy, 250,000 Filter Rules, Premium Features". The Mac Observer, Inc. Retrieved 2019-08-02.
^ Davenport, Corbin (2018-12-29). "AdGuard officially releases its own DNS service, and it works with Android Pie". Android Police. Illogical Robot LLC. Retrieved 2019-08-01.
^ Cimpanu, Catalin. "Cloudflare launches Android and iOS apps for its 1.1.1.1 service". ZDNet. Retrieved 2018-12-13.
^ "DNS over HTTPS". Argo Tunnel. Cloudflare. Retrieved 20 July 2019.
^ "DoH in curl".
^ "DNSCrypt-proxy v2.0". 2019-08-05.
^ "DNSP". 2019-07-22.
^ "DNS over HTTPS PHP Client". 2019-08-03.
^ "Trusted Recursive Resolver". Mozilla. 15 September 2019. Archived from the original (html) on 12 September 2019. Retrieved 15 September 2019. All preferences for the DNS-over-HTTPS functionality in Firefox are located under the `network.trr` prefix (TRR == Trusted Recursive Resolver). The support for these were added in Firefox 62.
^ "Improving DNS Privacy in Firefox".
^ "Go DoH Proxy Server".
^ "Intra on Play Store".
^ "GitHub - dimkr/NSS-TLS: A DNS over HTTPS resolver for glibc". 2019-08-02.
^ "DNS over HTTPS C# Client". 2019-07-18.
^ "nextdns". www.nextdns.io. Retrieved 2019-07-13.
^ "Nebulo - DNS over HTTPS/TLS - Apps on Google Play".
^ Gallagher, Sean (2019-11-19). "Microsoft says yes to future encrypted DNS requests in Windows". Ars Technica. Retrieved 2019-11-20.
^ "A Controversial Plan to Encrypt More of the Internet". Wired. ISSN 1059-1028. Retrieved 2019-11-19.
^ Jump up to:a b c d e Cimpanu, Catalin. "DNS-over-HTTPS causes more problems than it solves, experts say". ZDNet. Retrieved 2019-11-19.
^ "Google Unveils DNS-over-HTTPS (DoH) Plan, Mozilla's Faces Criticism". BleepingComputer. Retrieved 2019-09-14.
^ Tung, Liam. "DNS over HTTPS: Google hits back at 'misinformation and confusion' over its plans". ZDNet. Retrieved 2019-11-19.
^ Lee, Timothy B. (2019-09-30). "Why big ISPs aren't happy about Google's plans for encrypted DNS". Ars Technica. Retrieved 2019-11-19.
^ Cimpanu, Catalin. "First-ever malware strain spotted abusing new DoH (DNS over HTTPS) protocol". ZDNet. Retrieved 2019-11-19.
^ Cimpanu, Catalin. "UK ISP group names Mozilla 'Internet Villain' for supporting 'DNS-over-HTTPS'". ZDNet. Retrieved 2019-07-05.
^ "Internet group brands Mozilla 'internet villain' for supporting DNS privacy feature". TechCrunch. Retrieved 2019-07-19.
^ "British ISPs fight to make the web LESS secure". IT PRO. Retrieved 2019-09-14.
^ Patrawala, Fatema (2019-07-11). "ISPA nominated Mozilla in the "Internet Villain" category for DNS over HTTPs push, withdrew nominations and category after community backlash". Packt Hub. Retrieved 2019-09-14.
^ Hern, Alex (2019-09-24). "Firefox: 'no UK plans' to make encrypted browser tool its default". The Guardian. ISSN 0261-3077. Retrieved 2019-09-29.



External links[edit]

DNS Privacy Project: dnsprivacy.org
DNS over HTTPS Implementations
A cartoon intro to DNS over HTTPS
DNS over HTTPS: Ultimate Guide
DNS over HTTPS (DoH) Considerations for Operator Networks





from https://en.wikipedia.org/wiki/DNS_over_HTTPS




----------------------------------------------------------




DNS-over-HTTPS杂谈

DoH 基于 RFC 8484，如果要支持它，DNS服务器（称为DoH Server）和DNS客户端（称为DoH Client，比如Chrome，Curl，Dig）分别要做那些调整呢？

先上一张图，看看DoH单元之间工作原理：








从图中可以看出 DoH Client 应用程序要自行配置DoH Server（用户手动操作），这和传统DNS运作模式很不一样，各个应用程序也会缓存独立的DNS缓存。


DoH Server以URL的方式提供服务，比如Google的DoH Server地址是https://dns.google/dns-query，CloudFlare的DoH Server地址是https://cloudflare-dns.com/dns-query。


对于一个DoH Server来说，他为了查询出主机名的IP地址，它也会递归查询其他传统DNS Server（当然安全性比Client查询安全的多），也就是传统DNS Server和DoH Server是并存的。


对于一个DNS Server来说，为了支持DoH，改造并不大，只是对原生DNS消息格式进行处理，然后以HTTPS消息格式进行网络传输，其实复杂度并不高。


而对于一个DoH Client来说，考虑的内容多了很多，比如还要校验证书；如果DoH Server超时了，如何处理；如何设置配置选，以便让用户配置DoH Server，一系列复杂问题让我们怀疑他的可行性。


对于我们普通用户来说，还要自行配置DoH Server，这就更麻烦了，有多少人懂DNS呢？也许未来会做成完全自动化配置。


里面还有一个非常有意思的事情，不知道大家有没有发现，DoH Server也是以域名主机方式提供服务的，那么这个主机如何解析出IP地址呢？因为此时DoH Clinet还不知道DoH Server IP是什么，简单的解决方式是用传统DNS方式解析出DoH Server的IP，或者让用户自行设置DoH Server的IP。


目前Chrome，Firefox，Curl应用程序都支持了DoH Client，这个将来有机会再说，简单以Curl命令行的方式演示：

$ curl --doh-url https://dns.google.com https://www.simplehttps.com



写到现在还有很多疑问？为什么采用HTTPS协议承载DNS消息？有什么好处和坏处？为什么不采用TLS协议承载DNS消息？ISP会支持DoH吗？浏览器如何支持？会全面替代传统DNS吗？


上面介绍了DoH机制的一些原理，本文说下我对它的一些疑问，主要观点来源于 Curl 的作者 Daniel Stenberg，他发博文的频率非常高，曾经也是 Mozilla 的员工，如果想要了解 HTTP&Web 相关方面的知识，他的博客是必须订阅的。


第一个问题就是DoH为什么要使用HTTPS协议传输，而不是使用TLS协议（或其他协议）传输？


这一方面说明了HTTP（HTTPS）协议的通用性，HTTP协议虽然感觉上性能不佳（其实这属于旧观点了），但通用性非常好，只要是互联网应用，都可以轻松使用它传输消息，而且考虑到DoH是浏览器厂商力推的，Chrome和Firefox如果要发送DoH查询请求，那是非常的方便。


如果使用TLS协议承载DoH，那么DoH Clinet的改造就比较大了，没有HTTPS协议处理那么方便，比如要自行校验证书。


并且HTTPS协议的443端口一般不会被block（屏蔽），而如果使用其他端口传递DoH，很有可能被路由器、代理服务器过滤掉。


再比如你要搭建一个DoH Server（递归DNS），简单使用HTTPS Proxy就可以了，根本无需了解DNS知识，非常的方便。


我第一次听说DoH的时候，第一个考虑的问题是性能问题，传统DNS基于UDP，只要一个RTT就能响应，而HTTPS协议可并不是这样的。


其实HTTP/2协议可以多路复用，连接可以复用，你在浏览器访问十个不同的网站，Chrome只要和DoH Server建立一次连接；甚至基于Server Push功能，DoH Server能够主动给你发送更新，所以从这个角度看，性能问题不用太担心，但实际情况可能没有那么乐观。


传统DNS服务器是使用IP地址访问的，而DoH使用主机域名访问，能够进行负载均衡，通过CDN技术，让你访问最近的DoH Service。


第二个问题，对DoH基于HTTPS协议的一些质疑，传统DNS协议是非常轻量的一个应用层协议，而DoH感觉是对DNS协议的一个改造，并且还要使用HTTPS协议传输消息，总感觉怪怪的。


DoH更像一个集中式的服务，而DNS本身是阶层式的服务，DoH Service对外是一个递归服务器，内部还是采用迭代式的传统DNS查询方式，如果全面推广DoH，难道迭代式的查询就没了？比如你查询一个DNS解析，首先向Root DNS查询，它如何响应？告诉你下一个DNS的主机名（用于你迭代解析），由于这一块我还没深入了解，目前是我提出的一个疑问。


采用DoH，需要用户（或应用程序）去单独配置DoH Service（不是全局配置），还要考虑soft fail问题，使用起来非常麻烦。


采用DoH，由于是HTTPS协议，也很容易被跟踪，比如Cookie，带来新的一系列安全性问题，同时DoH Service能够了解到更多用户的行为，会不会爆发出新的罪恶之源？


采用DoH，是基于Geo获取用户的地址，如果获取不准，会导致DNS解析出的结果不一样，比如你在北京，权威服务器解析出的主机地址可能是A，如果Geo定位错误，权威服务器根据你的IP地址可能会解析到另外一个主机IP。


传统DNS排查非常容易，而如果采用DoH，出现问题如何排查？到底是DNS服务器的问题，还是HTTPS传输的问题？HTTPS消息是加密的，怎么知道具体问题是什么？


第三个问题，DoH会替代传统DNS吗？


我觉得不会，而且很有可能这个项目会失败，至少不会有大量的推广应用，本来很简单的一个DNS查询，因为有HTTPS协议的存在会衍生出新的问题。


对于用户来说，DoH配置那么复杂，有多少人会操作呢？任何一项技术，如果让用户难以使用，那么很难推广。


另外DoH还是要和传统DNS配合使用，比如第一次需要解析DoH Service的主机名，所以还难全面替换，从设计上来看，为了安全，把本来很简单的解决方案搞复杂了。


最重要的是DoH打破了原有DNS的工作机制，现在的PC，手机上的程序都基于系统的lib查询DNS，而如果改为DoH，就要自行处理DNS查询，且不说复杂度，这个过渡时间没十年根本不可能，所以没有动力去改造。


大家想想HTTPS的推广目前做的不错，原因在于Chrome等浏览器的推广，Web网站不改造，我就告诉用户你的网站不安全，逼得你要去改，同时Web改造工作量也不大（仅仅是http到https的替换）。可DoH，Chrome等浏览器没有大杀器逼着用户去配置使用DoH，所以目前的服务对象只能是我们这样的技术人员。


再考虑ISP愿意去改造吗？Windows这样的操作系统会愿意改造吗（让你全局配置DoH Service），且不说主观意愿，复杂度也高了很多，尤其对于ISP，可能还会破坏他们的既得利益。


再比如Root DNS，权威DNS会改造吗？你如何说服他们？如果他们也改造了，那传统DNS消息格式可能就不存在了。


所以目前DoH只能是浏览器厂商的一个尝试性项目，解决访问网站的安全性问题（且还存在很多问题），很难全面替换，即使要部分替换也要花上数十年，但技术是不断提高的，未来可能会有新的、更好的解决方案，让我们拭目以待。


前两篇文章讲解了DoH的原理和优缺点，本文说下如何让浏览器启用DoH，从firefox 60版本后就可以体验DoH特性了，也是目前唯一支持DoH的浏览器，不过需要手动启用。


首先在地址栏中输入 about:config，然后搜索 network.trr，会列出一系列的DoH参数，见下图：






重要的参数就三个，network.trr.mode 有好几个选项：



0，这是默认值，相当于5，表示不启用DoH。


1，启用DoH，但它同时也会使用传统DNS查询，返回响应快的结果。


2，启用DoH，如果不可用的时候，会启用传统DNS查询，相当于一个备份。


3，只启用DoH，这是最安全的方式，如果DoH不可用，那么你就无法访问网站了。




network.trr.uri 参数也很重要，表示选择DoH Server，比较著名的就是Google（https://dns.google/dns-query）和 Cloudflare（https://cloudflare-dns.com/dns-query）的。

不过悲催的是，这二个DoH Server的443端口目前是无法访问的。 


换言之在特定区域，DoH功能我们是享用不了的，从这个角度看，DoH想推广是困难重重。


network.trr.bootstrapAddress 这个参数也很重要，在firefox启动的时候，dns.google 和 cloudflare-dns.com 这两个 DoH Server 也需要进行 DNS 查询，如果实在要查询，就只能使用传统DNS查询了，为了避免潜在的不安全性，可以手动输入 DoH Server 的 IP 地址，Cloudflare 的是 1.1.1.1，Google 的是 8.8.8.8。


配置后，如何知道你访问网站使用DoH呢？在地址栏上输入 about:networking#dns，



如果 TRR 的值是 True，表示启用DoH了。

----------------------------------



技术上其实已经有了解决方案，那就是 RFC 7871 (Client Subnet in DNS Queries, aka edns-client-subnet, ECS)，RFC 文档见此，还可参考 Google 的帮助。 ECS 允许 DNS 解析的请求放附带一个网络地址，要求 DNS 服务器做出针对这个地址优化的解析响应。 但是，ECS 目前的实施还是非常不接地气的。国内大厂多有成熟的智能解析方案，国外大厂更由于隐私等诸多问题对此动力不足。即便是目前对 ECS 支持的最好的 Google Public DNS，发过去的请求包也只有一半可以得到正确的 ECS 响应。 因此 Google 提供了一种迂回的解决方案：DNS-over-HTTPS（文档）。不使用不能稳定得到 ECS 响应的 DNS 协议，通过 HTTPS 协议可以稳定获取 ECS 响应。 我们可以从这个方案中得到一个新思路，将 DNS 请求转化为 HTTPS 请求，再将收到的响应转化为 DNS 响应返回（事实上会小幅度增加解析耗时）。

------------------

https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-over-https/

------------------










'DNS over HTTPS' server的客户端程序cloudflared




概述

由于中国大陆内存在 DNS 缓存投毒，通过常规方式使用 DNS 会导致某些域名不能被正常解析。DNSSEC 曾经是被寄予厚望来解决 DNS 缓存投毒的方案， 然而由于大部分域名都未设置 DNSSEC，不能直接在 DNS 客户端使用强制 DNSSEC 校验并对校验失败的结果丢弃，因此 DNSSEC 在对抗 DNS 污染时并没有起到预想中的效果。反而，在执行 DNSSEC 查询时，即使是未被屏蔽的域名也可能遭受污染。

既然使用标准 DNS 协议会被污染，那最简单的方案就是在公网内使用非常规的 DNS 查询方法，并且把 DNS 查询内容加密，自然也就规避了 ISP 的 DNS 劫持和防火墙的 DNS 缓存投毒。

目前主流的方法主要是 DNS over HTTPS（DoH）和 DNS over TLS（DoT），本文档介绍第一种方案。

支持 DNS over HTTPS 的 DNS 程序非常多，然而大部分主要用于在核心路由器上甚至公网上提供 DNS 服务，如果你只是简单地在局域网环境使用，则使用 Cloudflare 提供的 Cloudflared 程序就可以轻松完成部署。


Windows

系统环境

在此文章撰写时...


Windows 10 Pro for Workstations / 1804. Build 17134.1


首先需要下载 Cloudflared 二进制文件

32 位系统

64 位系统

解压缩后放到任意位置，如我们放到 I 盘的 Cloudflare 文件夹中。



在左下角的 Windows 徽标按钮上右键单击，选择「Windows PowerShell（管理员）」，并在弹出的 UAC 授权提示框（如果有）中允许 PowerShell 使用管理员权限。



定位到 I:\Cloudflare 目录。



以 DNS 代理模式运行 Cloudflared



这时我们已经成功通过 Cloudflared 隧道程序以 HTTPS 方式连接到了 Cloudflare 提供的 DNS。

由于 Cloudflared 自身以 CLI（Command Lines）方式运行时不会以 Daemon 方式运行，我们需要通过 PowerShell 的功能来让它在后台运行。

输入命令（你需要自行修改命令中的路径）：
powershell -windowstyle hidden -command "I:\Cloudflare\cloudflared.exe proxy-dns"


某些安全软件可能会拦截以后台静默运行的程序，请允许 Cloudflared.exe 和 PowerShell 这么做




可以看到 PowerShell 窗口一闪而过，我们通过 nslookup 测试一下。



测试可以了解到，Cloudflared 仍然在正常运行，并提供着 DNS 代理服务。现在，只需要修改网络适配器中的 DNS 服务器地址为 127.0.0.1 就可以使用了。

将这个 PowerShell 设置为开机运行，就可以实现开机启动 Cloudflared 并运行 DNS 代理服务。

Windows 也可以将 Cloudflared 设置为系统服务来开机运行 Cloudflared，请参考官方文档


macOS

系统环境

在此文章撰写时...


macOS 10.13.5 Beta / Build 17F45c


macOS 系统可以通过包管理器或二进制安装 Cloudflared。

要安装 Homebrew（包管理器），你可以参考 Homebrew 的官方网站或直接在终端中输入：
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

已经安装 Homebrew 后，在终端中输入：
brew install cloudflare/cloudflare/cloudflared

也可以直接使用二进制文件安装：
curl https://bin.equinox.io/c/VdrWdbjqyF/cloudflared-stable-darwin-amd64.tgz | tar xzC /usr/local/bin


安装后直接在终端输入 sudo cloudflared proxy-dns 即可运行 Cloudflared 的 DNS 代理功能。

Cloudflared 以 DNS 代理模式运行时需要监听 53 端口，因此必须提权到 Root 用户才能运行。



要在后台运行 Cloudflared，官方方法是将 Cloudflared 设置为服务。

要设置 Cloudflared 为服务，你必须拥有一个 Cloudflare 账户并在至少一个域中购买了 Argo 增值服务。



因此，详细的设置方法请参考官方文档

macOS 也可以自行编写脚本来开机运行 Cloudflared，但是由于 macOS 是类 UNIX 系统且权限控制较为严格，此文档没有足够篇幅和必要介绍此种方法。


Linux

系统环境

在此文章撰写时...


Rad Hat Enterprise Linux 7.4
Ubuntu 18.04 LTS


Linux 发行版可以通过包管理器安装或二进制安装。

二进制文件 x86-64 | 二进制文件 ARMv6

.deb 包 x86-64 | .deb 包 ARMv6

.rpm 包 x86-64 | .rpm 包 ARMv6


二进制文件可以直接安装到 /usr/bin 等目录，安装后，输入 sudo cloudflared proxy-dns 就可以使用，可以部署到路由器上供网关下的设备使用。

Cloudflared 以 DNS 代理模式运行时需要监听 53 端口，因此必须提权到 Root 用户才能运行。如果已经是 Root 用户，直接运行即可。

可以在 screen 中运行 Cloudflared 以变相达成后台运行，或者自行编写 SystemInitV / Systemd 脚本来开机运行。

from  https://rixcloudkb.io/kb/dns-over-https/
-----------------------------------------------








相关帖子:

类似项目：gdns-go，https://briteming.blogspot.com/2019/08/dns-proxygdns-go.html 

http://briteming.blogspot.com/2018/10/4dnssecdnscryptdns-over-tlsdns-over.html


https://briteming.blogspot.com/2019/07/tutorial-to-setup-dns-over-tls-dot.html
--------
Minimal and efficient DNS-over-HTTPS (DoH) client

https-dns

https-dns is a minimal and efficient DNS-over-HTTPS (DoH) client. DNS-over-HTTPS (RFC 8484) is a protocol for performing DNS resolution through the HTTPS protocol that prevents manipulation of DNS response. https-dns forwards DNS queries from the client to upstream DoH servers, caches the response, and sends the response back to the client.

Installation

cargo install https-dns

Usage

# udp://localhost:53 -> https://1.1.1.1 (default)
sudo https-dns

# udp://localhost:53 -> https://cloudflare-dns.com
sudo https-dns --upstream-address cloudflare-dns.com

# udp://localhost:10053 -> https://dns.google
sudo https-dns --local-port 10053 --upstream-address dns.google

CLI Reference

$ https-dns --help

https-dns 0.2.0
Minimal and efficient DNS-over-HTTPS (DoH) client

USAGE:
    https-dns [OPTIONS]

OPTIONS:
    -h, --help                                   Print help information
        --local-address <LOCAL_ADDRESS>          [default: 127.0.0.1]
        --local-port <LOCAL_PORT>                [default: 53]
        --upstream-address <UPSTREAM_ADDRESS>    [default: 1.1.1.1]
        --upstream-port <UPSTREAM_PORT>          [default: 443]
    -V, --version 

from  https://github.com/xiaoyang-sde/https-dns 

---

公共DoH

国内服务商

1、阿里公共 DNS

DoT 地址：dns.alidns.com 或 223.5.5.5

DoH 地址：
https://dns.alidns.com/dns-query

2、DnsPod 腾讯 公共 DNS

DoT 地址：dns.pub 或者 119.29.29.29

DoH 地址：

https://dns.pub/dns-query

3、360DNS

DoT 地址：dot.360.cn

DoH 地址：https://doh.360.cn/dns-query

4、中国下一代互联网公共 DNS.

DoT 地址：dns.cfiec.net

DoH 地址：
https://dns.cfiec.net/dns-query

4、红鱼 dns

DoT 地址：rubyfish.cn
DoH 地址：https://rubyfish.cn/dns-query

国外服务商

1、Cloudflare 公共 DNS

知名云服务商 Cloudflare 提供的解析服务器。

DoT 地址：cloudflare-dns.com 或 1.1.1.1

DoH 地址：

https://1.1.1.1/dns-query

2、Google 公共 DNS

DoT 地址：dns.google 或 8.8.8.8

DoH 地址：
https://dns.google/dns-query

3、DNS.SB

DoT 地址：dns.sb 或 185.222.222.222

DoH 地址：

https://doh.dns.sb/dns-query

4、AdGuard DNS

DoT 地址：dns.adguard.com

DoH 地址：
https://dns.adguard.com/dns-query

5、Quad9 IBM 公共 DNS

DoT 地址：dns.quad9.net 或 9.9.9.9

DoH 地址：
https://dns.quad9.net/dns-query

浏览器中使用 DNS-over-HTTPS 的方法

Chrome

1. 在设置里选择【隐私设置和安全性】下点击【安全】
2. 在高级部分中，启用【使用安全 DNS】
3. 选择【自定义】，输入 https://doh.pub/dns-query

Firefox

1. 在选项里找到【网络设置】部分，然后单击【设置】
2. 选中【启用基于 HTTPS 的 DNS】
3. 选择【自定义】，输入 https://doh.pub/dns-query 单击确定

Edge

1. 在设置里找到【隐私、搜索和服务】部分
2. 在【安全性】下，启用 "使用安全的 DNS 指定如何查找网站的网络地址"
3. 选择【请选择服务提供商】，输入 https://doh.pub/dns-query