1 Introduction

Previously, I wrote an article about dnscrypt-proxy deployment (see:dnscrypt-proxy (v2.1.8) Multi-scenario configuration guide: from upstream deployment to downstream integration). The architecture at that time was: using Racknerd's Chicago VPS to deploy dnscrypt-proxy as an encrypted DNS upstream server (published in DoH mode), and AdGuard Home in the home data center (because AdGuard Home supports DoH as the upstream node) as a DNS downstream node to serve intranet devices, thus providing a pure, uncontaminated DNS service that supports encrypted transmission for the home network.

However, this solution also has a limitation in practical use:Unable to implement split resolution of domestic and foreign DNS queriesOf course, this is not because dnscrypt-proxy itself does not support it, but its diversion mechanism is more inclined to "forwarding based on server policy" (for example, through different server-names configuration), unlike dnsmasq or smartdns.Ability to intelligently select upstream servers based on whether the queried domain name is a domestic domain (such as geosite:cn).

Therefore, in daily use, this architecture is more suitable asPure external DNS exportHowever, it is not practical enough for scenarios that require domestic priority and intelligent diversion: many domestic websites will not respond to queries from foreign addresses at all.

At present, my DNS query diversion mainly relies on the DNS hijacking and rule diversion functions provided by Merlin Clash on the AC86U router. Although this method is simple to deploy and has intuitive effects, it also has a natural hidden danger:Over-reliance on the stability of a single nodeWhether it is Merlin Clash itself or the configured scientific Internet service provider, once any of them fails (such as scientific node failure, rule loading abnormality, or network fluctuations during some special periods), the entire DNS diversion chain will be broken. The most direct consequence is that the intranet equipment cannot correctly resolve some domain names, or even a complete resolution failure occurs.

I have encountered these problems more than once, so I gradually dare not point the upstream DNS of the iKuai router directly to the DNS service of AC86U. After all, once AC86U has problems, the entire network environment will be implicated.

So this time, I decidedCompletely solve this problem: Build aA local DNS service system that is stable, autonomous, independent of Merlin Clash and AdGuard Home, and has the ability to "intelligently divert domestic and foreign DNS queries"Its core objectives include:

High stability: No longer dependent on router firmware or third-party plug-ins, even if the scientific Internet service fails, the DNS diversion service is still available;
Intelligent traffic diversion capability：Using geosite, china-list and other rules, we can achieve accurate diversion of domestic and foreign domain names. Domestic domain names go to local upstream, and foreign domain names go to encrypted links.
Modular component design：The responsibilities of each part are clear, for example, dnsmasq focuses on traffic diversion and caching, sing-box or dnscrypt-proxy provides encryption and resolution services;
Friendly to main router：Let iQiyi safely send DNS requests to this system without worrying about a single point of failure causing the entire network to fail;
Transparent proxy compatibility: In the future, if it is linked with the tproxy mode of sing-box, it can also achieve deep integration of DNS and traffic forwarding.

This is a thorough reconstruction from "barely usable with plug-ins" to "clear modules, stable and reliable". The goal is to create a truly trustworthy DNS infrastructure for home data center scenarios.

2. Selection of diversion software

2.1 Overview

To achieve the diversion of domestic and foreign DNS requests, a "base point" software is needed - it must have sufficient policy flexibility to determine the ownership of the request based on factors such as domain name, IP address, and even response delay, and then combine the domestic and foreign DNS upstream servers we already have on hand to intelligently forward the query request to the appropriate target. This type of software acts as both a DNS forwarder and a "DNS routing scheduler", and is the core of building a diversion DNS system. Common base point solutions include dnsmasq and SmartDNS.

2.2 Introduction to dnsmasq: A long-established and robust DNS offload tool

In the scenario of building DNS splitting, dnsmasq is a lightweight DNS cache and forwarding tool with a long history and is widely used. Many embedded systems (such as OpenWrt) have it integrated by default. Although it is designed to be very simple, it can still perform tasks such as splitting by domain name, caching acceleration, and shielding malicious domain names with the assistance of appropriate configuration files. It is the "first choice" for many users when deploying scientific DNS splitting in the early stage.

2.2.1 Advantages

Advantage 1: Stable, lightweight, and widely used

The biggest feature of dnsmasq is its stability. It is small in size and takes up very little resources. It can run smoothly even on low-performance routers or embedded devices. It is almost standard in custom firmware such as OpenWrt, LEDE, and Padavan. It can also be found everywhere in mainstream Linux systems such as Debian/Ubuntu, and has a low configuration and maintenance threshold.

Advantage 2: The supporting ecosystem is mature and can be flexibly expanded by relying on external rule files

Although dnsmasq's own policy capabilities are relatively limited, it can be used with community-maintained rule projects (such as:https://github.com/felixonmars/dnsmasq-china-list) can achieve basic traffic diversion by domain name. This type of rule project usually provides:

accelerated-domains.china.conf: resolves domestic domain names through domestic upstream;
google.china.conf / apple.china.conf: fine-grained processing of specific manufacturer domain names;
bogus-nxdomain.conf: blocks the fake IP returned by the operator;
ipset.conf: Combined with firewall rules, to achieve egress NAT diversion.

Through these .conf files, dnsmasq can complete most of the tasks of "determining DNS upstream based on domain name ownership".

Advantage 3: Excellent compatibility, adaptable to various mainstream scenarios

dnsmasq supports DNS cache, PXE boot, DHCP service and other functions. It is suitable for deployment in intranet gateway devices. It can provide general local DNS functions and serve as an auxiliary component of scientific network strategies. In some scenarios with high system dependence and compatibility requirements, dnsmasq is a safe choice.

2.2.2 Disadvantages

Disadvantage 1: Limited policy expression capability, traffic diversion relies on the patchwork of rule files

Dnsmasq itself does not have the capabilities of "optimizing by line", "upstream speed measurement", "fallback switching", etc. Its traffic diversion completely relies on manually maintained rule files and cannot be adjusted dynamically. When you encounter problems such as changes in the CDN distribution of overseas domain names and pollution of domestic domain names, dnsmasq cannot make intelligent adjustments based on the actual network conditions.

Disadvantage 2: Lack of native DoH/DoT support, requiring external forwarders

dnsmasq does not support direct connection to DoH (DNS over HTTPS) or DoT (DNS over TLS) upstream servers. To use these protocols, additional components such as dnscrypt-proxy, smartdns, adguard home or https-dns-proxy are required as the front forwarding layer, which increases the complexity of deployment and debugging.

Disadvantage 3: Not friendly to modern DNS architecture, lengthy configuration and not flexible enough

When configuring a large number of diversion rules, dnsmasq needs to manually import multiple .conf files, and it is difficult to organize and combine the rules. At the same time, it does not support upstream grouping mechanisms such as tags and groups, and cannot implement behaviors such as "automatically selecting the fastest after returning multiple upstream results". This makes it somewhat powerless in complex network environments.

2.2.3 summary

As a classic DNS tool, dnsmasq has become a "veteran" in home network DNS diversion with its stability, lightness and wide community support. It is suitable for devices with limited resources and users who have a clear preset for the DNS architecture and are willing to manually maintain the rule files. However, when facing the needs of modern networks, its scalability and intelligence capabilities gradually expose bottlenecks. Therefore, in some more complex application scenarios, you may need to consider introducing more modern tools, such as SmartDNS, which will be introduced in the next section.

2.3 Introduction to SmartDNS: A powerful new generation of DNS splitter

Compared with dnsmasq, SmartDNS is a modern DNS diversion solution that has emerged in recent years. It has natural advantages in "intelligent selection of the fastest upstream", "delay speed measurement sorting", "multi-protocol support (including DoH, DoT)", etc. Although it was originally created for "acceleration", with the continuous promotion of the community, SmartDNS has gradually evolved into a fully functional diversion DNS hub, especially suitable for users who have high requirements for speed, strategy and flexibility.

2.3.1 Advantages

Advantage 1: Native support for DoH/DoT, strong upstream speed measurement optimization capability

SmartDNS supports access to DoH/DoT upstream through parameters such as server-tls and server-https, and can complete encrypted resolution requests without additional components. At the same time, SmartDNS will regularly test the speed of all upstreams, sort them according to response delays, and give priority to the fastest servers, effectively improving domestic and foreign access speeds.

This also makes it very suitable for environments with complex public network exports and frequent bandwidth changes, such as multiple home WANs, bypass routing, overseas transit, and other scenarios.

Advantage 2: Flexible policy grouping and screening mechanism, supporting complex diversion logic

SmartDNS supports tagging upstream servers and conditionally filtering them through rules, such as:

server-tls 1.1.1.1 -group foreign -exclude-default-group server 223.5.5.5 -group domestic server 127.0.0.1:5335 -group custom # shunt rule server-rule domain-suffix cn domestic server-rule domain full netflix.com foreign

This means that you can flexibly route different requests to different upstreams based on TLD (top-level domain), domain name keywords, client IP segments and other conditions, and groups and rules can be used in combination, fully supporting "multi-exit DNS diversion" or "directional resolution" requirements.

Advantage 3: Supports advanced features such as cache acceleration, concurrent queries, and DNS answer filtering

SmartDNS supports concurrent queries by default (initiating requests to multiple upstreams at the same time and only using the fastest response), TTL control, cache poisoning protection, filtering of invalid IP addresses (such as 0.0.0.0, operator hijacked IP), interception of specified domain names, etc., which greatly improves the security and response speed of the DNS system.

In addition, it can listen on multiple ports as DoH/DoT Server, allowing other devices to request it through an encrypted protocol, which is suitable for building a local private DNS service.

2.3.2 Disadvantages

Disadvantage 1: It takes up a little more resources and is not very friendly to memory-sensitive devices

When SmartDNS is started, it will cache the upstream configuration, speed test data and rule list. During multiple concurrent requests and latency analysis, it will take up more memory and CPU than dnsmasq, which is not friendly to small devices with very low configuration (such as 64MB routers). However, for devices with 128MB+ memory or running in LXC/PVE virtual machines, this usage is completely acceptable.

Disadvantage 2: The configuration syntax is slightly complex, and there is a certain threshold to get started

Although SmartDNS is very powerful, its configuration syntax is not intuitive enough and may be a bit cumbersome for beginners. Especially when it comes to grouping, labeling, and combining multiple rules, users need to carefully understand its parsing logic. A slight misconfiguration may cause all requests to fallback or hit the default group.

In addition, SmartDNS does not directly provide the ipset function (i.e. putting the IP after domain name resolution into the specified ipset), which means that if you need to divert traffic based on IP, you have to rely on front-end tools such as dnsmasq to generate ipset or use nftables set instead.

Disadvantage 3: Lack of mature rules and ecosystem, some diversion strategies need to be sorted out by yourself

Unlike the dnsmasq community which already has a large number of .conf files, SmartDNS's rule system is more user-defined. Although it is compatible with some basic geosite.dat/domain-list files, the official does not directly maintain a diversion rule repository like felixonmars. Therefore, deployers often need to combine GFWList, CNList, GeoIP, etc. to organize rule files by themselves, which is more suitable for users with certain hands-on skills.

2.3.3 summary

SmartDNS is a modern and powerful DNS offload tool, which has overwhelming advantages in DoH/DoT support, multi-upstream speed test optimization, and flexible policy scheduling. It is a very competitive choice for scenarios that pursue high performance and complex DNS policies. But at the same time, it also places higher requirements on device performance and configuration level, and is more suitable for running on servers with abundant resources, LXC containers or bypass routers.

Compared with dnsmasq, SmartDNS is a "future-oriented" DNS tool. The complexity and flexibility it brings are exactly what modern home networks and high-performance bypass routing architectures need.

3. “Basepoint” software deployment and configuration

3.1 dnsmasq

3.1.1 DNS request processing logic of dnsmasq (practical and concise version)

For most users, the actual process of dnsmasq can be simply understood as three steps:

Step 1: Check first hostsdocument

dnsmasq will first look for static resolution rules and read the contents of the /etc/hosts file by default.

effect: Suitable for binding certain specific domain names (such as ad blocking, LAN services):

192.168.10.100 nas.local 0.0.0.0 ads.example.com

Step 2: Look/etc/dnsmasq.d/*.conf"Whether the diversion rules are matched

This is the core diversion mechanism. The content in the file is similar to the following:

server=/baidu.com/114.114.114.114 server=/bilibili.com/114.114.114.114 server=/google.com/8.8.8.8 server=/github.com/8.8.8.8

Or use the top-level domain rule:

server=/cn/114.114.114.114

These rules tell dnsmasq:For specific domain name requests, send them to the specified upstream DNS.

For general diversion needs,/etc/dnsmasq.d/"It is enough to have 2 conf files in the directory.dnsmasq-china-listIn the project:accelerated-domains.china.confandapple.china.confYou can download them by yourself, or you can make a scheduled script to regularly download and update these two files, but it is generally not necessary, as it doesn’t make much sense to update these two files so frequently.

Step 3: Use the default upstream DNS (usually overseas) as a backup

If a domain name is neither in the hosts file nor hits any/etc/dnsmasq.d/*.conf" will be handed over to the upstream DNS server specified in the "dnsmasq.conf" configuration file using the "server=" field:

server=1.1.1.1 server=8.8.8.8

effect: Used to resolve all unspecified domain names, usually foreign DNS.

Summarize:

The order in which dnsmasq actually processes DNS requests is:

First check the hosts file (default /etc/hosts or custom addn-hosts)
Check again/etc/dnsmasq.d/*.confIs there a specified diversion rule?
Finally, the unreachable request will be resolved by the upstream resolution specified by the "server=" statement in the "dnsmasq.conf" configuration file.

Note: For dnsmasq 2.89 and later versions, it is no longer recommended to use the "resolv-file=/etc/dnsmasq.upstream.conf" method to specify the upstream DNS. Instead, it is recommended to use the more controllable server= method directly in the dnsmasq.conf configuration file to configure the global or split DNS, which is especially suitable for users who need to split domestic/foreign DNS queries.

3.1.2 Install dnsmasq

3.1.2.1 Source code installation

If it is under Debian or Ubuntu, just use the apt command to install it:

apt-get install -y dnsmasq

The current version installed by apt is 2.90, and the official latest version is 2.91, which is almost the same. It is not necessary to have the latest version:

As for other platforms, the installation methods are similar, so I won’t go into details here to avoid being lazy.

3.1.2.2 Docker installation

Installation in docker run format:

docker run --name=dnsmasq -d --restart=always \ -p 1053:53/udp \ -p 1053:53/tcp \ -v /docker/dnsmasq/dnsmasq.conf:/etc/dnsmasq.conf:ro \ -v /docker/dnsmasq/dnsmasq.d:/etc/dnsmasq.d:ro \ -e "DNS1=8.8.8.8" -e "DNS2=1.1.1.1" \ --cap-add=NET_ADMIN \ dockerr/dnsmasq

Note 1: When deploying dnsmasq using docker, when configuring "dnsmasq.conf" later, the address on the host machine cannot be filled in after "listen-address=", because docker cannot see the host machine's IP. Therefore, you can fill in 127.0.0.1, or simply comment or delete the "listen-address=" line, then the default is to listen to all addresses.

Note 2: DNS1 and DNS2 are equivalent to directly specifying the foreign upstream DNS server IP, and do not need to be specified using the "server=" method in the "dnsmasq.conf" configuration file.

3.1.3 Configuring traffic diversion rules

mkdir -p /etc/dnsmasq.d/ cd /etc/dnsmasq.d/ wget https://github.com/felixonmars/dnsmasq-china-list/blob/master/accelerated-domains.china.conf wget https://github.com/felixonmars/dnsmasq-china-list/blob/master/apple.china.conf

3.1.4 Create dnsmasq.conf configuration file

For dnsmasq, the content of the configuration file /etc/dnsmasq.conf determines the core behavior and operation mode of the entire service: it not only controls the listening address, cache size, log output, whether to enable DHCP, whether to read the /etc/hosts file and other basic settings, but also defines whether to enable diversion, whether to block IPv6, whether to read additional configuration directories (such as /etc/dnsmasq.d/) and other advanced options.

In addition, dnsmasq allows additional configuration files to be loaded through the conf-dir= or conf-file= directives, making it highly flexible and maintainable. For example, we usually split various server= diversion rules, address redirection, ad blocking rules, etc. into multiple configuration files and put them in the /etc/dnsmasq.d/ directory for easy module management.

It can be said that /etc/dnsmasq.conf is the "master console" of dnsmasq behavior, and the configurations it contains or introduces together constitute the "working brain" of dnsmasq. A set of scientific and reasonable configurations can make dnsmasq an efficient, stable, and divertible core component of home DNS services.

The following is the content of the dnsmasq.conf configuration file of dnsmasq I am using, for your reference:

# Listen on the local loopback interface and the primary network card eth0 (to ensure that DNS requests can be accessed by the container or host) interface=lo interface=eth0 # Set the listening port to 53 (DNS default port) port=53 # Enable all upstream DNS queries to be sent at the same time. The result of the one that returns first will be used to improve the response speed all-servers # Specify the upstream DNS server (supports diversion or backup) server=1.1.1.1 # Cloudflare Public DNS (overseas) server=8.8.8.8 # Google Public DNS (overseas) # Set the DNS cache capacity in entries (can be increased according to memory) cache-size=1000 # Do not read /etc/hosts (usually to prevent accidental pollution or use a unified hosts file) no-hosts # Specify an additional hosts file path for local resolution customization addn-hosts=/etc/dnsmasq.hosts # Ignore the system default /etc/resolv.conf (to avoid interfering with upstream configuration) no-resolv # Load all .conf files in the /etc/dnsmasq.d/ directory (commonly used for domain name diversion configuration) conf-dir=/etc/dnsmasq.d # Maximum number of concurrent forwarding queries (to prevent packet loss or delay during high concurrency) dns-forward-max=150 # Enable Windows-compatible behavior to filter invalid IPv6 requests (such as WPAD related) filterwin2k # (Optional) Disable IPv6 resolution #no-ipv6 # Enable query log (for debugging or analysis, it is recommended to use logrotate for long-term online operation) log-queries log-facility=/var/log/dnsmasq.log # Do not enable DHCP function (dnsmasq supports DHCP by default, turn it off here to avoid conflicts) no-dhcp-interface=eth0

Create the dnsmasq.conf configuration file:

vim /etc/dnsmasq.conf

Paste the above configuration example and save it, then restart the dnsmasq service:

systemctl restart dnsmasq.service

If you do not want to use the default configuration file path and name, you need to customize it yourself with the "--conf-file" parameter. For example, if you want to use "/opt/my.conf" as the dnsmasq configuration file, you need to first copy "/lib/systemd/system/dnsmasq.service" (the default path of the dnsmasq.service file when installing dnsmasq in apt mode) to the "/etc/systemd/system" path and edit it:

cp /lib/systemd/system/dnsmasq.service /etc/systemd/system/dnsmasq.service vim /etc/systemd/system/dnsmasq.service

Change the "ExecStart" field to:

ExecStart=/usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid -u dnsmasq --conf-file=/opt/my.conf

Then restart the service:

systemctl daemon-reexec systemctl daemon-reload systemctl restart dnsmasq.service

In fact, you can also use the officially recommended "systemctl edit" method to directly overwrite the ExecStart field in "/lib/systemd/system/dnsmasq.service", which will generate an override file "override.conf" in the "/etc/systemd/system/dnsmasq.service.d/" directory, which only contains the override of the ExecStart field. But I don't like this method, it feels piecemeal, so I just cp to "/etc/systemd/system/dnsmasq.service" and modify it directly, which is equivalent to the command "systemctl edit –full dnsmasq.service".

3.2 smartdns

3.2.1 Install smartdns

3.2.1.1 Source code installation

Because the version of smartdns provided in apt is too old, only 40:

The latest release version on the official github page is 46.1, which is too different:

So don't use apt for installation, but directly download the latest version from github.

1. Download the installation package for the corresponding environment

Because I use Debian 12, I download:

cd ~ wget https://github.com/pymumu/smartdns/releases/download/Release46.1/smartdns.1.2025.03.02-1533.x86_64-linux-all.tar.gz

2. Decompression

tar zxf smartdns.1.2025.03.02-1533.x86_64-linux-all.tar.gz

3. Execute the installation script

cd smartdns chmod +x install ./install -i

Installation complete:

The above figure shows the execution content of the self-extracting installation script (./install -i) in the official SmartDNS release package: it mainly completes the process of "copying binary + registering service".

3.2.1.2 Docker installation

1. Create a directory

mkdir -p /etc/smartdns

2. Create a container using the docker run command

docker run -d --name smartdns --restart=always -p 53:53/udp -v /etc/smartdns:/etc/smartdns pymumu/smartdns:latest

3.2.2 Obtaining geosite files

The geosite file mainly comes from the project on GitHub:Loyalsoldier/v2ray-rules-dat, which provides a lot of options:

The specific choice depends on your diversion requirements and scenarios. For me, the requirement is very simple: "specified domain names" use domestic DNS, and the rest use foreign DNS. It is simple, crude, and practical. The "specified domain names" are composed of direct-list.txt and apple-cn.txt in the figure above, which are actually consistent with the two conf files in the "/etc/dnsmasq.d/" path in my previous dnsmasq configuration:
accelerated-domains.china.conf and apple.china.conf.

Merge the contents of "direct-list.txt" and "apple-cn.txt" into the file "/etc/smartdns/china.conf":

curl "https://raw.githubusercontent.com/Loyalsoldier/v2ray-rules-dat/release/direct-list.txt" >> /etc/smartdns/china.conf curl "https://raw.githubusercontent.com/Loyalsoldier/v2ray-rules-dat/release/apple-cn.txt" >> /etc/smartdns/china.conf

Convert the format to SmartDNS recognizable rules, remove "full:", and specify these domain names as cn groups:

sed "s/^full://g;/^regexp:.* $/d;s/^/nameserver \//g;s/$ /\/cn/g" -i /etc/smartdns/china.conf

3.2.3 Create the configuration file smartdns.conf

Create a configuration file:

vim /etc/smartdns/smartdns.conf

Paste the following content in and save:

# Disable IPv6 force-AAAA-SOA yes disable-ipv6 yes # Listen on local port 53 bind :53 # Cache size and performance settings cache-size 2048 dualstack-ip-selection no prefetch-domain yes speed-check-mode ping # Include customized domestic domain name rules (direct-list + apple-cn) conf-file /etc/smartdns/china.conf # Domestic DNS, standard UDP server 119.29.29.29 -group cn server 114.114.114.114 -group cn # Foreign DNS, standard UDP + DoH server 1.1.1.1 -group foreign server 8.8.8.8 -group foreign # Enable concurrent resolution, use the fastest response server-policy fastest-response # The default policy is: Use grouping according to domain name rules nameserver-policy /cn/cn nameserver-policy /china/cn # Others use foreign (Note: If no match is found for cn, foreign is used by default)

When specifying the upstream DNS in the configuration file smartdns.conf, SmartDNS provides a variety of query methods. Currently supported are UDP, TCP, DOT, DOH, DOQ, and DOH3. These query protocols have their own advantages and disadvantages in performance and security, and can be configured and used as needed. The following table is a description of several protocols:

Restart the smartdns service:

systemctl restart smartdns

Note: This section uses smartdns as a downstream DNS client, while smartdns also supports being an upstream DNS server. Compared with dnscrypt-proxy, except for not supporting dnscrypt, other functions are fine. You can choose as needed.

3.2.4 Regularly update china.conf

mkdir /root/script vim /root/script/update-smartdns-china.sh

Paste the following content in and save:

#!/bin/bash # Update SmartDNS's domestic domain name list TMP_FILE="/tmp/smartdns-china.conf.new" > " $TMP_FILE" # Download the latest rules curl -sSL "https://raw.githubusercontent.com/Loyalsoldier/v2ray-rules-dat/release/direct-list.txt" >> "$ TMP_FILE" curl -sSL "https://raw.githubusercontent.com/Loyalsoldier/v2ray-rules-dat/release/apple-cn.txt" >> " $TMP_FILE" # Convert to SmartDNS recognizable format sed -i 's/^full://g;/^regexp:.*$ /d;s/^/nameserver \//g;s/ $/\/cn/g' "$ TMP_FILE" # Overwrite the original china.conf mv "$TMP_FILE" /etc/smartdns/china.conf # Restart SmartDNS service systemctl restart smartdns

Grant execution permissions:

chmod +x /root/script/update-smartdns-china.sh

Then add automatic tasks through crontab -e, such as updating at 3 am every day:

0 3 * * * /root/script/update-smartdns-china.sh

4 Conclusion

In fact, for most personal home network domestic and foreign DNS diversion needs, the conventional diversion logic - "specified domestic domain name queries go to domestic DNS servers, and all others go to foreign DNS" - is sufficient. From the perspective of "realizing diversion", both dnsmasq and smartdns can do the job, especially when used with rule files (such as direct-list.txt and apple-cn.txt), the configuration is also very clear and direct.

But as mentioned earlier in the article, smartdns has a significant advantage over dnsmasq: it supports more diverse and flexible upstream DNS server types: in addition to standard UDP 53 queries, it also natively supports encryption protocols such as DoT (DNS over TLS) and DoH (DNS over HTTPS), making it easier to access modern DNS services such as Cloudflare, Google, NextDNS, and even self-built DOH servers, improving privacy and anti-interference capabilities.

More importantly, smartdns also supports sending requests to multiple upstreams concurrently, and automatically selects the fastest response result to return, which can significantly improve the DNS resolution experience when the network quality fluctuates (dnsmasq is essentially a serial query). In addition, it has built-in caching, pre-fetching, speed testing, automatic speed testing and optimization of domain names, etc. A series of enhanced functions make it not only "capable of diverting traffic" in actual use, but also "fast, accurate, and anti-interference".

The final conclusion: smartdns is better than dnsmasq in realizing domestic and international diversion functions.

The reason why we need to emphasize the upstream DNS server types supported by the diversion software is that this will directly affect the flexibility and fault tolerance of overseas DNS queries: if the diversion software only supports the traditional UDP 53 query method, then the upstream DNS servers that can be used are very limited, and often can only rely on public DNS services such as 1.1.1.1, 8.8.8.8, etc. Although this solution is simple, it is easy to encounter two problems in actual use: first, these public DNS services themselves are easily interfered with, and second, when the family's scientific Internet environment fluctuates or is interrupted, the overseas DNS query may also fail.

If the traffic diversion software supports encrypted DNS protocols such as DoH (DNS over HTTPS) and DoT (DNS over TLS), such protocols can be used as a supplementary or backup DNS query channel. Furthermore, it can be used with a downstream DNS client deployed within the home network that directly uses the domestic broadband export to access the self-built DoH and DoT encrypted DNS services on the remote overseas VPS through Cloudflare transit, Tailscale, or even public IP. Even if the scientific service fails, it can still access the self-built overseas DoH service through the broadband native path, thereby ensuring that the overseas domain name resolution capability is not affected.

Under this design, the overseas DNS query method has a redundant structure with multiple channels:

Science Service Channel → Using standard public DNS, such as 1.1.1.1, 8.8.8.8, has low latency and high speed, and is the preferred choice.
Non-scientific channels + self-built DoH/DoT → Use the native export of home broadband in conjunction with the encrypted DNS service deployed on the overseas VPS to continue to ensure overseas domain name resolution when the scientific service fails.

As shown below:

Since smartdns supports concurrent queries and automatically selects the fastest response mechanism, even if multiple upstream DNS are configured, as long as the scientific service channel is normal, the DNS channel based on the scientific service channel will respond faster and it will be used first, without human intervention, to the greatest extent possible.performanceandAvailability; When there is a problem with the scientific service channel, the response of the non-scientific channel will serve as a backup for foreign queries. For this reason, DNS diversion software with modern protocol support is not only "capable of diversion", but also "capable of backup", which is particularly important in an unstable network environment. To achieve this effect, it is only necessary to fill in the addresses of foreign DNS services under different channels in the configuration file of the overseas upstream DNS server at the same time. Take the smartdns configuration file as an example:

From this perspective, dnsmasq is inferior (because it does not directly support DoT/DoH). If I want to use dnsmasq to achieve the same fault tolerance, I also need to use the previously deployed Adguard home to achieve it (Adguard home supports DoH, DoT and other encryption protocols), which means there is one more functional node.

Note 1: After writing the article, I found out that there is a Mosdns, which is more complex than smartdns and supports more functions. I took a quick glance at it and I don’t need to use the extra functions. Forget it, I’m too lazy to bother with it. Smartdns is enough for the home intranet environment.

Note 2: In order to write this article, I played around with dnsmasq and smartdns. I felt it would be a shame if I didn't use them all, so I ended up setting up the DHCP server on iKuai like this:

In this way, the DNS server addresses of all intranet devices will use smartdns as the first choice and dnsmasq as the backup. Unless the lxc that deploys smartdns and dnsmasq is dead, the domestic and international diversion effect of the intranet DNS requests will be as stable as an old dog.

Share this article