1. DNSStubListener 开关让 resolved 监听 127.0.0.53:53 提供 DNS 解析
2. /etc/resolv.conf 链接至 /run/systemd/resolve/stub-resolv.conf，该配置指定了 nameserver 127.0.0.53
3. 应该不开会好点

大部分链接 glibc 的程序会使用 Name Service Switch (libnss)解析域名，由 /etc/nsswitch.conf 控制，通常是通过 libnss-resolve 插件走 D-Bus 访问 resolved 查询。

不链接 glibc 的程序（例如原生 go 程序）通过读 /etc/resolv.conf 自行发起查询。

@v2tudnew 需要依赖绿标的用户不会认域名。
由于 Certificate Transparently 日志政策，CA 乱签证书这事还是有防范方法的

如果你没用 os.lseek，那基本就是顺序读写，具体是不是顺序读写还要看文件是不是顺序分布在磁盘上，但这是文件系统管的事，python 管不着这个。

按 Google 的说法是 EV 的绿标对反钓鱼意义不大。

正面理解就是群众未必知道 EV 绿标显示的公司和品牌的关系，例如 Steam 和 Valve 的关系。

负面理解 Google 是为了商业利益推它的 SafeBrowsing 服务，到国内就是网站安全标识，可以收保护费的那种。

要真按 HTTPS 定安全性，一大票 gov 网站都是不安全的。

真要明白这些东西的区别的，也不需要依赖那个绿标。

另外目前浏览器认为 HTTPS 出现错误时的危险性是高于不加密的 HTTP 的，所以有些不加密能用的功能反而 HTTPS 出错后不能用。

永久性身份标识（身份证号等）没啥办法，只能减少攻击面，例如手机支付只用微信支付宝云闪付，别家的一律不用。

其他身份标识（地址、生日、银行卡号、手机号）可以使用小号（定期更换 III 类卡号、注册账户混用备用手机号），必要时用假信息，例如快递不上门就把地址模糊到小区名。

@nealot 微星所有主板都是”Supports ECC UDIMM memory (non-ECC mode)“，其他厂家一般也是说支持 ECC UDIMM 但没说是不是工作在 ECC mode 。

因为前两代有民间实验验证虽说不支持但 ECC 实际上是工作的，Ryzen5000 情况有可能也是这样。

我搞错了，按 ASUS 说法 Ryzen 5000 全系+B550/X570 都支持 ECC
( https://www.asus.com.cn/support/FAQ/1045186)
那主板根据需求买就行

大部分 B550 主板都支持 ECC，但 AMD 官方只验证 Ryzen PRO 处理器的 ECC 功能。

内存的话推荐买 3200AA 时序的 ECC Unbuffered DDR4 条子，不过购买渠道我不了解。

需要注意 MIUI 中的“访问已安装的应用列表”、“设置媒体音量”、“读写剪贴板”都是 MIUI 自创的权限项，APP 无法感知是否授权、也无法通过 Manifest 声明是否需要这个权限，因此这几个权限所有 APP 默认都是允许的。

目前没啥特别优雅的办法，github 用的是相对路径，内嵌目前只能用 base64 data uri，正常人应该都不愿意用这个的。

其实很多高校的校园网都是直接分公网 IP 的，特别是有线接入的地方，不过依旧要面对出校防火墙的问题。

Ryzen 3000 支持 JEDEC 3200 。
问题是你买到的所谓 3200MHz 的零售内存通常 SPD 包含的是 JEDEC 2666 和 XMP 3200 的配置档，如果不开 DOCP 就会跑在 JEDEC 2666 上。
镁光好像有 JEDEC 3200 的内存条，但那玩意不零售。

如果有稳定需求，不要求很高可用性的话，自己买卡组服务器就行。主要优势在于如果没有 ECC 或者特殊应用需求，可以用采购成本只有一半左右的游戏卡。
临时用用还是云服务器省事。

它**有能力**做一些你认为属于间谍行为的事，具体有没有启用到要看系统管理员的策略。
反正 Cisco 家的软件也差不多这种德行。

对于这类安全问题，如果你觉得值得折腾的（愿意搞一套虚拟机来隔离）就有罪推定就行了。

试下改成这个
After=systemd-networkd.service
Before=network.target
参考自 systemd-resolved.setvice

按目前 LE 博客的说法( https://letsencrypt.org/2020/12/21/extending-android-compatibility.html )，X1 暂时会由 DST X3 交叉签名(DSTX3->X1->R3->Entity)，因为部分平台会忽略根证书的有效期。

如果要兼容那种老平台还是老实用全 RSA 链。

COMODO Sectigo 有全 ECC 的证书链，不过不清楚申请条件。

ISRG X2 并没有纳入大部分客户端的根证书库中，预计到时候还是用交叉证书链的形式使用(X1->X2->E1->Entity),也就是 Server 要带三个证书。

目前典型的 IPv6 部署方案是用户路由器通过 PPPoE 或分配一个 IPv4 地址及一个 /128 的 IPv6 地址，同时路由器通过在 PPP 链路发送 DHCPv6-PD 请求获得一个 /64 或更短的前缀，路由器通过 ICMPv6 RA 向下游广播这个前缀。下游主机根据 RA 生成地址并通过 DAD 检测后使用地址，在该步骤中路由器只是主动或周期广播 RA 而不参与其他活动。路由器通常会隔绝下游发送的各种组播包，不会传播至上游。

@putaozhenhaochi 所提到的 ULA 网段跟保护隐私没有任何关系，按照那篇主题的说法，ULA 只是为了让局域网内的设备互访时可以使用一个稳定的地址。

目前 IPv6 主流部署的是 SLAAC，很少使用 DHCPv6 有状态配置，运营商的 DHCPv6 服务器通常只用来分配前缀（通常是 /56 或者 /64 ）。

另外对于大部分终端设备都会启用 IPv6 隐私拓展，所以并不可以通过后 64 位反推 MAC 地址。至于开放端口问题需要运营商主动扫描，传入流量还有可能会被用户自设的路由器拦截，通常是不管用的。