BaseHalf
全部文章

用 BaseHalf 和 AI 入门 DNS

我们在 BaseHalf 里打开真实的 dns-fundamentals 文件夹，把解析路径、记录类型和 TTL 笔记摆成卡片，把 upstream 写进练习笔记，再在 Agent Area 用 Claude Code 把四条 example.com 记录判为正确。

检查一组短的 DNS 记录时，最好把每个概念放在自己的卡片上，让智能体同时看到这些卡片和练习笔记。我们在桌面上建了一个普通文件夹，塞进六份短 Markdown，再用 BaseHalf 打开。窗口标题变成 dns-fundamentals，侧栏列出每一个文件，每份笔记变成卡片。我们在右侧 Agent Area 启动了 Claude Code，并选中了练习卡片。

磁盘上的路径是 Desktop/basehalf-learn-sessions/dns-fundamentals/。画布上的文件是这些：

dns-fundamentals/
  00-goal.md
  01-resolution.md
  02-record-types.md
  03-ttl.md
  04-practice.md
  sources.md

标题为 dns-fundamentals 的 BaseHalf 窗口：侧栏列出 00-goal 到 sources；画布上是目标、三张概念卡片、sources，以及 04-practice，概念卡片和 sources 有连线进入练习笔记。

每张卡片写了什么

00-goal.md 划定范围：把一次主机名查询读成解析器和名字服务器上的路径，说出一个小站点常用的记录类型，然后核对一组练习记录。

01-resolution.md 写明路径：本机的存根解析器向递归解析器提问；若递归解析器没有缓存的答案，就从根名字服务器开始，再到顶级域名字服务器（example.com 里的 “com”），最后到保存记录的权威名字服务器。

02-record-types.md 记下：A 把名字映射到 IPv4 地址，AAAA 映射到 IPv6 地址；CNAME 让它的所有者成为别名，且该名字上不应再有其他数据；MX 是优先级（数字越小越先尝试）加上一个主机名，而不是 IP；NS 是区的权威名字服务器；TXT 存放文本，常用于验证。

03-ttl.md 把 TTL 写成以秒计的时间：解析器可以把一条记录缓存多久，到期后再取一份新的。

sources.md 链接了 MDN 的 DNS 词条、Cloudflare Learning 的 DNS 是什么 和 DNS 服务器类型，以及 RFC 1034。对这个文件夹来说，这些页面才是依据，而不是模型本身。

练习笔记上的 Upstream

我们把练习笔记连到三张概念卡片和 sources.md。画布上，从 01-resolution、02-record-types、03-ttl 和 sources 出发的线，都进入 04-practice。之后，04-practice.md 的开头是：

upstream:
  - 01-resolution.md
  - 02-record-types.md
  - 03-ttl.md
  - sources.md

这份列表会留在文件里。选中不会：它只在 BaseHalf 打开时写在 .bh/cache/selection.yaml。我们选中了练习卡片，状态栏显示 04-practice，然后请 Claude Code 批改。

example.com 练习

练习卡片的题目是：为 example.com 这个文档用站点写出记录，使 example.com 解析到 IPv4 203.0.113.10，www.example.com 是 example.com 的别名，example.com 的邮件送到优先级为 10 的 mail.example.com，且 mail.example.com 解析到 IPv4 203.0.113.20。这些地址来自 RFC 5737 的文档地址段，不是正在运行的站点。

我们的答案是：

example.com.        A      203.0.113.10
www.example.com.    CNAME  example.com.
mail.example.com.   A      203.0.113.20
example.com.        MX  10 mail.example.com.

A 和 MX 留在 example.com 上，CNAME 只放在 www 上，因为带有 CNAME 的名字不应再保存其他数据。MX 的目标是一条带 A 记录的主机，不是 IP，也不是别名。

dns-fundamentals 画布和 Agent Area：Claude Code 把这四条记录判为正确，逐条对回记录类型卡片和 RFC 1034，并说明没有改任何文件。

Claude Code 实际说了什么

把回复当作草稿来看。这次会话里，Claude Code（v2.1.322，窗口里显示为 Fable 5.2、xhigh effort、Claude Ultra）给出的成绩是正确，并说四条记录都符合题目，我们的两句理由也成立，它没有发现错误。它没有编辑任何文件。这一轮用了 2 分 59 秒。

它把每条记录都对回一张卡片和文档里的一句话：两条 A 记录对到卡片 02 的 “A maps a name to an IPv4 address”，以及 RFC 1034 第 3.6 节（主机地址，32 位）；CNAME 对到卡片 02 的 “owner is the alias”，以及 RFC 1034 第 3.6.2 节；MX 对到卡片 02 的 “a preference, then a host name”，以及 RFC 1034 同一节里 “数字越小越好”。

它同意 CNAME 只应放在 www 上，并引用 RFC 1034 第 3.6.2 节：若某个名字上有 CNAME，则 “no other data should be present”（不应再有其他数据）。

同一段 Claude Code 会话，滚动到说明部分：答案里不写 TTL 作为示例记法是可以的；可服务的区还需要 SOA 和 NS；两篇 Cloudflare 页面在普通抓取被拒绝后，是在 Chrome 里读的。

它还列了几条说明，但不是扣分。MX 不得指向别名这条更明确的规则在 RFC 2181 第 10.3 节，并不在 sources.md 里；Claude Code 核对了该 RFC，并说结论和我们一致。答案省略了 TTL 和 class，RFC 1034 第 3.6.1 节也说示例里常常省掉它们；真正上线的记录仍需要 TTL，TTL 那张卡片虽在 upstream 里，这道题没有用到。一个可服务的区在 example.com 上还需要 SOA 和 NS；题目没有要求这两项。对 www.example.com 做邮件查询时，会跟随 CNAME，拿到 example.com 的 MX。名字末尾的点表示完整域名，这是 RFC 1034 第 3.1 节的写法。

关于资料本身：RFC 1034 支撑了答案里的每一条记录。两篇 Cloudflare 页面支撑解析路径那张卡片；谈到记录时，它们只说 A 记录保存 IP，CNAME 是会触发新查询的别名。MDN 词条只定义了 DNS 和查询，没有覆盖记录类型。AAAA 和 TXT 写在记录类型卡片上，但不在这四份页面里，答案也没有用到它们。对 Cloudflare 页面的普通抓取被拒绝，所以 Claude Code 后来在 Chrome 标签页里阅读，并在读完后关掉了它。

如果智能体的说法和 sources.md 里的链接不一致，以文档为准，再回去改画布上的笔记。

还是同一个产品，只是一次真实练习

BaseHalf 并没有为我们做成套的 DNS 教程。我们打开一个桌面文件夹，摆好普通的 Markdown，把 upstream 写进练习文件，然后让 Claude Code 根据这些文件和链出的页面来批改。卡片位置留在 .bh/ 里；真正要紧的连接留在文件里。这篇文章写自 dns-fundamentals 画布上的那次会话，不是虚构的教学大纲。