Nebula 灯塔 DNS：谁能查询哪些记录？
可选的监听器用灯塔持有的主机数据来回答。A 记录与 TXT 查询在可达范围和受众上并不相同，因此要有意地约束它。
Nebula 中的灯塔角色做了许多人们以为会自动完成的工作，而应答 DNS 并不在其中。名字服务是一个默认关闭的可选监听器，所以一个在 overlay 内解析顺畅的主机，可能根本没有任何办法解析同事的笔记本。开启之前，先决定谁应当能访问它、你愿意应答哪些记录类型，因为这两个答案并不一样。
监听器是可选组件，默认关闭
服务发现和 DNS 是两件不同的事。灯塔帮助对端彼此找到对方，还可以额外应答它所知道主机的名字查询，但后一部分必须在配置中明确打开。
在启用任何东西之前，先决定哪些接口和网络应当能访问监听器。一个在你并不打算使用的接口上应答的 DNS 服务，会变成一次没人会去读日志的小规模信息泄露。现在做决定，比等到有东西依赖了错误答案之后再收窄要便宜得多。两行配置也比半年后的一份事故记录更容易解释。
A 记录与 TXT 的受众并不相同
这两类记录在完全不同的条件下被应答，把它们当成同一个服务，正是本文想要避免的错误。
| Query | What it returns | Who can reach it |
|---|---|---|
| A record for a host name | That host Nebula IP | Any host that can reach the listener, overlay or not |
| TXT for a host IP | Certificate information | Only over the Nebula network |
这种不对称是刻意设计的，而不是疏漏。名字到地址的映射对外人价值很低，而证书元数据描述的是你 overlay 中的身份。不要因为同一个进程同时应答两者，就把某一行里的假设搬到另一行。
它只应答灯塔自有主机的相关信息
它不是给你的办公室、云上 VPC 或公共互联网用的通用解析器。灯塔依据交给它的主机信息来应答，这也正是该功能放在灯塔节点而非每个对端上的原因。
当某个名字解析失败、而 overlay 与此毫无关系时，去找真正拥有它的区域和解析器。把 overlay 解析器混进主机的通用 DNS 配置，会产生看起来随机的故障，因为有些名字能解析，另一些则无人应答。
同时留意引导用的入口点。用于访问第一座灯塔的主机名，必须先通过普通路径解析成功，发现过程才可能依赖它，所以这里的先有鸡还是先有蛋问题，看起来和 overlay 坏掉一模一样。它连报告方式都一样：对端始终起不来，且没有明显原因。在碰证书之前先检查名字解析，因为这个顺序恰好抓住那些从更难的一半入手的人。
先检查绑定地址，再从外部测试
lighthouse.dns.host 与 lighthouse.dns.port 决定这个可选服务在哪里监听。要连同主机防火墙和网络策略一起审视这些取值，因为绑定地址是一种意图声明，本身并不是安全控制。
dig @10.42.0.1 -p 53 workstation.nebula A +short
dig @10.42.0.1 -p 53 10.42.0.7 TXT +short从你打算放行的网络去查询，而不是从灯塔自身。在灯塔上查询成功只能证明进程在运行，完全不能说明外部主机能问什么，而后者才是真正重要的问题。
有意识地把它暴露出来
名字和证书元数据都是有用的运行信息，而有用性从来是双刃的。决定监听器是否只对 overlay 开放、允许哪些记录类型，以及配置变动时由谁复核。
然后把它写在灯塔设置旁边。下一个排查解析故障的人，否则就会以为这个服务一直都在。他还会以为自己碰巧测试的那个位置一直都能访问它。用一段话记录绑定地址、允许的网络和记录类型，就能替那个人省下一个下午，也替你自己省下一条追问“为什么改了”的消息。