AI-poweredtranslation
This article has been translated by LLM model and revised by the author.

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:

  1. set DoH in browser (1. Non-browser applications are out, 2. No option to set a fallback DNS)
  2. 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.

Specific Software

GitHub - DNSCrypt/dnscrypt-proxy: dnscrypt-proxy 2 - A flexible DNS proxy, with support for encrypted DNS protocols.

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

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; DNSCrypt will automatically query them in order until it succeeds.

Windows Network Configuration

Control Panel \ Network and Internet \ Network Connections -> -> IPv4 DNS: 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.
  • 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>.

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.

© api2o.com:: a website of blog, tools, APIs. 一个包含: 博客、在线工具、API 的网站. All rights reserved.