选择chaos这个词是因为~~实在很难找到一个更合适的词来形容这儿了……
12月1日,FreeBSD 发布了 FreeBSD-EN-23:16.openzfs, 用于修正近期发现的 ZFS 数据损坏问题。 这个问题是由 Rob Norris 最终修正的,这里记一笔。
Read more...上周末抽时间把服务器升级到了 FreeBSD 14.0-RELEASE。
软件的发布中存在许多的工序,大致上,在 releng/ 分支上的代码树会正式命名为 -RELEASE
,
同时由一位 Release Engineer 开始最终的 build(对应的文件会发布到 FTP 上,
并在 网站 上提供链接),并在适当的时候将 releng/ 分支上的代码
tag 成 release。此后, Security Team 需要将 Release Engineer 签名的 -RELEASE
放到 freebsd-update builder 上再次 build、签名,并生成二进制更新所需的文件。
由于安装用的 ISO 映像文件都比较大,传统上将这些映像文件分发到全球的镜像站点上需要一些时间。 现时,云服务提供商往往还有自己的 QA 步骤,因此最终宣布 -RELEASE 的时间往往会比 FTP 上出现的时间晚上一周左右。技术上这段时间这个 build 依然只是一个发布候选版本(Release Candidate), 因此普通用户不应使用这些版本,因为在这一周的时间如果遇到一些突发状况的话可能会需要将这个版本撤回 (例如原本应发布为 FreeBSD 4.6.1 的 FreeBSD 4.6.2 就是这样的情况)。
Read more...上回书 说到我换到了一个采用微波通讯技术的小型本地 ISP,然而经过将近两年的时间, 我最终还是换回了 Comcast。正如张师傅说的,南湾乡下的居民不配有好东西,经过这么久, 我家这边依然没有 5G 互联网服务,也没有光纤到府,至于 cable 也很自然地也没有 DOCSIS 4.0,也不想想看,您配吗?
为什么要换回 cable 呢?Sail 声称他们采用的设计可以避免雨季带来的干扰,事实来看确实是这样, 但是他们的服务稳定性在过去几个月出现了灾难性的下降,此外延迟由于一些未知的原因增加了不少。 我为此收集了一些数据,发现去大河以及 Google 的延迟有时竟然超过了 500ms,这个就实在是太难受了。
Read more...软件项目中,实现同一功能的源代码只保留一份是一项十分重要的最佳实践,这种做法可以带来许多显而易见的好处:
2009年的时候 kmacy@ 做了 一些初步的工作,但后续没有继续推进。 这之后 我 考虑重新把这个事给做掉,但苦于平时比较忙因此未能如愿。最终, Yoshihiro Ota 完成了大部分的工作。
Read more...这里简单记一笔。我有一个域名使用的是 Google Workspace 的邮件服务。 昨天,一位用户使用该域名向中国的 QQ 邮箱用户发送邮件时被退回了。
退信中给出的线索是:
550 DMARC check failed [XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
IP: 2607:f8b0:4864:20::112b]. https://service.mail.qq.com/detail/124/61.
腾讯给出的那个链接是一篇关于 DMARC 如何配置的文章。 从上下文来看,应该是由于腾讯的服务器认为 Google Workspace 的 IP 地址不在允许发信的范围内。
退信确实是 Google Workspace 的邮件服务生成的,数据来源是和对方(腾讯) MX 之间的 SMTP 会话。
我的这个域名确实启用了 DMARC。我的DMARC记录 (域名下的 _dmarc
TXT
记录) 设置如下:
v=DMARC1; p=reject; rua=mailto:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX@dmarc-reports.cloudflare.net;
pct=100; adkim=s; aspf=s
此配置要求对方检查 DKIM 和 SPF,并拒绝不匹配的邮件。
其 SPF 记录 (域名的 @ 的 TXT
记录) 设置如下。这是 Google 官方文档中推荐的设置:
v=spf1 include:_spf.google.com -all
主要的区别是,我使用的是 -all
,即拒绝 SPF 不匹配的邮件,而不是更为常见的、表示即使发现 SPF
不匹配,也仅仅做标记但允许接收的 ~all
。
这里需要说一下背景:在 2004 年左右,一些业内人士认为应该推荐采用
~all
而不是 -all
,因为当时许多大型邮件系统的架构中存在多层邮件服务器分别进行不同的过滤处理,
而在 SMTP 会话阶段直接回一个永久性拒绝 (5XX) 代码可能会让一些不适任的邮件系统管理员如此配置的邮件系统将一些伪造了来源的邮件退到不希望的地方。
我并不赞同这样的观点。事实上,在会话阶段进行退信要比在收件方服务器上生成退信并将退信退给发件人或对方域名的 postmaster 要更好:
对于垃圾邮件的发送者,这意味着他们的邮件服务器会立即知道自己的行为被直接地丑拒,
接收方明确告知他们吞下垃圾邮件,而不是继续发送。对于正常的邮件服务器,
这意味着发件人可以立即收到退信从而找到自己的邮件系统管理员,而不是告诉收件人去翻垃圾箱看看是否有自己的邮件。
另一方面,回应永久性拒绝并不妨碍收件服务器对邮件内容进行进一步分析:它完全可以在 DATA
阶段结束时再回拒绝,从而将邮件完整地接收下来但不递给收件人。
当然,历史无法假设,并已经无数次地证明人类根本不配拥有美好的事物。
DomainKey 记录 (域名下的 google._domainkey
TXT
记录) 由于与此问题无关,故在此处略去。
该域名启用了 DNSSEC。
Read more...Ed25519 是一种高性能的公钥签名系统。和 RSA 相比, 同等强度的 Ed25519 的密钥长度要比 RSA 短很多,此外,软件实现的 Ed25519 的验证速度也比同等强度的 RSA 快很多。
尽管早在2018年 RFC 8463 Section 5 就已经将 RFC 6376 Section 3.3 修正为要求验证者必须支持 Ed25519 验证,然而时至今日主要的邮件服务提供商中, 包括 Google 的 Gmail 和 Microsoft 的 Outlook.com 以及 Apple 的 iCloud 都还不支持验证 Ed25519 DKIM 签名。ProtonMail 支持 Ed25519 的 DKIM 签名,但它并不使用 Ed25519 签名向外发出的邮件。
Read more...在本地的局域网上建立 DNS 解析服务可以显著地改善 DNS 的安全性:所有的 DNS 查询将由可以信任的本地 DNS 解析服务进行验证, 而不是简单地相信一台不受控的远程服务器通过 UDP 提供的应答。因此,这些年来我自己的网络包括机房的网络都是自己运行一组 DNS 解析服务的。
Read more...TL;DR:我的观点是现时 (2023) 大多数人都不应该自建 DNS,而应该找一家比较可靠的供应商。
下面说说我的理由。
Read more...近期由于一些众所周知的原因,我做了一系列域名转移的操作。和 2006 年的这篇相比, 这些年我也经历了不少域名注册服务提供商,并且积累了不少经验,是时候更新一下了。
域名服务是一项互联网基础服务,它提供了容易被人记忆和识别的在线地址。对于个人和企业来说, 拥有自己的域名最大的好处在于能够掌握随时换一家供应商的议价权。集中式的平台, 包括 YouTube、Twitter、GitHub,也包括新兴的平台如 TikTok、 或是来自中国的小红书、喜马拉雅、B站等等,尽管也都是很好的产品, 有些甚至可以为内容作者带来丰厚的回报,但是其上的个人或是企业无法很容易地离开这些平台。 依赖这些平台,意味着在它们选择对内容作者采取某些行动,或是退出某项生意的时候, 当事人可能没有任何其他选择,而必须在极短的时间内通知自己的受众去其他平台, 这有时是很困难甚至不可能的。
对个人来说,邮件服务的运行成本是很高的(这里需要考虑的不仅是服务器本身的成本和运行费用, 也包括需要投入的时间精力)。但即使不自己去运行邮件服务,也仍然有许多支持独立域名的邮件服务提供商, 例如 Google Workspace、 Microsoft 365、Zoho Workplace等等。与单纯使用 Gmail 或 outlook.com 等等相比, 拥有独立的域名意味着可以在这些服务之间随时进行转移,而无需逐个通知亲朋好友。
Read more...DNSSEC 是一组针对 DNS 协议的扩展,其主要目的是为数据的权威性(或者说DNS数据确实来自于有权发布这些数据的人) 提供一套验证机制。DNSSEC并不改善私密性,所有的查询依然是明文的。
目前最新的 DNSSEC 最佳实践指南是 BCP 237 (RFC 9364)。 值得说明的是,如果没有特别的需要,使用 DNS 服务业者的 DNSSEC 实现可以避免踩很多的坑, 尽管这样一来安全方面就完全要仰赖这些业者了, 但对普通的域名所有这来说这些服务要比他们自己去架设和管理要可靠不少。 本文并不打算深入介绍 DNSSEC 及其部署,而只是关注于在进行域名转移时需要注意的问题, 以备我个人未来进行参考。
Read more...