DNS

关于 Google Workspace 的 SPF / DMARC 设置

| Security | #SPF | #E-mail | #DMARC | #Email | #Google Workspace | #DNS | #Authentication

这里简单记一笔。我有一个域名使用的是 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。

阅读全文…( 本文约 1412 字，阅读大致需要 3 分钟 )

采用 Ed25519 的 DKIM 签名

| Security | #DKIM | #E-mail | #DNS | #Ed25519 | #Email | #Postfix | #milter | #dkimpy-milter

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 签名向外发出的邮件。

阅读全文…( 本文约 953 字，阅读大致需要 2 分钟 )

在本地架设根 DNS 的镜像

| Security | #DNS | #DNSSEC | #unbound | #Self-hosting | #Networking | #网络

目的

在本地的局域网上建立 DNS 解析服务可以显著地改善 DNS 的安全性：所有的 DNS 查询将由可以信任的本地 DNS 解析服务进行验证， 而不是简单地相信一台不受控的远程服务器通过 UDP 提供的应答。因此，这些年来我自己的网络包括机房的网络都是自己运行一组 DNS 解析服务的。

阅读全文…( 本文约 1091 字，阅读大致需要 3 分钟 )

自建权威 DNS 的利弊

| Security | #DNS | #DNSSEC | #Self-hosting | #Networking | #网络

TL;DR：我的观点是现时 (2023) 大多数人都不应该自建 DNS，而应该找一家比较可靠的供应商。

下面说说我的理由。

阅读全文…( 本文约 1609 字，阅读大致需要 4 分钟 )

再谈域名注册服务提供商的选择

| Security | #DNSSEC | #DNS | #Domains | #Registrar | #Cloudflare | #AWS | #Porkbun | #域名

近期由于一些众所周知的原因，我做了一系列域名转移的操作。和 2006 年的这篇相比， 这些年我也经历了不少域名注册服务提供商，并且积累了不少经验，是时候更新一下了。

域名服务是一项互联网基础服务，它提供了容易被人记忆和识别的在线地址。对于个人和企业来说， 拥有自己的域名最大的好处在于能够掌握随时换一家供应商的议价权。集中式的平台， 包括 YouTube、Twitter、GitHub，也包括新兴的平台如 TikTok、 或是来自中国的小红书、喜马拉雅、B站等等，尽管也都是很好的产品， 有些甚至可以为内容作者带来丰厚的回报，但是其上的个人或是企业无法很容易地离开这些平台。 依赖这些平台，意味着在它们选择对内容作者采取某些行动，或是退出某项生意的时候， 当事人可能没有任何其他选择，而必须在极短的时间内通知自己的受众去其他平台， 这有时是很困难甚至不可能的。

对个人来说，邮件服务的运行成本是很高的（这里需要考虑的不仅是服务器本身的成本和运行费用， 也包括需要投入的时间精力）。但即使不自己去运行邮件服务，也仍然有许多支持独立域名的邮件服务提供商， 例如 Google Workspace、 Microsoft 365、Zoho Workplace等等。与单纯使用 Gmail 或 outlook.com 等等相比， 拥有独立的域名意味着可以在这些服务之间随时进行转移，而无需逐个通知亲朋好友。

阅读全文…( 本文约 3710 字，阅读大致需要 8 分钟 )

带 DNSSEC 的域名转移

| Security | #DNSSEC | #Cheatsheet | #DNS | #Migration | #作弊条 | #域名

DNSSEC 是一组针对 DNS 协议的扩展，其主要目的是为数据的权威性（或者说DNS数据确实来自于有权发布这些数据的人） 提供一套验证机制。DNSSEC并不改善私密性，所有的查询依然是明文的。

目前最新的 DNSSEC 最佳实践指南是 BCP 237 (RFC 9364)。 值得说明的是，如果没有特别的需要，使用 DNS 服务业者的 DNSSEC 实现可以避免踩很多的坑， 尽管这样一来安全方面就完全要仰赖这些业者了， 但对普通的域名所有这来说这些服务要比他们自己去架设和管理要可靠不少。 本文并不打算深入介绍 DNSSEC 及其部署，而只是关注于在进行域名转移时需要注意的问题， 以备我个人未来进行参考。

阅读全文…( 本文约 2082 字，阅读大致需要 5 分钟 )

Google Domain 域名转让备忘

| Life | Cheatsheets | #Google Domains | #DNS | #Domains | #作弊条 | #Cheatsheet | #域名

这里记录一下过程备忘。

我在 2011 年注册了一个比较技术宅的 .org 的域名，但一直没有实际投入使用， 最近宏观经济形势不太好，所以索性把不用的域名出一批来减少持续的花销， 周四终于出现了一位愿意接手的朋友，于是我们找时间做了一次域名转让的操作。

阅读全文…( 本文约 823 字，阅读大致需要 2 分钟 )

一种针对DNS缓存服务器的杠杆式攻击

| Security | #DDoS | #DNS

今天发现一台国内的机器流量异常，检查发现这台机器上运行的 DNS 缓存服务被人用作了攻击的放大杠杆，这里简单记一下。

发现流量异常，首先当然是检查服务器上的 TCP 会话，发现了一些不太正常的东西，关闭之后流量减少，但仍然没有回到正常水平。

于是听包。这一听发现一大片：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

07:39:53.271744 IP 158.XX.XX.238.53019 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.271772 IP 158.XX.XX.238.53019 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.271784 IP 158.XX.XX.238.53019 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.271792 IP 158.XX.XX.238.53019 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.274225 IP 92.XX.XX.148.31650 > XX.XX.XX.XX.53: 23600+ [1au] ANY? isc.org. (36)
07:39:53.274252 IP 92.XX.XX.148.31650 > XX.XX.XX.XX.53: 23600+ [1au] ANY? isc.org. (36)
07:39:53.274262 IP 92.XX.XX.148.31650 > XX.XX.XX.XX.53: 23600+ [1au] ANY? isc.org. (36)
07:39:53.274270 IP 92.XX.XX.148.31650 > XX.XX.XX.XX.53: 23600+ [1au] ANY? isc.org. (36)
07:39:53.291822 IP 158.XX.XX.238.13616 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.291850 IP 158.XX.XX.238.13616 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.291860 IP 158.XX.XX.238.13616 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.291869 IP 158.XX.XX.238.13616 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.291877 IP 92.XX.XX.148.56278 > XX.XX.XX.XX.53: 23600+ [1au] ANY? isc.org. (36)
阅读全文…( 本文约 679 字，阅读大致需要 2 分钟 )

如何：为小于 /24 的 IPv4 网段实现反解析

| Security | #DNS | #IP address | #Protocols

以前一直以为这事必须由ISP以个案的方式去做，最近跟北美一家ISP接触加上查阅资料以后发现其实早就有办法，原理和普通的域名解析类似，也是可以使用delegate和glue去把解析权移交给持有IP的客户，从而减少ISP自己的负担，在这里记一笔。

阅读全文…( 本文约 785 字，阅读大致需要 2 分钟 )

DNS安全：投毒攻击与缓存服务器的配置

| Security | #BIND | #DNS | #Security

DNS是目前互联网上使用最为普遍，同时也是漏洞很多的一个协议。DNS投毒攻击（Poisoning）是一种比较常见的攻击手法，具体而言，通常一台 DNS 缓存服务器能够影响大量的客户机，通过投毒攻击，能够使得大量用户访问某个具体域名时得到不正确的结果（例如，钓鱼网站，等等）。

阅读全文…( 本文约 1115 字，阅读大致需要 3 分钟 )