2016年10月4日，美国商务部、美国专利商标局以及经济和统计管理局联合发布研究报告《知识产权与美国经济2016（Intellectual Property and the US Economy：2016 Update）》，指出知识产权密集型产业至少为美国提供了4500万个就业机会，产业贡献超过6万亿美元，占美国GDP总量的38.2%。该报告识别了81个广泛采用专利、著作权以及商标权保护的知识产权密集型产业，包括软件出版业、录音产业、音频和视频设备制造业、有线电视和其他订阅节目、表演艺术公司以及广播电视。这些产业直接或间接产生的就业机会约占美国所有产业的30%。
Clone and run for a quick way to see Electron in action.
This is a minimal Electron application based on the Quick Start Guide within the Electron documentation.
Use this app along with the Electron API Demos app for API code examples to help you get started.
A basic Electron application needs just these files:
package.json - Points to the app's main file and lists its details and dependencies.
main.js - Starts the app and creates a browser window to render HTML. This is the app's main process.
index.html - A web page to render. This is the app's renderer process.
You can learn more about each of these components within the Quick Start Guide.
To Use
To clone and run this repository you'll need Git and Node.js (which comes with npm) installed on your computer. From your command line:
# Clone this repository
git clone https://github.com/electron/electron-quick-start
# Go into the repositorycd electron-quick-start
# Install dependencies
npm install
# Run the app
npm start
Note: If you're using Linux Bash for Windows, see this guide or use node from the command prompt.
The Electron framework lets you write cross-platform desktop applications using JavaScript, HTML and CSS. It is based on Node.js and Chromium and is used by the Atom editor and many other apps.
Follow @ElectronJS on Twitter for important announcements.
This project adheres to the Contributor Covenant code of conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to coc@electronjs.org.
Installation
To install prebuilt Electron binaries, use npm. The preferred method is to install Electron as a development dependency in your app:
npm install electron --save-dev [--save-exact]
The --save-exact flag is recommended for Electron prior to version 2, as it does not follow semantic versioning. As of version 2.0.0, Electron follows semver, so you don't need --save-exact flag. For info on how to manage Electron versions in your apps, see Electron versioning.
For more installation options and troubleshooting tips, see installation.
Quick start & Electron Fiddle
Use Electron Fiddle to build, run, and package small Electron experiments, to see code examples for all of Electron's APIs, and to try out different versions of Electron. It's designed to make the start of your journey with Electron easier.
(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:
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.
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.
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.
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.
Install
If you compile it yourself, you won’t need to do this, the make install will have already taken care of it.
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.
# HTTP listen port
listen = [
"127.0.0.1:8053",
"[::1]:8053",
]
# 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 = [
"127.0.0.1:53",
]
# Upstream timeout
timeout = 60
# Number of tries if upstream DNS fails
tries = 10
# Only use TCP for DNS query
tcp_only = false
# Enable logging
verbose = false
This will tell DoH-server to use our dnscrypt-proxy to do its DNS requests.
Once done, restart the service.
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.
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.
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:
ssl_stapling on;
ssl_stapling_verify on;
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.
sudo add-apt-repository ppa:certbot/certbot
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:
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.
Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
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.
# This file contains important security parameters. If you modify this file
# manually, Certbot will be unable to automatically provide future security
# updates. Instead, Certbot will print and log an error message with a path to
# the up-to-date file that you will need to refer to when manually updating
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.
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.
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.
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.
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-TLSis 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.
$ 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
针对后两点，技术上其实已经有了解决方案，那就是 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。
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.
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"
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.
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.
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:
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!
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.
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 -----------------------------------------------
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失败，遂放弃此项目）
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.
# 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 supportedstderr: /var/log/dohproxy.err # default: stderr, log-to-file on Windows is not supportedlevel: info # default: debug, choices: debug, info, warn(warning), error, dpanic, panic, fatallisten:
- type: udpaddress: 127.0.0.1:53
- type: tcpaddress: 127.0.0.1:53upstreams:
google-public:
type: dnsaddress: 8.8.8.8:53my-corp-dns:
type: dnsaddress: 192.168.53.1:53doh-get-with-proxy:
type: doh-getaddress: https://some-doh-server-i-cant.com/dns-queryproxy: socks5://127.0.0.1:1080doh-post:
type: doh-postaddress: https://cloudflare-dns.com/dns-queryrules:
- 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
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.
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]
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 typeapplication/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:
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.
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.
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 FirefoxWeb 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]
^"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.
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
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.
