Win10 Global DoH Solution: Best Practice
This article introduces the most perfect solution for using global DoH (DNS Over HTTPS) on Windows 10: setting up a local DNSCrypt service, including configuration and verification.
Introduction
Currently, there are several solutions for using DoH (DNS Over HTTPS) for Windows users:
- set DoH in browser (1. Non-browser applications are out, 2. No option to set a fallback DNS)
- Upgrade to Windows 11 😒
If you have some networking knowledge, you can come up with a simple approach: DNS over (Local DoH Application), to achieve native global DoH experience as in Windows 11.
The topology is:
All Your Applications ----(local DNS port 53)----> DNSCrypt ----(https)-----> DoH Service Provider (Google, Cloudflare...)
Although all applications using the traditional DNS port 53, the queries out are actually DoH queries, actually implement global DoH (communication in localhost is considered secure).
In addition to running the service on a single machine's port 53, it can also be hosted on an internal network server, enabling DNS over (Intranet DoH Service) for intranet machines.
Introduction to DNSCrypt
In short, DNSCrypt is a standard for DoH, with implementations available on different platforms. Its role is to launch an application/service that receives traditional DNS queries (through the local port 53) and transmit DoH queries out.
- DNSCrypt version 2 - Official Project Home Page
- DNSCrypt - Download clients and servers for DoH and DNSCrypt
Specific Software
Follow the official documentation for installation, and it is best to install it as a Service.
Configuration
For a beginner's guide and specific configuration functions, please refer to the official documentation, so I won't elaborate further here.
Set the log level to debug during testing, and turn off logging after the tests are completed.
Custom Section of dnscrypt-proxy.toml
## Servers from the "public-resolvers" source (see down below) can
## be viewed here: https://dnscrypt.info/public-servers
server_names = [ 'tuna-doh-ipv6','dnspod','easymosdns-doh','google']
👆👆:
- Selected these from public resolvers to prevent temporary access issues with any one service;
DNSCryptwill automatically query them in order until it succeeds.
Windows Network Configuration
Control Panel \ Network and Internet \ Network Connections -> 127.0.0.1
Testing and Verification
nslookup
Using Default DNS Queries
nslookup www.google.com
If the configuration is correct, it should return:
Server: UnKnown
Address: 127.0.0.1
Non-authoritative answer:
Name: www.google.com
Address: 142.250.196.196
If the server returned is not 127.0.0.1, it's problem in your adaptor config preventing DNS query from reaching local port 53. Temporarily specify 127.0.0.1 for testing:
nslookup www.google.com 127.0.0.1
PowerShell Check for Local Port 53
Get-NetTCPConnection | Where-Object {$_.State -eq 'Listen'}
Logging Method
Enable logging in the configuration, then restart the application/service and check the logs for any access queries:
[query_log]
file = 'query.log'
format = 'tsv'
ignored_qtypes = ['DNSKEY', 'NS']
Packet Capture Method
- Receive: Local communication on port 53:
- Use Wireshark to capture on the localhost adapter to see if there are packets on
udp.port==53.
- Use Wireshark to capture on the localhost adapter to see if there are packets on
- Transmit: Outbound DoH:
- Use Wireshark to capture on the external network adapter to check for encrypted packets for DNS addresses
ip.addr==<server_names service IP> || ip.addr==<server_names service IP>.
- Use Wireshark to capture on the external network adapter to check for encrypted packets for DNS addresses
Other Issues
Multiple Adapters Configured with IPv4 DNS Leading to DNS Not Routing Through Localhost Port 53
Tests show that if multiple adapters are configured with IPv4 DNS, all traffic will route through one of those DNS servers (unknown priority). Remove the extra configurations and keep only one.
VM inside Host Cannot Access Host Machine's Port 53
Requests made through NAT to :53 do not go through. Check the firewall rules to see if they restrict private networks while the connected adapter is set to public network. The corresponding rules in firewall settings also have advanced -> edge traversal set to block by default; change this to allow apps instead.