前言
相信大家都接触过openwrt，从几年前仅4M的flash就能刷openwrt的tplink路由器，到现在大家玩的软路由，openwrt都在HomeLab里面扮演着“智能路由器”的角色，一个路由器能干的事情也越来越多，像是DNS、各种科学的插件、远程下载、甚至塞上docker等等。
而写这个系列探讨的事情恰恰相反，为了避免ALL IN BOOM的结局，追求最棒的性能和稳定性，在主路由器只当纯粹的路由器，很硬的硬路由的前提下，如何搭建局域网内的各种服务，实现更HiFi的网上冲浪。或者说，在企业级的环境下，如何实现更好的“优化”方案，毕竟企业级的路由器就真的是路由器。实际上，方案也经过了实际的千人以上企业级环境使用验证，很久之前就想整理出来写文章。缺点也很明显，如果你是ALL IN BOOM的软路由用户，要低碳低功耗，那这个文章系列可能不太适合你的需求。
为啥需要递归DNS
谈起DNS，相信很多折腾软路由都不陌生，大家可能为了一个“最佳的DNS”想尽了各种办法，比如收集各种公共DNS服务器，对他们进行测速，看看哪个快；又或者使用类似SmartDNS这种工具，把返回的结果进行再测速。但无论如何，你查询的DNS的路径都是这样的(以查询ipsu.03k.org为例)：
那这个结果又是怎么来的呢？当然是114作为一个公共DNS服务器，帮你查询了权威DNS服务器（指域名所在的DNS托管服务器，用nslookup查询提示的非权威应答就是这个意思）得到的结果，而114这种公共DNS服务器我们把他叫做“递归DNS”服务器。他的查询过程是这样的：
如果你想知道114用了什么IP来帮你查询权威服务器，你可以运行下面的命令：
或者，你可以使用03k.org的服务：
以上过程只是一个简单的示例，实际上如果你还有CNAME记录套娃的话，这个查询过程也就一层层套下去了，如果你有一个畅通无阻的网络，你可以安装dig命令，使用dig +trace 域名命令来执行一次原生的查询过程：
| |
可以看到，这个过程比起直接查询公共DNS服务器，需要走更多的“路径”，而最后一行也就是权威服务器给的应答，dig也给出每一步所需要的耗时ms，前后加起来也有1秒多了，这也是为什么会有公共DNS服务器的存在，因为如果大家都这么查询的话，上网冲浪实在是比天翼3G还慢。
那既然大家都用公共DNS的话，选择哪个DNS有什么区别吗？首先我们不考虑客户端到公共DNS服务器之间的延迟这个问题，就返回的解析结果来考虑，不同的DNS服务器可能返回不一样的结果。一个常见的场景是，很多域名使用了CDN，解析结果根据所在地理IP来返回，比如你是广东电信，返回在广东电信的服务器地址，而在北京联通就返回北京联通的地址，尽管公共DNS服务器一般都有Anycast（同一个IP有很多台服务器），DNS服务器的地理位置也可能不尽相同，IP的精度也不能面面俱到，有时候结果还不如当地运营商的公共DNS。虽然有ECS这种协议存在（DNS ECS是DNS协议的一个扩展，它允许递归DNS解析器在发送给权威DNS服务器的请求中包含终端用户IP地址数据的部分），但首先它是用在递归DNS上的，也就是部署在114这种公共服务器上的，其次你请求的域名所在的权威DNS要支持ECS协议才可以，说白了这个协议对局域网用户来说没什么用（因为你什么都做不了）。
那么有什么完美的DNS服务器呢？答案是我们可以拥有属于自己的递归DNS服务器，说白了就是把114这样的DNS服务器装你家里。这样你的每个请求都非常的原生地到达了权威DNS服务器，获取的结果可谓是准确中的准确。你再也不需要对DNS服务器进行收集和测速，也不需要对解析结果进行测速（实际上，你已经获取了原生的准确解析结果了，测它没有什么意义，多个DNS解析结果本来就是为了能DNS轮询负载均衡故障转移，比如在一个大局域网大家都用同一个IP连接视频播放地址可能就不是一个好主意），实在是强迫症治愈良药。
除了以上原因，一个不太常见的问题就是，你觉得公共DNS服务器值得信任吗？在不考虑DNS解析结果被运营商劫持的情况下，你怎么能保证它返回的结果值得信任？毕竟你不是直接问的权威DNS服务器，自然结果也是凭良心了（虽然有DNSSEC这种东西存在，但它并不能解决DNS劫持和污染，你除了知道它结果可能是错的之外什么都做不了）。即使DNS结果值得信任，但你的查询记录可能会被公共DNS服务器记录日志，四舍五入你上了什么网站，什么时间上的，IP地址是什么，这些都可以入了公共DNS的大数据系统，也就是可能会造成一定的隐私问题。尽管有的公共DNS澄清自己是干净无记录的，但你怎么能保证他们能遵守诺言呢？是的，你不能保证。一个更加离谱的可能是，如果公共DNS服务器被攻击，那你的查询结果可能被引导到恶意网站，就算这种可能性比较低，公共DNS服务器也有故障的时候，你可能又开始考虑：我能保证谁的公共DNS服务器100%稳定性？是的，你不能保证。但当你拥有一台属于自己的递归DNS服务器的时候，稳定性和隐私问题将由你自己掌控。
如何搭建递归DNS服务器
这里推荐使用unbound作为递归DNS服务器程序，理由如下：
- unbound是一个老牌安全的开源递归DNS服务器，主要由NLnet Labs，VeriSign Inc.，Nominet开发。它可以直接查询权威的DNS服务器，而不需要依赖其他上游DNS服务器，稳定性经过长久验证。
- unbound支持redis缓存（redis版本要编译安装），性能表现优异，曾经对比过多款递归DNS服务程序，从压力测试结果来看unbound是非常不错的选择，如果说哪个DNS服务的缓存性能和算法值得信赖，unbound肯定是其中之一（well，没错我说的就是GitHub上各种奇奇怪怪的智能DNS服务的缓存会出现各种奇奇怪怪的bug）。
- 具有完美可控的缓存和预读取功能，DNS记录可以通过redis持久化和接近ttl过期的时候进行预读取，即使过期也能通过返回一个低值ttl的旧记录后秒刷新，实现无感知的“网页秒开”，当然，你内存越大能存的记录越多体验越好啦（不过一般来说就算是重度企业使用能存下2G也很厉害了）。
- unbound支持完整的DNS协议实现，能保证各种结果的准确性和其他可能用不上的高级自定义。
具体的搭建可以参考官方文档：
https://unbound.docs.nlnetlabs.nl/en/latest/
以及优化指南:
https://www.nlnetlabs.nl/documentation/unbound/howto-optimise/
看到这里你是不是开始头疼了，要编译unbound，还要搞清楚一堆参数配置，还要配置redis，如果你在China大陆，你还得考虑境外DNS防污染的问题，实在头疼。
Well，这就是接下来要说的重点，为了能一键部署，我做了个docker镜像，一次满足你所有需求~！
PaoPao DNS docker
泡泡DNS是一个能一键部署递归DNS的docker镜像，它使用了unbound作为递归服务器程序，使用redis作为底层缓存，此外针对China大陆，还有智能根据CN分流加密查询的功能，也可以自定义分流列表，可以自动更新IP库，分流使用了mosdns程序，加密查询使用dnscrypt程序，针对IPv4/IPv6双栈用户也有优化处理。
为啥叫泡泡DNS，因为部署DNS就像吹泡泡一样简单（其实我写docker的时候刚好在看《泡泡》）。
（AI生成的LOGO）
Github 项目地址： https://github.com/kkkgo/PaoPaoDNS
(っ◞‸◟c)都看到这里了，点个Star吧
更新日志
以下文档说明以Github最新文档为准
docker镜像： sliamb/paopaodns
泡泡DNS适合的使用场景：
- 场景一：仅作为一个纯粹准确的递归DNS服务器，作为你其他DNS服务程序的上游，替代
114.114.114.114,8.8.8.8.8等公共DNS上游 - 场景二：作为一个局域网内具备CN智能分流、解决污染问题和IPv6双栈优化的DNS服务器，或者你的局域网已经从IP层面解决了“科学”的问题，需要一个能智能分流的DNS服务器。
使用方法和参数说明
简单来说，那么你可以运行：
如果你需要容器运行在同一个局域网段而不是单独映射端口，除了一些NAS有现成的界面点点点，原生docker你可以考虑使用macvlan如下的配置(假设你的网络是192.168.1.0/24)：
| |
如果你的网络端口没有冲突，也可以考虑使用docker host网络模式以获得最佳性能。
如条件允许建议使用docker compose部署
如果你的网络环境访问Dokcer镜像有困难，可以尝试使用上海交大的镜像。
验证你的递归DNS正常运行(假设你的容器IP是192.168.1.8)，可以执行以下命令：
或者，你可以使用03k.org的服务：
如果返回的IP和你宽带的出口IP一致的话，说明你的递归DNS服务正常运作了。
搭建完请简单验证所有DNS组件是否工作正常：
同时你可以查阅更新日志的最新版本公告时间，检查输出的镜像版本时间是否大于等于当前最新版本。
需要注意的是，如果你的网络有“自动分流IP”的功能，请把容器的IP加入不分流的名单，因为权威DNS需要准确的IP去判断，IP分流会影响权威DNS的判断。此外，一些软路由存在劫持DNS请求的情况，解决办法参见这个issue。
[DNS hijack]DNS劫持算是经常问的高频问题了，请参考
docker的运行家用建议内存2G，企业环境建议16G，再大了意义不太大（实际内存占用差不多达到4G已经很厉害了，当然，内存越大性能越好，命中率体验更棒），容器启动的时候会根据可用内存调整配置文件参数，占用内存不会超过上限。根据Github的使用者反馈，有最低512M内存的ARM路由器流畅使用的案例。实际上，在最低参数启动下的缓存也是能满足家庭使用需求的。
直接拉取镜像运行即可，你需要挂载容器的/data目录，该目录会存放所有配置文件、DNS缓存文件和更新的数据，容器重新启动的时候也会直接读取。如果你是在隔离的网络中运行的容器，你需要映射53端口出来，需要注意的是你的宿主也可能运行着DNS服务，跟53端口冲突，这个需要你自己解决（比如禁用自带的DNS服务）。当然，最佳的运行网络环境是跟你的客户端在同一个网段设置一个静态IP，原生docker的话可以使用macvlan网络实现，或者某些NAS提供了docker的桥接到物理网卡的点点点选择（如果你要写docker compose的话，威联通的NAS的桥接网络驱动类型是qnet）。
环境变量参数如下：
| 环境变量 | 默认值 | 可用值 |
|---|---|---|
| CNAUTO | yes | yes,no |
| DNSPORT | 53 | 端口值 |
| DNS_SERVERNAME | PaoPaoDNS,blog.03k.org | 不含空格的英文字符串 |
| SERVER_IP | 空，非必须。 | IP地址，如10.10.10.8 |
| SOCKS5 | 空，非必须。 | 如：10.10.10.8:7890 |
| TZ | Asia/Shanghai | tzdata时区值 |
| UPDATE | weekly | no,daily,weekly,monthly |
| IPV6 | no | no,yes,only6,yes_only6,raw |
| CNFALL | yes | no,yes |
| CUSTOM_FORWARD | 空，可选功能 | IP:PORT,如10.10.10.3:53 |
| CUSTOM_FORWARD_TTL | 0 | 1-604800 |
| AUTO_FORWARD | no | no,yes |
| AUTO_FORWARD_CHECK | yes | no,yes |
| USE_MARK_DATA | no | no,yes |
| RULES_TTL | 0 | 1-604800 |
| USE_HOSTS | no | no,yes |
| HTTP_FILE | no | no,yes |
| SAFEMODE | no | no,yes |
| ADDINFO | no | no,yes |
| SHUFFLE | no | no,yes,lite,trnc |
| QUERY_TIME | 2000ms | time.Duration |
用途说明：
- CNAUTO：是否开启CN大陆智能分流，如果位于境外可配置为no
- DNSPORT：设置DNS服务器端口，仅在CNAUTO=no时生效
- DNS_SERVERNAME：DNS的服务器名称，你使用windows的nslookup的时候会看到它。注意，该选项仅在容器的网卡IP和外部网卡IP一致的时候生效（比如macvlan）。
- SERVER_IP：指定DNS服务器的外部IP。假设你的DNS容器是宿主
10.10.10.4映射出来的端口而不是独立的IP，设置该项为10.10.10.4可以让你看到正确的DNS_SERVERNAME。同时会设定域名paopao.dns指向该IP地址10.10.10.4，可配合其他服务使用。 - SOCKS5：为分流非CN IP的域名优先使用SOCKS5查询（如
10.10.10.8:7890，强制使用socks5查询则加上@，比如@10.10.10.8:7890），但没有也能查，非必须项。仅在CNAUTO=yes时生效。SOCKS5初始化会有大概3分钟的延迟连接测试过程，期间的解析结果并非最优延迟。 - TZ: 设置系统的运行时区，仅影响输出日志不影响程序运行
- UPDATE: 检查更新根域数据和GEOIP数据的频率,no不检查,其中GEOIP更新仅在CNAUTO=yes时生效。注意：
daily,weekly,monthly分别为alpine默认定义的每天凌晨2点、每周6凌晨3点、每月1号凌晨5点。更新数据后会瞬间完成重载。 - IPV6： 仅在CNAUTO=yes时生效，是否返回IPv6的解析结果，默认为no，如果没有IPv6环境，选择no可以节省内存。设置为yes返回IPv6的查询（为分流优化，非大陆双栈域名仅返回A记录）。如果设置为
only6，则只对IPv6 only的域名返回IPv6结果。如果设置为yes_only6，则对大陆域名返回IPv6的解析结果（相当于yes），对非大陆域名只对IPv6 only的域名返回IPv6结果（相当于only6）。如果设置为raw，则不对IPv6结果做任何处理，直接返回原始记录。 - CNFALL: 仅在CNAUTO=yes时生效，在遇到本地递归网络质量较差的时候，递归查询是否回退到转发查询，默认为yes。配置为no可以保证更实时准确的解析，但要求网络质量稳定（尽量减少nat的层数），推荐部署在具备公网IP的一级路由下的时候设置为no； 配置为yes可以兼顾解析质量和网络质量的平衡，保证长期总体的准确解析的同时兼顾短时间内网络超时的回退处理。
- CUSTOM_FORWARD: 仅在CNAUTO=yes时生效，指定一个自定义的IP:端口的DNS服务器，将
force_forward_list.txt内的域名列表转发到到CUSTOM_FORWARDDNS服务器。该功能可以配合第三方旁网关的fakeip，域名嗅探sniffing等特性完成简单的域名分流效果。 - CUSTOM_FORWARD_TTL：该项设置的值大于0的时候生效，设定CUSTOM_FORWARD的ttl的最小值。
- AUTO_FORWARD：仅在CNAUTO=yes时生效，配合
CUSTOM_FORWARD功能使用，默认值为no，当设置为yes的时候，解析非CN大陆IP的域名将会直接转发到CUSTOM_FORWARD。 - AUTO_FORWARD_CHECK：在
AUTO_FORWARD=yes时，转发前是否检查域名是否有效，避免产生无效查询。默认值为yes，设置为no则不检查。 - USE_MARK_DATA：该项默认值为no，当设置为yes的时候，将会自动更新下载预先标记处理的全球百万域名库，在判断大陆分流的时候优先使用该数据，该功能仅标记数据，后续如何处理取决你的设置（比如默认分流或者自动转发）。域名数据库来源于
paopao-pref项目定期更新。该功能：- 优点：可以优化DNS泄漏问题、提供更快速精准高效的分流
- 缺点：会占用更多内存，增加容器启动时间
- RULES_TTL：该项设置的值大于0的时候生效，将
/data/force_ttl_rules.txt里面指定的域名转发到指定的DNS服务器，并修改其TTL值为RULES_TTL。该功能仅对A记录和AAAA记录生效，其他记录请参考进阶自定义示例一节。该功能可以适用于多种场景，比如想实现在异地的网络访问回家的DDNS域名的结果更实时一点，你可以把RULES_TTL设置为一个较低的值，然后把你的DDNS域名指定转发到对应的权威DNS服务器（也就是whois信息的NS服务器对应的IP地址，注意不要CNAME嵌套）即可。force_ttl_rules的规则格式为域名@服务器:端口，以下都是合法的格式：
| |
此外，RULES_TTL功能也可以直接指定某个域名的A记录或者AAAA记录，或者“CNAME”到另一个域名。格式使用域名@@记录或者域名@@@记录，以下都是合法的格式：
| |
- CN_TRACKER：仅在CNAUTO=yes时生效，默认值为yes，当设置为yes的时候，强制
trackerslist.txt里面tracker的域名走dnscrypt解析。更新数据的时候会自动下载最新的trakcerlist。该功能在一些场景比较有用，比如AUTO_FORWARD配合fakeip的时候可以避免使用fakeip连接tracker。 - USE_HOSTS: 当设置为yes的时候，在启动时读取容器/etc/hosts文件。可以配合docker的
-add-hosts或者docker compose的extra_hosts使用。仅在CNAUTO=yes时生效。 - HTTP_FILE: 当设置为yes的时候，会启动一个7889端口的http静态文件服务器映射
/data目录。你可以利用此功能与其他服务程序共享文件配置。 - SAFEMODE： 安全模式，仅作调试使用，内存环境存在问题无法正常启动的时候尝试启用。
- ADDINFO： 默认为
no,设置为yes时，在DNS查询结果中增加ADDITIONAL SECTION的调试信息，如结果来源、查询延迟、失败原因等，使用dig命令就可以实时追踪域名结果来源，详情参考更新日志( https://github.com/kkkgo/PaoPaoDNS/discussions/61 )。该功能仅对CNAUTO=yes生效。 - SHUFFLE 默认为
no,设置为yes时，对解析的结果进行洗牌实现Round-robin DNS（注：SHUFFLE功能是对每次查询都进行洗牌输出。即使设置为no，在DNS的ttl过期后重新提供的DNS记录本身是经过unbound洗牌过的）。当设置为lite，返回精简的仅与请求类型匹配的回应，参考更新日志( https://github.com/kkkgo/PaoPaoDNS/discussions/108 )；当设置为trnc，在lite选项的基础之上，如果返回的记录大于3个，则每次洗牌完成后仅在ttl有效期内输出3个随机记录，参考更新日志( https://github.com/kkkgo/PaoPaoDNS/discussions/109 ) - QUERY_TIME：限制DNS转发最大时间，仅作调试使用，随意更改此值会导致你查不到DNS结果。
| 可映射端口 | 端口用途 |
|---|---|
| 53 | 提供DNS服务的端口，在CNAUTO=no时数据直接来自unbound，CNAUTO=yes时数据来自mosdns |
| 5301 | 在CNAUTO=yes时，递归unbound的端口，可用于dig调试 |
| 5302 | 在CNAUTO=yes时并设置了SOCKS5时，走SOCKS5的dnscrypt服务端口，可用于dig调试 |
| 5303 | 在CNAUTO=yes时，原生dnscrypt服务端口，可用于dig调试 |
| 5304 | 在CNAUTO=yes时，dnscrypt的底层unbound实例缓存，可用于dig调试或者fakeip网关的上游 |
| 7889 | HTTP_FILE=yes时，http静态文件服务器端口 |
挂载共享文件夹/data目录文件说明：存放redis数据、IP库、各种配置文件，在该目录中修改配置文件会覆盖脚本参数，如果你不清楚配置项的作用，请不要删除任何注释。如果修改任何配置出现了异常，把配置文件删除，重启容器即可生成默认文件。
注：群晖等挂载权限问题参考
redis.conf：redis服务器配置模板文件，修改它将会覆盖redis运行参数。除了调试用途，一般强烈建议不修改它。容器版本更新将会覆盖该文件。redis_dns_v2.rdb：redis的缓存文件，容器重启后靠它读取DNS缓存。刚开始使用的时候因为递归DNS有一个积累的过程，一开始查询会比较慢(设置了CNFALL=no的话，如果CNFALL=yes查询速度不会低于公共DNS)，等到这个文件体积起来了就很流畅了。容器版本更新不会覆盖该文件。
注意：redis_dns_v2.rdb文件生成需要累积达到redis的最持久化要求，取决于redis.conf的配置，默认最低2小时后才会进行一次持久化操作。如果你升级容器的镜像，可以删除其他所有配置文件而保留这个rdb文件。unbound.conf：Unbound递归DNS的配置模板文件，除了调试用途，一般不要修改它。容器版本更新将会覆盖该文件。unbound_custom.conf：Unbound的自定义配置文件，里面内置了一些高级自定义的示例。容器版本更新不会覆盖该文件。
以下文件仅在开启CNAUTO功能时出现：dnscrypt-resolvers文件夹：储存dnscrypt服务器信息和签名，自动动态更新。容器版本更新将会覆盖该文件。Country-only-cn-private.mmdb：CN IP数据库，自动更新将会覆盖此文件。容器版本更新将会覆盖该文件。global_mark.dat：USE_MARK_DATA功能的数据库，自动更新将会覆盖此文件。容器版本更新将会覆盖该文件。dnscrypt.toml：dnscrypt配置模板文件，修改它将会覆盖dnscrypt运行参数。除了调试用途，一般不修改它。容器版本更新将会覆盖该文件。force_forward_list.txt： 仅在配置CUSTOM_FORWARD有效值时生效，强制转发到CUSTOM_FORWARDDNS服务器的域名列表，容器版本更新不会覆盖该文件。一行一条，语法规则如下：
以domain:开头域匹配:domain:03k.org会匹配自身03k.org，以及其子域名www.03k.org,blog.03k.org等。
以full:开头，完整匹配，full:03k.org只会匹配自身。完整匹配优先级更高。
以regexp:开头，正则匹配，如regexp:.+\.03k\.org$。Go标准正则。
以keyword:开头匹配域名关键字，如以keyword: 03k.org会匹配到www.03k.org.cn
尽量避免使用regexp/keyword会消耗更多资源。域名表达式省略前缀则为domain:。同一文本内匹配优先级：full > domain > regexp > keywordforce_dnscrypt_list.txt：强制使用dnscrypt加密查询结果的域名列表，匹配规则同上。容器版本更新不会覆盖该文件。force_recurse_list.txt：强制使用本地递归服务器查询的域名列表，一般不会用到该list，强制递归的域名不会被生效CNFALL功能，匹配规则同上。容器版本更新不会覆盖该文件。force_ttl_rules.txt: 参见RULES_TTL功能。修改将实时重载生效。容器版本更新不会覆盖该文件。- 修改
force_forward_list.txt或force_dnscrypt_list.txt或force_recurse_list.txt或force_ttl_rules.txt将会实时重载生效。 - 文本匹配优先级
(custom_mod功能seq: top)>force_forward_list>force_dnscrypt_list>force_recurse_list>force_ttl_rules>(custom_mod功能seq: list)>其他自动分流逻辑。 - 注意事项：由于跨平台系统差异，不建议使用Windows自带记事本编辑。如果list出现了问题无法读取或者无法生效，可以直接删除list文件，重启容器会自动重建默认的list。如果你想解析的域名位于境外，并且没有境内CDN，而你又想获取原始记录（与
force_forward_list.txt或者使用AUTO_FORWARD功能获取到的解析记录区分开），那么你应该把域名加进force_dnscrypt_list.txt而不是force_recurse_list.txt，因为基于个人网络环境差异，递归服务器位于境外的域名存在递归失败的可能。force_recurse_list.txt的应用场景一般应仅限于特殊域名递归调试，大部分场景都不适用于force_recurse_list.txt。 此外，你可以根据文本匹配优先级灵活设置同一个域名子域名走不同的list。（参考 ）。 trackerslist.txt：bt trakcer列表文件，开启CN_TRACKER功能会出现，会增量自动更新，更新数据来源 ，你也可以添加自己的trakcer到这个文件(或者向该项目提交)，更新的时候会自动合并。修改将实时重载生效。容器版本更新不会覆盖该文件。force_ttl_rules.txt: 参见RULES_TTL功能。修改将实时重载生效。容器版本更新不会覆盖该文件。mosdns.yaml：mosdns的配置模板文件，修改它将会覆盖mosdns运行参数。除了调试用途，一般强烈建议不修改它。容器版本更新将会覆盖该文件。custom_env.ini可以自定义环境变量，会覆盖在容器在启动时的环境变量。在容器启动后修改该文件将会导致MosDNS重载，但在容器启动后修改的环境变量不会影响已经启动的其他组件。配置的格式为key="value"（注意英文双引号），错误格式的环境变量将会被忽略加载。容器版本更新不会覆盖该文件。custom_mod.yaml可以自定义一些高级功能，参见下面的custom_mod.yaml文件说明。错误的配置可能导致服务运行异常。需要重启容器应用配置。容器版本更新不会覆盖该文件。
custom_mod.yaml配置说明
| |
注：Swaps应用场景参考：替换指定IP段的解析结果为指定IP
工作逻辑细节
如果你仅使用递归Unbound DNS的功能（CNAUTO=no），那么工作逻辑比较简单：
- 容器启动初始化，根据内存和CPU性能生成配置文件
- 启动unbound作为递归DNS服务器
- 使用redis作为缓存，缓存数据位于/data/redis_dns_v2.rdb
- 根据设置的
UPDATE更新频率更新根域名服务器文件（事实上，这个文件不需要频繁更新，因为根服务器往往只会在初始查询的时候用到，根服务器文件的更新频率也很低，并且更新脚本会自动验证存在正确MD5且不一致才会更新）
在开启了智能分流的情况下（CNAUTO=yes），工作逻辑稍微复杂一些：
- 容器初始化在生成配置的同时将同时生成初始GEOIP数据和dnscrypt服务器信息（如果不存在的话），以及相关其他程序的配置模板文件。
- 启动dnscrypt服务，dnscrypt是一个解决DNS污染的程序，该服务将会自动拉取可用的dnscrypt服务器信息并自动测试延迟和可用性、负载均衡和故障转移。如果你配置了
SOCKS5变量，将会额外再启动一个使用了SOCKS5代理的dnscrypt实例，这里把它称为dnscrypt-socks。一般来说，即使不配置SOCKS5也能正常使用，但如果你的代理跟目标线路一致，这有可能帮助你获取更理想的解析结果。 - 启动两个unbound实例，第一个unbound实例为查询递归DNS用途，这里把它称为
unbound-local。第二个unbound实例为缓存dnscrypt用途，这里把它称为unbound-dnscrypt，它的上游是dnscrypt，如果配置了SOCKS5变量，它的上游将会优先dnscrypt-socks。redis缓存将会同时接受这两个unbound实例的请求。 - 启动mosdns进行分流处理（不缓存任何请求，缓存由redis完成），处理过程如下：
- 拒绝qtype65请求（避免apple设备类型被动使用https DNS）
- 读取
force_nocn_list.txt的域名列表，直接转发到unbound-dnscrypt。 - 读取
force_cn_list.txt的域名列表，直接转发到unbound-local。 - 先尝试请求
unbound-local，如果返回的结果IP位于China大陆，则接受并返回到客户端。 - 如果返回的结果不位于China大陆，则把结果抛弃并转发到
unbound-dnscrypt。 - 如果请求的域名使用了
unbound-dnscrypt，并且同时具备IPv4和IPv6的解析，那么将会仅返回IPv4记录，过滤IPv6记录，如果仅有IPv6记录，将不会过滤，这个流程是考虑双栈用户的分流问题，因为应用端会优先使用IPv6地址而导致你的静态路由失效，但又不放弃那些仅有IPv6的网站。
进阶自定义示例
- 在企业内可能需要的一个功能，就是需要和AD域整合，转发指定域名到AD域服务器的方法：
打开
/data/custom_mod.yaml编辑：
- 添加微软KMS服务器SRV记录
如果有其他高级的自定义需求，欢迎在discussions里面参与讨论。
附赠：PaoPao-Pref
这是一个让DNS服务器预读取缓存或者压力测试的简单工具，配合PaoPaoDNS使用可以快速生成redis_dns_v2.rdb缓存。从指定的文本读取域名列表并调用nslookup命令查询记录，docker镜像默认自带了全球前100万热门域名。
详情：https://github.com/kkkgo/PaoPao-Pref
相关项目：PaoPaoGateWay
PaoPao GateWay是一个体积小巧、稳定强大的FakeIP网关，支持Full Cone NAT ，支持多种方式下发配置，支持多种出站方式，包括自定义socks5、自定义yaml节点、订阅模式和自由出站，支持节点测速自动选择、节点排除等功能，并附带web面板可供查看日志连接信息等。PaoPao GateWay配合PaoPaoDNS的CUSTOM_FORWARD功能就可以完成简单精巧的分流。
详情：https://github.com/kkkgo/PaoPaoGateWay
附录：使用到的程序
unbound：
- https://nlnetlabs.nl/projects/unbound/about/
- https://www.nlnetlabs.nl/documentation/unbound/howto-optimise/
- https://unbound.docs.nlnetlabs.nl/en/latest/
redis: https://hub.docker.com/_/redis
dnscrypt:
- https://github.com/DNSCrypt/dnscrypt-proxy
- https://github.com/DNSCrypt/dnscrypt-resolvers
- https://dnscrypt.info/
mosdns:
GEOIP: