na

Pari Public DNS 更新

Sun, 19 Oct 2025 00:00:00 GMT

5年！

Pari Public DNS 不知不觉已经运营了5年，直至今日，已经为数以万计的用户提供服务，每个月的查询量 2亿+ 次，感谢大家的支持与信任

过去有什么问题

在过去的一段时间里，Pari DNS 一直在使用 AdGuardHome 提供广告过滤与响应缓存服务，规则集来源于 Cats-Team/AdRules ，上游使用企业版 Cloudflare Gateway (支持 EDNS) + Fallback 递归DNS的方案

这个旧方案体验反馈良好，响应速度快 (平均<5ms) ，解析结果基本正确，但仍然存在诸多问题：

AdGuardHome 的 CacheKey 配置简单，无法根据不同的 ECS 分发响应的缓存，即便在使用支持 EDNS 的上游，也会导致缓存串扰，不同的客户端对于同一域名会收到相同结果，使得连接到的地区或 ISP 不同造成实际体验下降
对于广告过滤方法，AdGuardHome 原生提供的方式只有返回错误的 IP 地址 / NXDOMAIN / REFUSED ，无法返回 NOERROR ，若返回错误的 IP ，可能会导致等待超时造成延迟，若返回 NXDOMAIN/REFUSED ，可能会导致回退到其它可用 DNS 并解析出正确结果
广告过滤规则不够全面，如现在有非常多的应用程序内置 HTTPDNS 等绕过系统 DNS 进行查询，应用内置类 PCDN 泛滥，需要自行构建更全面好用的过滤规则
AdGuardHome的部分实现过于简单，性能低下，仅适合自用部署，应该有更好的方式来进行查询和提供公共服务
只要有可靠上游 DNS 并可信，额外的回退递归服务器与检查 DNSSEC 似乎用处不大
DoH 不支持 DNS-over-HTTP/3，AdGuardHome 更新缓慢，新特性支援差，滞留问题多

总体而言，AdGuardHome 的确非常 "Home"

:::tip

对于本服务的一切数据分析基于匿名化的 IP

:::

这次升级解决了什么

NLnetLabs/unbound 可以提供基于 ECS 的缓存规则，配置全面，适合作为最底层提供查询和缓存服务的上游 DNS，根据基于前期对各大 DNS ECS 支持与准确性的分析，在 unbound 中，使用转发到 Cloudflare Gateway / Google Public DNS / 递归 DNS 查询的方案，转发 ECS 并进行缓存，这样可以不浪费查询的同时提高可用性

仍然使用 AdGuardHome 进行广告过滤，创建了一个新的规则过滤库，合并了多个上游和自行收集的域名规则，并为 AdGuardHome 特别生成了一个 dnsrewrite 版本，将广告过滤方式修改为返回 NOERROR，这样可以有效地避免上述问题2和3

::github{repo="Natsuki-Kaede/Natsuki-List"}

配置 unbound 作为 AdGuardHome 的上游，在这里我发现 unbound 本身转发速度比较慢，同时由于 ECS 分别缓存所以缓存命中里极低，因此整体响应速度偏慢，为了解决这个问题，创建了一个 cloudflared 代理的 Cloudflare Gateway，作为 AdGuardHome 的第二个上游，并发地请求它们，这样如果能够命中缓存，unbound 可以返回更快更准确的结果，若无缓存，也能够保证及时响应，同时在 unbound 中缓存一份结果以便下次取用，彻底解决问题1和4

使用 openresty 对外提供性能更好更标准的 DoH 服务，并支援 gzip/brotli/zstd 压缩，可以提供压缩后的响应，并支援 HTTP/3 ，同时可以为以后的扩容与分流预留可配置空间

因为需要根据 ECS 精细地缓存，在这个方案部署的初期，查询响应速度可能会略微下降，但可以收到较为准确的结果，整体网络体验应是更好的，后期缓存命中率提高后，响应速度理论上会较旧方案提高

还有问题？

[ ] 需要运行的服务太多了，服务器配置低内存小，可能挤占缓存空间
[ ] 维护难度上升
[ ] ECS 缓存命中率低，需要后续观察
[ ] 每次重新查询的开销大同时导致响应速度变慢，要先观察缓存情况

以后的事情

[ ] 考虑自己实现一个 DNS 服务器来满足上述需求，便于维护和管理
[ ] 扩容服务器，但目前看来暂时不需要，~~也没有钱~~
[ ] 多点部署，不久后会增加欧洲与北美服务器

加密DNS的提供方式（升级后）

Origin：

直接从源服务器提供的服务

不同域名的服务均相同，只是为了防止部分地区可能阻断/污染

DNS-over-HTTPS (:443, HTTP/2, HTTP/3):

https://dns.flymc.cc/dns-query

https://doh.flymc.cc/dns-query

https://resolver.flymc.cc/dns-query

DNS-over-TLS (:853):

tls://dns.flymc.cc

tls://dot.flymc.cc

DNS-over-QUIC (:853):

 quic://dns.flymc.cc

CDN:

通过 Cloudflare CDN 提供服务，适合全球使用（尤其是在实现多点部署后）（仅支持 DoH）

DNS-over-HTTPS (:443, HTTP/2, HTTP/3):

https://dns.pari.network/dns-query

https://doh.pari.network/dns-query

Finally

从 AdGuardHome 的日志来看，响应速度是不错的，广告过滤也全部重写为了 RCODE:0 NOERROR

如有任何反馈和建议，欢迎联系我！

Nextcloud 各种踩坑记录？

Sun, 06 Jul 2025 00:00:00 GMT

一定要使用容器!

Nextcloud这一大坨在维护和迁移过程中极其麻烦，直接使用容器可以极大地减少运维成本

无论是普通版本还是aio，请使用Docker/Podman

如果接入对象存储

在服务器本身存储受限的情况下，我们可以考虑接入对象存储

Nextcloud自带的外部存储功能并不符合“将对象存储作为主存储”的需求，而按照官方文档: Configuring Object Storage as Primary Storage的接入方式性能极差(尝试用netcup rs德国直接接入 Wasabi Frankfurt，上下行只有约5 MB/s)，并且和部分提供商不兼容，不可以透过Cloudflare传输（无法利用Cloudflare Bandwidth Alliance节省Egress流量），如果有加密需求，Nextcloud自带的加密模块也不是一个很好用的东西，所以需要考虑更优的解决办法

最简单的方式是用s3fs或者类似物将bucket直接挂载到服务器上，并把Nextcloud的数据目录放在上面，这样我们就将对象存储的工作交给了性能更好的其它软件上，让Nextcloud本身无法感知，从而提升性能

可能是更好一点的方法：我使用了JuiceFS来连接对象存储，这样我们就可以将所有工作都交给JFS，只需要维护元数据，它的性能要远高于s3fs和efs，并且支持RSA + AES-GCM加密，在绝大多数支持AES-NI的服务器上性能损耗很小，可以替代Nextcloud的服务器加密，加密后也可以防止因为用户上传CASM/版权内容导致对象存储账号被扬

这类分布式文件系统优点非常明显，迁移和维护方便（只需要动元数据库），性能优秀（支持缓存和预取）... 它还可以透过Cloudflare接入bucket而不是只能使用Endpoint（不知道为什么，这点我在很多使用对象存储的应用上都做不到）

在用了一短时间后，没有发现很致命的缺点，小问题有：单机下会受限于网络和本机性能，IOPS可能没有大容量HDD服务器高，但得益于缓存、缓冲区、预取，在应用层面感知不大；消耗流量，接入对象存储本来就非常消耗流量，jfs的Prefetch功能会带来一定的读放大，会消耗流量（可能还会增加存储桶的操作计数），所以在使用时应该尽量选择大流量/无限流量的服务器和支持Cloudflare Bandwidth Alliance/不计次数和免费Egress的服务提供商来平衡成本

禁用公共可读的System Address Book

也许是Nextcloud专为彼此认识的公司/团队设计，在安装后system_addressbook_exposed为yes，在contacts功能中你将默认可以看到所有用户的用户名和Email，在共享对话框和各种输入框中也会根据这个系统地址簿显示自动补全，如果你是个人使用或者作为公共服务提供，那么这个默认行为明显不合理，使用命令 occ config:app:set dav system_addressbook_exposed --value="no" 来禁用它，并在共享中关闭允许在共享对话框中自动完成帐户名称并允许访问系统地址簿以保护你和其它人的隐私

启用OPCACHE

这里不是踩坑，只是记一下推荐的OPCACHE参数

opcache.enable = 1
opcache.interned_strings_buffer = 128
opcache.max_accelerated_files = 50000
opcache.max_wasted_percentage=15
opcache.memory_consumption = 512
opcache.validate_timestamps = 0
opcache.revalidate_freq = 0
opcache.save_comments = 1
opcache.fast_shutdown=1
opcache.jit = 1255
opcache.jit_buffer_size = 256M

配置Redis作为memcache

即便官方不推荐，我也将 'memcache.local' 'memcache.distributed' 'memcache.locking'这三个字段全部写成了\OC\Memcache\Redis，不想用APCu和Memcached（

这里有个比较逆天的坑：Nextcloud将redis的端口写死在了6379，即便是在array里自定义port字段也是6379，当时无论如何都连不上redis令人头大最后改成了默认端口才好orz

如果使用nginx，不要缓存

本身不需要缓存，如果开启后会导致问题，总之不建议开

Collabora & Talk HPB

Collabora需要能公开访问...不知道是我傻还是Nextcloud&Collabora官方文档不清楚，我在单独配置Collabora时使用容器内网连接，在Nextcloud管理后台中可以连接成功，但无法正常使用，最后单独开了个域名把服务放出来就可以用了...

Talk HPB（高性能后端）因为没需求所以没部署（尝试过但太混乱了遂关闭），如果不想踩坑推荐直接用aio而不是自己单独部署

Finally

因为重建了不久，所以遇到的坑暂时就这么多，后续会继续补充

如果你想试试这样部署的Nextcloud性能如何，或者需要Collabora，欢迎email我

Migrated to astro!

Sat, 05 Jul 2025 00:00:00 GMT

决定将这个blog迁移到astro!

之前的内容在不久的将来会（有选择性地）同步到这里

使用的主题是：

::github{repo="saicaca/fuwari"}

Pari Public DNS 將僅提供加密DNS服務，停止無加密DNS解析

Tue, 25 Jun 2024 00:00:00 GMT

P-A-R-i~!

Pari Public DNS 上綫已有近4年的時間，每年為用戶提供約10億+次解析，總共50億+次，服務期間SLA ≥ 99.9%，平均解析時延 < 5ms.🎉

Pari DNS將在2024年7月1日后不再提供無加密查詢功能(TCP/UDP 53)，此後僅提供加密DNS服務。

爲什麽不再提供無加密DNS

被嚴重污染的網絡環境

在網絡環境日益惡劣的時代，（尤其是在中國的嚴重DNS污染下）無加密DNS的解析結果變得不再可靠，有90%的無加密查詢請求來自中國大陸，這些用戶極有可能會在收到正確的查詢結果前被ISP或其它設施搶答，收到錯誤的結果，這也使網絡變得不再安全。

攻擊無處不在

Pari DNS伺服器暴露的TCP/UDP 53端口的無加密DNS收到了大量來自Brazil的攻擊，起初是對cisco.com大量查詢TXT記錄進行放大攻擊，在禁止相關域名的TXT記錄查詢一段時間後，攻擊者開始使用隨機域名和相同的手法進行DNS放大攻擊（https://pari.cafe/notes/9ujw8lvhzy），這大量消耗了網絡資源，造成了不必要的開銷。

加密DNS的提供方式(WIP)

Pari DNS將繼續提供完整且标准的加密DNS功能

將提供以下類型：

DNS-over-HTTPS (Origin): https://dns.flymc.cc/dns-query (Origin, h2 only)

DNS-over-HTTPS (via CDN): https://dns.pari.network/dns-query (CDN, support h3)

DNS-over-TLS: tls://dns.flymc.cc (Not recommended in Mainland China)

DNS-over-QUIC: quic://dns.flymc.cc